mesa-users — open list for mesa comments, questions, & answers

[mesa-users] Modules in the other_hooks

[Héctor MR <hec...@pi...>]

  Dear all,

  How can I include a module (let's say mymodule.f) within the subroutine
for an extra_hook? I mean something like (e.g.)

  module mymodule

  use star_def
  use const_def

  [...]

  end module mymodule

  and then

  subroutine other_neu(id, ierr)
  *! include my code here*
  end subroutine other_neu

  Should I change the makefile somehow to generate the mymodule.o file
along with MESA's compilation (and then "use mymodule" within the hook)?

  Thanks!


  --
  H.

[mesa-users] which file creates the reaction rates binary files?

[李二涛 <le...@sz...>]

 Dear MESA users,
 
I know that the reaction rates are stored in data/rates_data/cache as binary files. From the star/defaults/star_job.defaults file,  I also know that I am using jina_reaclib_results_20130213default2 database. So, I suppose that the binary files are created by the  jina_reaclib_results_20130213default2 file. But, after I deleted a reaction binary file and  replaced the jina_reaclib_results_20130213default2 with an empty file(just have the same file name:jina_reaclib_results_20130213default2), to my surprise, the MESA still able to create a new binary file and run successfully.
  
Now, I am wondering which file creates the reaction rates binary files when running the MESA?
 
Thanks in advance for any help that you can offer!




Er-Tao Li(李二涛)
Institute of Nuclear Technology，College of Physics & Energy, Shenzhen University
Nanhai Ave 3688, Shenzhen, Guangdong, P.R.China, 518060 
Tel: 86-755-26536232. Fax: 86-755-26534374 
 
 

 

Re: [mesa-users] changes in spatial and temporal resolution in MESA

[Robert F. <rjf...@as...>]

Hi

>'mesh_delta_coeff' in all of the 5 inlists provided i.e.
inlist_remove_core, inlist_adjust, inlist_edep, inlist_explosion

first you need to understand how mesa is doing the ccsn in 7624. I would
start from the ccsn test case and not the mesaIII inlists

In the ccsn test case there are several inlists corresponds to a single
step in the process of exploding a star, looking in the rn file to find the
order they are ran in you'll see:

do_one inlist_adjust_header ready_to_remove_center.mod
do_one inlist_remove_core_header ready_to_shock.mod
do_one inlist_edep_header done_with_edep.mod
do_one inlist_explosion_header final.mod

I would thus suggest you only worry about making changes to the last set of
inlists inlist_explosion and inlist_explosion_header as that is what is
doing the explosion, the other inlists setup the explosion by removing the
core and inserting the extra energy.

> mesh_delta_coeff_for_highT vs mesh_delta_coeff

You can change the value of mesh_delta_coeff between "normal" temperatures
and high temperatures, usually you want to reduce the number of zones at
high T to cut the computational time.

I suggest a good read of the
http://mesa.sourceforge.net/docs/r7624/controls_defaults.html#mesh_adjustment
section to see where the split between normal and high T occurs.

>In order to change the spatial resolution, is it only the
'varcontrol_target'

No, varcontrol_target controls the timestep not the spatial resolution,
look over
http://mesa.sourceforge.net/docs/r7624/controls_defaults.html#timestep_controls
for the various options.

mesh_delta and varcontrol are the easiest ways to change the mesh/timestep
but they are not the only ways, they are also somewhat crude and apply
everywhere there are other controls than can add mesh/time points only
where you want it to go.

>I'm not sure what's the role of 'min_timestep_limit' here?

Its the minimum timestep in seconds mesa will take, if it tries to take a
smaller timestep mesa will stop.

Rob



On Tue, Mar 28, 2017 at 8:56 AM, Subedi, Shiv Kumar <ss3...@oh...>
wrote:

> Dear All!
>
>
> Currently I have been using MESA version 7624 to study the explosive
> nucleosynthesis phenomenon in Core-Collapse Supenova (CCSN). For this I
> have been using the explosive nucleosynthesis inlists provided in the MESA
> III Instrument Paper Inlists. I now wish to do the convergence tests
> changing the spatial resolution and temporal resolution in the inlists.
>
>
> I have an idea that in order to investigae the changes in spatial
> resolution, we need to make changes in the values of the 'mesh_delta_coeff'
> in all of the 5 inlists provided i.e. inlist_remove_core, inlist_adjust,
> inlist_edep, inlist_explosion and inlist_massive_defaults. But when I go
> into individual inlists I find following statements of the 'mesh_delta
> coeff' and I'm not sure which of them should I change? I am also curious to
> know about the choice of the values of the mesh_delta_coeff values below.
>
>
> Inlist_adjust:
>
>                       mesh_delta_coeff_for_highT = 1.4
>
>
> Inlist_remove_core:
>
>                       mesh_delta_coeff_for_highT = 1.4
>
>
> Inlist_explosion:
>
>                         mesh_delta_coeff = 0.8
>
>
> Inlist_massive_defaults:
>
>                         mesh_delta_coeff = 1.5
>                        mesh_delta_coeff_for_highT = 2.5
>                        logT_max_for_standard_mesh_delta_coeff = 9.0
>                         logT_min_for_highT_mesh_delta_coeff = 9.5
>
> In addition, In order to change the spatial resolution, is it only the
> 'varcontrol_target' that we need to change? I am confused when I look into
> the inlist_explosion of MESA Summer School 2015 Minilab 2 (simulating
> supernova explosions and nucleosynthesis) exercise where it provides
> following set of timestep controls varriables.
>
> varcontrol_target = 1d-3
> min_timestep_limit = 1d-10
>
> I'm not sure what's the role of 'min_timestep_limit' here?
>
> Also, in order to make the supernova explosion to work, I had to make
> following change in the 'solver controls' section in  'inlist_explosion' of
> the MESA III Instrument Paper Inlists.
> I replaced 'use_time_centering = .true. '  by 'use_energy_coversion_form=.
> true.'.
> I am not sure what are the roles of each of above parameters and if its
> the right way to undergo the supernova explosion in MESA?
>
> I'd really appreciate if anyone could provide his/her useful suggestions
> and guidance.
>
> Sincerely,
> Shiv Subedi
> Graduate Student
> Ohio University
> Athens, Ohio
>
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>

[mesa-users] changes in spatial and temporal resolution in MESA

[Subedi, S. K. <ss3...@oh...>]

Dear All!


Currently I have been using MESA version 7624 to study the explosive nucleosynthesis phenomenon in Core-Collapse Supenova (CCSN). For this I have been using the explosive nucleosynthesis inlists provided in the MESA III Instrument Paper Inlists. I now wish to do the convergence tests changing the spatial resolution and temporal resolution in the inlists.


I have an idea that in order to investigae the changes in spatial resolution, we need to make changes in the values of the 'mesh_delta_coeff' in all of the 5 inlists provided i.e. inlist_remove_core, inlist_adjust, inlist_edep, inlist_explosion and inlist_massive_defaults. But when I go into individual inlists I find following statements of the 'mesh_delta coeff' and I'm not sure which of them should I change? I am also curious to know about the choice of the values of the mesh_delta_coeff values below.


Inlist_adjust:

                      mesh_delta_coeff_for_highT = 1.4


Inlist_remove_core:

                      mesh_delta_coeff_for_highT = 1.4


Inlist_explosion:

                        mesh_delta_coeff = 0.8


Inlist_massive_defaults:

                        mesh_delta_coeff = 1.5
                       mesh_delta_coeff_for_highT = 2.5
                       logT_max_for_standard_mesh_delta_coeff = 9.0
                        logT_min_for_highT_mesh_delta_coeff = 9.5

In addition, In order to change the spatial resolution, is it only the 'varcontrol_target' that we need to change? I am confused when I look into the inlist_explosion of MESA Summer School 2015 Minilab 2 (simulating supernova explosions and nucleosynthesis) exercise where it provides following set of timestep controls varriables.

varcontrol_target = 1d-3
min_timestep_limit = 1d-10

I'm not sure what's the role of 'min_timestep_limit' here?

Also, in order to make the supernova explosion to work, I had to make following change in the 'solver controls' section in  'inlist_explosion' of the MESA III Instrument Paper Inlists.
I replaced 'use_time_centering = .true. '  by 'use_energy_coversion_form=.true.'.
I am not sure what are the roles of each of above parameters and if its the right way to undergo the supernova explosion in MESA?

I'd really appreciate if anyone could provide his/her useful suggestions and guidance.

Sincerely,
Shiv Subedi
Graduate Student
Ohio University
Athens, Ohio

Re: [mesa-users] Change in evolutionary timescale between r8118 and r9575

[Aaron D. <aar...@gm...>]

Hi Matteo,

Somewhere between r8118 and r9575 there was a change to the internal EOS
code that switched from cubic to linear interpolation in X.

I was able to reproduce your results between 8118 and 9575 by switching
back and forth between linear and cubic interpolation in the EOS.

Can you continue to use r8118?  If not, you might want to wait for the next
public release and update again.

Aaron


On Tue, Mar 28, 2017 at 11:03 AM, Matteo Dell'Omodarme <mat...@fa...
> wrote:

> Dear All,
>
> I'm performing some basic comparisons in order to extend (using MESA
> r9575) a
> dataset computed by means of MESA r8118.
> I'm noticing some differences in the evolutionary timescale between the two
> releases.
>
> The case study I'd like to discuss is M = 1.40 Msun, Z = 0.01894, Y =
> 0.2674.
> The inlist for the computations are attached to this message (inlist,
> inlist_default, and inlist-nr) [the control  photo_interval in r9575
> replaces
> the old photosteps], as well as the .net adopted.
>
> It turns out that the stellar evolution computed by r9575 is 2% faster than
> the one by r8118 (see attached plots). This is a very notable difference --
> all input being the same -- and it
> will have a relevant impact on grid-based estimates of stellar mass,
> radius, and age.
>
> I've no clue to trace the origin of the difference, since the release
> notes do
> not highlight some changes which could alter so much the evolutionary
> timescale.
>
> Could someone help by pointing out the changes (algorithms or default
> values) occurred between the two versions?
>
> Thanks in advance,
> Matteo Dell'Omodarme
>
> Sezione di Astronomia
> Università di Pisa
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>

Re: [mesa-users] Change in evolutionary timescale between r8118 and r9575

[Pablo M. <pa...@gm...>]

Hi Matteo, my first recommendation would be to check for convergence of
your models. Using the same version of MESA, do you get the same lifetime
if you increase resolution by two and decrease your timesteps by a similar
factor? How many steps are you using to model the main sequence.

At this mass in particular you could be getting a small convective core as
well. Depending on your treatment of the convective boundary this can cause
odd discrepancies. You can for instance make some Kippenhahn plots to check
for this, either using the options available on PGSTAR for that, or some
python tools developed by some of us

https://github.com/orlox/mkipp
https://github.com/rjfarmer/mesaplot

In particular I'd recommend you use the Ledoux criterion with
semiconvection, by setting

use_ledoux_criterion = .true.
alpha_semiconvection = 1d0

Cheers

On Tue, Mar 28, 2017 at 10:03 AM, Matteo Dell'Omodarme <mat...@fa...
> wrote:

> Dear All,
>
> I'm performing some basic comparisons in order to extend (using MESA
> r9575) a
> dataset computed by means of MESA r8118.
> I'm noticing some differences in the evolutionary timescale between the two
> releases.
>
> The case study I'd like to discuss is M = 1.40 Msun, Z = 0.01894, Y =
> 0.2674.
> The inlist for the computations are attached to this message (inlist,
> inlist_default, and inlist-nr) [the control  photo_interval in r9575
> replaces
> the old photosteps], as well as the .net adopted.
>
> It turns out that the stellar evolution computed by r9575 is 2% faster than
> the one by r8118 (see attached plots). This is a very notable difference --
> all input being the same -- and it
> will have a relevant impact on grid-based estimates of stellar mass,
> radius, and age.
>
> I've no clue to trace the origin of the difference, since the release
> notes do
> not highlight some changes which could alter so much the evolutionary
> timescale.
>
> Could someone help by pointing out the changes (algorithms or default
> values) occurred between the two versions?
>
> Thanks in advance,
> Matteo Dell'Omodarme
>
> Sezione di Astronomia
> Università di Pisa
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>


-- 
Pablo Marchant Campos
M.Sc on Astrophysics, Universidad Católica de Chile
PhD student, Argelander-Institut für Astronomie

[mesa-users] Change in evolutionary timescale between r8118 and r9575

[Matteo Dell'O. <mat...@fa...>]

Dear All,

I'm performing some basic comparisons in order to extend (using MESA 
r9575) a
dataset computed by means of MESA r8118.
I'm noticing some differences in the evolutionary timescale between the two
releases.

The case study I'd like to discuss is M = 1.40 Msun, Z = 0.01894, Y =
0.2674.
The inlist for the computations are attached to this message (inlist,
inlist_default, and inlist-nr) [the control  photo_interval in r9575 
replaces
the old photosteps], as well as the .net adopted.

It turns out that the stellar evolution computed by r9575 is 2% faster than
the one by r8118 (see attached plots). This is a very notable difference --
all input being the same -- and it
will have a relevant impact on grid-based estimates of stellar mass,
radius, and age.

I've no clue to trace the origin of the difference, since the release 
notes do
not highlight some changes which could alter so much the evolutionary 
timescale.

Could someone help by pointing out the changes (algorithms or default
values) occurred between the two versions?

Thanks in advance,
Matteo Dell'Omodarme

Sezione di Astronomia
Università di Pisa

Re: [mesa-users] MESA writes incorrect mass to history and profile files after switching inlists

[Bellinger, E. <bel...@mp...>]

Aha, that explains it. Thanks for your quick reply. 

Best regards, 
Earl Bellinger 

---
www.earlbellinger.com
Department of Astronomy, Yale University
Stellar Ages & Galactic Evolution Group, Max Planck Institute

________________________________________
From: Bill Paxton [pa...@ki...]
Sent: Monday, March 27, 2017 9:20 PM
To: Bellinger, Earl
Cc: mes...@li... users
Subject: Re: [mesa-users] MESA writes incorrect mass to history and profile files after switching inlists

Hi Earl,

Keep in mind that initial_mass is a control parameter that you either set or it has the default value:


         !### initial_mass

         ! initial mass in Msun units.
         ! can be any value you'd like when  you are creating a pre-main sequence model.

         ! not used when loading a saved model.
         ! however is reported in output as the initial mass of the star.

         ! if you are loading a ZAMS model and the requested mass is in the range of
         ! prebuilt models, the code will interpolate in mass using the closest prebuilt models.
         ! if the requested mass is beyond the range of the prebuilt models, the code will
         ! load the closest one and then call "relax mass" to create a model to match the request.
         ! the prebuilt range is 0.08 Msun to 100 Msun, so the `relax_mass`
         ! method is only used for extreme cases.  there are enough prebuilt models that the
         ! interpolation in mass seems to work fine for many applications.

      initial_mass = 1


-b



On Mar 27, 2017, at 12:01 PM, Earl Bellinger wrote:

> Dear mesa-users,
>
> With fear of having done something terribly wrong, I present to you
> all the following bug I am experiencing with the newest version of
> MESA (r9575).
>
> I run a pre-main sequence model with a mass M=1.5. MESA outputs the following:
>
>
> DATE: 2017-03-27
> TIME: 20:09:07
>                                         version_number        9575
> read inlist_0all
> read inlist_1pms
> create pre-main-sequence model
>                                          species  mass          10
> 1.5000000000000000D+00
>        729   7.264438   7125.621   0.687587   0.687587   1.500000
> 1.500000   0.703459   0.004628   0.272383   0.708406  -2.165113    863
>     0
> ...
> saved to zams.mod
>
>
> The pre-main sequence terminates; I switch to a main sequence inlist
> and load the saved ZAMS model. I run it and again a mass of 1.5 is
> output to stdout:
>
>
>                                         version_number        9575
> read inlist_0all
> read inlist_2ms
> load saved model zams.mod
>        733   7.265671   7171.550   0.689069   0.689069   1.500000
> 1.500000   0.700155   0.004664   0.272383   0.707918  -2.167833   1009
>     0
> ...
>
>
> But when I check the history and profile files, I see
>
>
> initial_mass
> 1.0000000000000000E+000
>
>
> The FGONG file, however, has the right mass of 2.983800000E+33 (i.e. 1.5 M_Sun).
>
> If I instead combine all of the inlists into one big inlist instead of
> separating the pre-main sequence from the main sequence, the history
> and profile files output the right mass:
>
>
> initial_mass
> 1.5000000000000000E+000
>
>
> Have I made some mistake, or is there a bug? (Inlists attached.)
>
> Best regards,
> Earl Bellinger
>
> ---
> www.earlbellinger.com
> Department of Astronomy, Yale University
> Stellar Ages & Galactic Evolution Group, Max Planck Institute
> <inlist><inlist_0all><inlist_1pms><inlist_2ms><zams.mod>------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

Re: [mesa-users] MESA writes incorrect mass to history and profile files after switching inlists

[Bill P. <pa...@ki...>]

Hi Earl,

Keep in mind that initial_mass is a control parameter that you either set or it has the default value:


         !### initial_mass

         ! initial mass in Msun units.
         ! can be any value you'd like when  you are creating a pre-main sequence model.

         ! not used when loading a saved model.
         ! however is reported in output as the initial mass of the star.

         ! if you are loading a ZAMS model and the requested mass is in the range of
         ! prebuilt models, the code will interpolate in mass using the closest prebuilt models.
         ! if the requested mass is beyond the range of the prebuilt models, the code will
         ! load the closest one and then call "relax mass" to create a model to match the request.
         ! the prebuilt range is 0.08 Msun to 100 Msun, so the `relax_mass`
         ! method is only used for extreme cases.  there are enough prebuilt models that the
         ! interpolation in mass seems to work fine for many applications.

      initial_mass = 1


-b



On Mar 27, 2017, at 12:01 PM, Earl Bellinger wrote:

> Dear mesa-users,
> 
> With fear of having done something terribly wrong, I present to you
> all the following bug I am experiencing with the newest version of
> MESA (r9575).
> 
> I run a pre-main sequence model with a mass M=1.5. MESA outputs the following:
> 
> 
> DATE: 2017-03-27
> TIME: 20:09:07
>                                         version_number        9575
> read inlist_0all
> read inlist_1pms
> create pre-main-sequence model
>                                          species  mass          10
> 1.5000000000000000D+00
>        729   7.264438   7125.621   0.687587   0.687587   1.500000
> 1.500000   0.703459   0.004628   0.272383   0.708406  -2.165113    863
>     0
> ...
> saved to zams.mod
> 
> 
> The pre-main sequence terminates; I switch to a main sequence inlist
> and load the saved ZAMS model. I run it and again a mass of 1.5 is
> output to stdout:
> 
> 
>                                         version_number        9575
> read inlist_0all
> read inlist_2ms
> load saved model zams.mod
>        733   7.265671   7171.550   0.689069   0.689069   1.500000
> 1.500000   0.700155   0.004664   0.272383   0.707918  -2.167833   1009
>     0
> ...
> 
> 
> But when I check the history and profile files, I see
> 
> 
> initial_mass
> 1.0000000000000000E+000
> 
> 
> The FGONG file, however, has the right mass of 2.983800000E+33 (i.e. 1.5 M_Sun).
> 
> If I instead combine all of the inlists into one big inlist instead of
> separating the pre-main sequence from the main sequence, the history
> and profile files output the right mass:
> 
> 
> initial_mass
> 1.5000000000000000E+000
> 
> 
> Have I made some mistake, or is there a bug? (Inlists attached.)
> 
> Best regards,
> Earl Bellinger
> 
> ---
> www.earlbellinger.com
> Department of Astronomy, Yale University
> Stellar Ages & Galactic Evolution Group, Max Planck Institute
> <inlist><inlist_0all><inlist_1pms><inlist_2ms><zams.mod>------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

[mesa-users] MESA writes incorrect mass to history and profile files after switching inlists

[Earl B. <bel...@mp...>]

Dear mesa-users,

With fear of having done something terribly wrong, I present to you
all the following bug I am experiencing with the newest version of
MESA (r9575).

I run a pre-main sequence model with a mass M=1.5. MESA outputs the following:


DATE: 2017-03-27
TIME: 20:09:07
                                         version_number        9575
 read inlist_0all
 read inlist_1pms
 create pre-main-sequence model
                                          species  mass          10
1.5000000000000000D+00
        729   7.264438   7125.621   0.687587   0.687587   1.500000
1.500000   0.703459   0.004628   0.272383   0.708406  -2.165113    863
     0
...
 saved to zams.mod


The pre-main sequence terminates; I switch to a main sequence inlist
and load the saved ZAMS model. I run it and again a mass of 1.5 is
output to stdout:


                                         version_number        9575
 read inlist_0all
 read inlist_2ms
load saved model zams.mod
        733   7.265671   7171.550   0.689069   0.689069   1.500000
1.500000   0.700155   0.004664   0.272383   0.707918  -2.167833   1009
     0
...


But when I check the history and profile files, I see


initial_mass
1.0000000000000000E+000


The FGONG file, however, has the right mass of 2.983800000E+33 (i.e. 1.5 M_Sun).

If I instead combine all of the inlists into one big inlist instead of
separating the pre-main sequence from the main sequence, the history
and profile files output the right mass:


initial_mass
1.5000000000000000E+000


Have I made some mistake, or is there a bug? (Inlists attached.)

Best regards,
Earl Bellinger

---
www.earlbellinger.com
Department of Astronomy, Yale University
Stellar Ages & Galactic Evolution Group, Max Planck Institute

[mesa-users] save a partial mode for gyre?

[Jing L. <jin...@gm...>]

Dear mesa-users,

I have two questions please :-)

1, Is it possible to save only part of a stellar model in the format of
'GYRE' please?

The motivation is: my model has a thin outer convective region. Since the
non-adiabatic computation for oscillation cannot really treat the
convective region properly (people use the so-called 'frozen convection'
which is physically incorrect), so I'd like to cut off the convective
region. Then the outer boundary of the partial stellar model won't have
pressure=0, so I also need to use my own set of outer boundary conditions.

2, Is it possible to set up my own outer boundary conditions for gyre
please?

Many thanks!

Sincerely,
Jing

Re: [mesa-users] EOS build failed

[Josiah S. <jws...@uc...>]

Hi Stephen,

> ../utils/build_and_test_parallel: line 56: 18962 Killed
>   ./test_quietly &> test_quietly.txt

That looks to me like your system killed the process.  Check your system
logs to see why.

Josiah

Re: [mesa-users] EOS build failed

[Aaron D. <aar...@gm...>]

Hi Steve,

You might try cd'ing to the directory:

/home/istvan/mesa/eos/test

executing the test code and seeing what happens.  Does that give you more
information about what went wrong?

Aaron

On Wed, Mar 22, 2017 at 2:04 PM, Stephen Asztalos <sja...@lb...>
wrote:

> HI,
>
> Release 9575 compiled nicely through the eos package, then exited
> unceremoniously. There's not much to go on and am open to ideas on
> what went wrong.
>
> Thanks,
>
> Steve
>
> ----------
>
> /home/istvan/mesa/eos
> building eos package.
>
> gfortran -fopenmp -o ../plotter eos_support.o plot_eosDT.o
> plot_eosQT.o plot_eosPT.o plot_eosDE.o plot_eosDT_dfridr.o plotter.o
> -L../../make -leos -L../../../lib -lchem -linterp_2d -linterp_1d -lnum
> -lf2crlibm -lcrlibm -lmtx -lconst -lutils -lmesaklu
> `mesasdk_lapack_link` `mesasdk_blas_link`
> gfortran -fopenmp -o ../tester opal_eval.o eos_support.o
> test_macdonald_eos.o test_eos_support.o test_eos.o -L../../make -leos
> -L../../../lib -lchem -linterp_2d -linterp_1d -lnum -lf2crlibm
> -lcrlibm -lmtx -lconst -lutils -lmesaklu `mesasdk_lapack_link`
> `mesasdk_blas_link`
> gfortran -fopenmp -o ../test_quietly eos_support.o
> test_macdonald_eos.o test_eos_support.o test_eos_quietly.o
> -L../../make -leos -L../../../lib -lchem -linterp_2d -linterp_1d -lnum
> -lf2crlibm -lcrlibm -lmtx -lconst -lutils -lmesaklu
> `mesasdk_lapack_link` `mesasdk_blas_link`
> gfortran -fopenmp -o ../sample sample_eos.o -L../../make -leos
> -L../../../lib -lchem -linterp_2d -linterp_1d -lnum -lf2crlibm
> -lcrlibm -lmtx -lconst -lutils -lmesaklu `mesasdk_lapack_link`
> `mesasdk_blas_link`
> ../utils/build_and_test_parallel: line 56: 18962 Killed
>   ./test_quietly &> test_quietly.txt
>
> /home/istvan/mesa/eos/test
> FAILED
>
>
> /home/istvan/mesa/eos
> ./build_and_test FAILED
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>

[mesa-users] EOS build failed

[Stephen A. <sja...@lb...>]

HI,

Release 9575 compiled nicely through the eos package, then exited
unceremoniously. There's not much to go on and am open to ideas on
what went wrong.

Thanks,

Steve

----------

/home/istvan/mesa/eos
building eos package.

gfortran -fopenmp -o ../plotter eos_support.o plot_eosDT.o
plot_eosQT.o plot_eosPT.o plot_eosDE.o plot_eosDT_dfridr.o plotter.o
-L../../make -leos -L../../../lib -lchem -linterp_2d -linterp_1d -lnum
-lf2crlibm -lcrlibm -lmtx -lconst -lutils -lmesaklu
`mesasdk_lapack_link` `mesasdk_blas_link`
gfortran -fopenmp -o ../tester opal_eval.o eos_support.o
test_macdonald_eos.o test_eos_support.o test_eos.o -L../../make -leos
-L../../../lib -lchem -linterp_2d -linterp_1d -lnum -lf2crlibm
-lcrlibm -lmtx -lconst -lutils -lmesaklu `mesasdk_lapack_link`
`mesasdk_blas_link`
gfortran -fopenmp -o ../test_quietly eos_support.o
test_macdonald_eos.o test_eos_support.o test_eos_quietly.o
-L../../make -leos -L../../../lib -lchem -linterp_2d -linterp_1d -lnum
-lf2crlibm -lcrlibm -lmtx -lconst -lutils -lmesaklu
`mesasdk_lapack_link` `mesasdk_blas_link`
gfortran -fopenmp -o ../sample sample_eos.o -L../../make -leos
-L../../../lib -lchem -linterp_2d -linterp_1d -lnum -lf2crlibm
-lcrlibm -lmtx -lconst -lutils -lmesaklu `mesasdk_lapack_link`
`mesasdk_blas_link`
../utils/build_and_test_parallel: line 56: 18962 Killed
  ./test_quietly &> test_quietly.txt

/home/istvan/mesa/eos/test
FAILED


/home/istvan/mesa/eos
./build_and_test FAILED

Re: [mesa-users] adding rotation

[Bill W. <wm...@ph...>]

Hi Catherine,

Please keep replies on the users list so others can learn from any resolution.

Short answer: Yep, that should work.

Longer answer: you should take a long look at any included run_star_extras file from a directory you start from, especially if you didn’t create it. There may be other surprises in there that you might not want or good surprises you could learn from. In general, test suite cases come with implicit time limits to help determine if the test “fails” by taking too long. You probably want to remove that, too. multimass has some other tricks up its sleeve like changing velocities and maximum timestep durations.

Glad we figured it out!

Regards,

Bill

________________________ 
William Wolf 
wm...@ph... 

UCSB Department of Physics 

On March 21, 2017 at 12:00:52 PM, Catherine Lovekin (clo...@mt...) wrote:

Hi Bill,



I do indeed start from the multimass test case.  It looks like I should be able to comment out the if statement where that gets set to avoid the problem then?



Catherine



Catherine Lovekin
Assistant Professor
Department of Physics
Dunn 222
Mount Allison University
clo...@mt...
phone: (506) 364-2582
From: Bill Wolf <wm...@ph...>
Sent: Tuesday, March 21, 2017 3:56 PM
To: mes...@li...; Catherine Lovekin
Subject: Re: [mesa-users] adding rotation
 
Ah, for instance, the multimass test case sets initial surface rotation to 45 in its run_star_extras, so did you by chance start from that?

Bill

________________________ 
William Wolf 
wm...@ph... 

UCSB Department of Physics 

On March 21, 2017 at 11:54:44 AM, Bill Wolf (wm...@ph...) wrote:

Hi Catherine,

Is what you’ve pasted the contents of your file called “inlist”? If not, an easy way to get this problem would be for this control to be read from another inlist that you forgot about.

Also, if you copied your original work directory from a test suite case, there may be hooks in run_star_extras.f that were relevant for the test but are not relevant to your experiment.

Very intriguing if it’s not one of these situations...

Bill

________________________ 
William Wolf 
wm...@ph... 

UCSB Department of Physics 

On March 21, 2017 at 11:45:41 AM, Catherine Lovekin (clo...@mt...) wrote:

Hi everyone,



I'm trying to run some rotating models (1.2-2.2 solar masses), and I've run into a problem.  For now, I'm trying to include rotation in the simplest way possible,  so I've got an inlist that has the following:

&star_job

   show_log_description_at_start = .false.

   eos_file_prefix = 'mesa'
   kappa_file_prefix = 'gs98'

   change_v_flag = .true.
   new_v_flag = .true.

   new_rotation_flag = .true.
   change_rotation_flag = .true.

   relax_initial_surface_rotation_v = .true.
   set_surface_rotation_v = .true.
   new_surface_rotation_v = 100
      

/ ! end of star_job namelist



When I run a model, it starts out with whatever rotation rate I set on the last line, but around 30 models in, I see:
 turn on rotation
                               new_surface_rotation_v =    4.5000000000000000D+01    3.7745766462731172D-05

and the rotation rate of my star drops.  I can confirm that this is what happens when I plot omega or v as a function of the age of the star. The rotation velocity starts out where I set it, and then drops to close to 45 km/s and evolves from there.  

 I get a surface rotation of 45 km/s for my model even if I comment all of the rotation commands out of my inlist, so it seems that my version of mesa is reading a velocity from somewhere else, or there's a default that isn't getting changed somehow.   I've tried deleting all my inlists and making new ones, as well as recompiling the code, but the problem doesn't go away.  Is there another rotation parameter I'm not setting, or another place I should be changing the rotation?  I'm running version 8845 on a Mac OSX 10.9.5.



Thanks,



Catherine



Catherine Lovekin
Assistant Professor
Department of Physics
Dunn 222
Mount Allison University
clo...@mt...
phone: (506) 364-2582
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
mesa-users mailing list
mes...@li...
https://lists.sourceforge.net/lists/listinfo/mesa-users

Re: [mesa-users] adding rotation

[Bill W. <wm...@ph...>]

Ah, for instance, the multimass test case sets initial surface rotation to 45 in its run_star_extras, so did you by chance start from that?

Bill

________________________ 
William Wolf 
wm...@ph... 

UCSB Department of Physics 

On March 21, 2017 at 11:54:44 AM, Bill Wolf (wm...@ph...) wrote:

Hi Catherine,

Is what you’ve pasted the contents of your file called “inlist”? If not, an easy way to get this problem would be for this control to be read from another inlist that you forgot about.

Also, if you copied your original work directory from a test suite case, there may be hooks in run_star_extras.f that were relevant for the test but are not relevant to your experiment.

Very intriguing if it’s not one of these situations...

Bill

________________________ 
William Wolf 
wm...@ph... 

UCSB Department of Physics 

On March 21, 2017 at 11:45:41 AM, Catherine Lovekin (clo...@mt...) wrote:

Hi everyone,



I'm trying to run some rotating models (1.2-2.2 solar masses), and I've run into a problem.  For now, I'm trying to include rotation in the simplest way possible,  so I've got an inlist that has the following:

&star_job

   show_log_description_at_start = .false.

   eos_file_prefix = 'mesa'
   kappa_file_prefix = 'gs98'

   change_v_flag = .true.
   new_v_flag = .true.

   new_rotation_flag = .true.
   change_rotation_flag = .true.

   relax_initial_surface_rotation_v = .true.
   set_surface_rotation_v = .true.
   new_surface_rotation_v = 100
      

/ ! end of star_job namelist



When I run a model, it starts out with whatever rotation rate I set on the last line, but around 30 models in, I see:
 turn on rotation
                               new_surface_rotation_v =    4.5000000000000000D+01    3.7745766462731172D-05

and the rotation rate of my star drops.  I can confirm that this is what happens when I plot omega or v as a function of the age of the star. The rotation velocity starts out where I set it, and then drops to close to 45 km/s and evolves from there.  

 I get a surface rotation of 45 km/s for my model even if I comment all of the rotation commands out of my inlist, so it seems that my version of mesa is reading a velocity from somewhere else, or there's a default that isn't getting changed somehow.   I've tried deleting all my inlists and making new ones, as well as recompiling the code, but the problem doesn't go away.  Is there another rotation parameter I'm not setting, or another place I should be changing the rotation?  I'm running version 8845 on a Mac OSX 10.9.5.



Thanks,



Catherine



Catherine Lovekin
Assistant Professor
Department of Physics
Dunn 222
Mount Allison University
clo...@mt...
phone: (506) 364-2582
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
mesa-users mailing list
mes...@li...
https://lists.sourceforge.net/lists/listinfo/mesa-users

Re: [mesa-users] adding rotation

[Bill W. <wm...@ph...>]

Hi Catherine,

Is what you’ve pasted the contents of your file called “inlist”? If not, an easy way to get this problem would be for this control to be read from another inlist that you forgot about.

Also, if you copied your original work directory from a test suite case, there may be hooks in run_star_extras.f that were relevant for the test but are not relevant to your experiment.

Very intriguing if it’s not one of these situations...

Bill

________________________ 
William Wolf 
wm...@ph... 

UCSB Department of Physics 

On March 21, 2017 at 11:45:41 AM, Catherine Lovekin (clo...@mt...) wrote:

Hi everyone,



I'm trying to run some rotating models (1.2-2.2 solar masses), and I've run into a problem.  For now, I'm trying to include rotation in the simplest way possible,  so I've got an inlist that has the following:

&star_job

   show_log_description_at_start = .false.

   eos_file_prefix = 'mesa'
   kappa_file_prefix = 'gs98'

   change_v_flag = .true.
   new_v_flag = .true.

   new_rotation_flag = .true.
   change_rotation_flag = .true.

   relax_initial_surface_rotation_v = .true.
   set_surface_rotation_v = .true.
   new_surface_rotation_v = 100
      

/ ! end of star_job namelist



When I run a model, it starts out with whatever rotation rate I set on the last line, but around 30 models in, I see:
 turn on rotation
                               new_surface_rotation_v =    4.5000000000000000D+01    3.7745766462731172D-05

and the rotation rate of my star drops.  I can confirm that this is what happens when I plot omega or v as a function of the age of the star. The rotation velocity starts out where I set it, and then drops to close to 45 km/s and evolves from there.  

 I get a surface rotation of 45 km/s for my model even if I comment all of the rotation commands out of my inlist, so it seems that my version of mesa is reading a velocity from somewhere else, or there's a default that isn't getting changed somehow.   I've tried deleting all my inlists and making new ones, as well as recompiling the code, but the problem doesn't go away.  Is there another rotation parameter I'm not setting, or another place I should be changing the rotation?  I'm running version 8845 on a Mac OSX 10.9.5.



Thanks,



Catherine



Catherine Lovekin
Assistant Professor
Department of Physics
Dunn 222
Mount Allison University
clo...@mt...
phone: (506) 364-2582
------------------------------------------------------------------------------  
Check out the vibrant tech community on one of the world's most  
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
mesa-users mailing list  
mes...@li...  
https://lists.sourceforge.net/lists/listinfo/mesa-users  

[mesa-users] adding rotation

[Catherine L. <clo...@mt...>]

Hi everyone,


I'm trying to run some rotating models (1.2-2.2 solar masses), and I've run into a problem.  For now, I'm trying to include rotation in the simplest way possible,  so I've got an inlist that has the following:

&star_job

   show_log_description_at_start = .false.

   eos_file_prefix = 'mesa'
   kappa_file_prefix = 'gs98'

   change_v_flag = .true.
   new_v_flag = .true.

   new_rotation_flag = .true.
   change_rotation_flag = .true.

   relax_initial_surface_rotation_v = .true.
   set_surface_rotation_v = .true.
   new_surface_rotation_v = 100


/ ! end of star_job namelist


When I run a model, it starts out with whatever rotation rate I set on the last line, but around 30 models in, I see:
 turn on rotation
                               new_surface_rotation_v =    4.5000000000000000D+01    3.7745766462731172D-05

and the rotation rate of my star drops.  I can confirm that this is what happens when I plot omega or v as a function of the age of the star. The rotation velocity starts out where I set it, and then drops to close to 45 km/s and evolves from there.

 I get a surface rotation of 45 km/s for my model even if I comment all of the rotation commands out of my inlist, so it seems that my version of mesa is reading a velocity from somewhere else, or there's a default that isn't getting changed somehow.   I've tried deleting all my inlists and making new ones, as well as recompiling the code, but the problem doesn't go away.  Is there another rotation parameter I'm not setting, or another place I should be changing the rotation?  I'm running version 8845 on a Mac OSX 10.9.5.


Thanks,


Catherine


Catherine Lovekin
Assistant Professor
Department of Physics
Dunn 222
Mount Allison University
clo...@mt...
phone: (506) 364-2582

[mesa-users] Bug in edot mechanism in binary module

[Glenn-Michael O. <gle...@ku...>]

Dear developers,


I would like to report on a bug in the binary_edot file. It concerns the tidal mechanism from Hut (1981).


In line 129 in the code, there is multiplied by pow_cr(1-b% eccentricity**2,6.5d0) instead of divided by it, which has huge implications once the eccentricity becomes large (suppose your eccentricity is 0.9, this results in a discrepancy of almost 10 orders of magnitude!).


So basically in binary_edot.f90, line 128-129:


edot_tidal = -27.0d0*qratio*(1+qratio)*pow8(r_phot/osep) &
            * b% eccentricity*pow_cr(1-b% eccentricity**2,6.5d0)*b% Ftid_1

should be

edot_tidal = -27.0d0*qratio*(1+qratio)*pow8(r_phot/osep) &
            * b% eccentricity*pow_cr(1-b% eccentricity**2,-6.5d0)*b% Ftid_1

as it is given in Eq. 10 of Hut (1981).

Cheers,
Glenn-Michael Oomen

Re: [mesa-users] Mesa - Postprocessing network

[Robert F. <rjf...@as...>]

Hi
You want to look at the net/test folder. There's a lot of examples there
for running the nuclear network with 1 zone. You'd set the t,rho and
composition in the corresponding inlists

Rob

On Sun, Mar 19, 2017 at 4:35 AM, Yossef Zenati <oyo...@gm...> wrote:

> Hi everyone,
>
> How can I run Mesa standalone
> network to post-process particle trajectories
> generated from other codes (e.g., flash)?
> Also, How to choose my output version (T,rho,composition,..)?
> Yossef
>
> --
> Yossef Zenati
> Physics Department
> Technion - Israel Institute of Technology
> Haifa, Israel 32000
>
> Office: Lidow Physics Complex, room 216
> Cell: 972-54-9929586 , Tel: 97248295782
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>

[mesa-users] Mesa - Postprocessing network

[Yossef Z. <oyo...@gm...>]

Hi everyone,

How can I run Mesa standalone
network to post-process particle trajectories
generated from other codes (e.g., flash)?
Also, How to choose my output version (T,rho,composition,..)?
Yossef

-- 
Yossef Zenati
Physics Department
Technion - Israel Institute of Technology
Haifa, Israel 32000

Office: Lidow Physics Complex, room 216
Cell: 972-54-9929586 , Tel: 97248295782

Re: [mesa-users] Fwd: Wind loss in MESA

[Jiri K. <kr...@mo...>]

Hi,

Just a comment: Please note that de Jager et al. 1988A&AS...72..259D wind 
mass-loss rates are based on observations of stars with log L>3, 
consequently using them for low-mass MS stars is a huge extrapolation.

Cheers,

Jiri

On Sat, 18 Mar 2017, Bill Paxton wrote:

> Hi,
>
> Glad to hear that you are using MESA again.
>
> I'm forwarding your question to mesa-users -- there are lots of experienced users who are happy to answer questions like this one.   Thanks for attaching the inlists; that's a big help.
>
> Cheers,
> Bill
>
>
>
> Begin forwarded message:
>
>> Resent-From: <pa...@ki...>
>> From: Alessandro Patruno <pa...@st...>
>> Date: March 18, 2017 10:00:08 AM PDT
>> To: pa...@ki...
>> Subject: Wind loss in MESA
>>
>
>> I am using the latest version (9575) and I am evolving a binary with a point mass and a low mass main sequence donor (say <1 Msun). In my simulations I want the donor star to begin with a certain rotational velocity, synchronize with the orbit and emit wind (enhanced by tidal effects). I see that in this version of MESA all this is possible and so I want to take advantage of this.
>>
>> However, I am having troubles to activate the wind loss in the low mass star. For some reason the code does not calculate any mass loss (wind) during the calculations and I do not know what I am doing wrong. The lg_wind_mdot_1 stays stuck at -99 throughout the simulation.
>>
>> Do you know how to activate a de Jager type mass loss during the main sequence of low mass stars?
>>
>>
>
>

Re: [mesa-users] Suppress H burning

[RICHARD H D T. <tow...@as...>]

> On Mar 18, 2017, at 1:37 PM, Josiah Schwab <jws...@uc...> wrote:
> 
> Hi Rich,
> 
>> That would work. But as someone who has never played with the nuclear
>> stuff in MESA, I’m at a loss how to start. Is there a tutorial on
>> modifying nets that I could follow?
> 
> Look at which net you're using.
> 
> Make a copy of that file from $MESA_DIR/data/net_data/nets into your
> work directory.
> 
>  cp $MESA_DIR/data/net_data/nets/basic.net no_burn_h.net
> 
> Open up no_burn_h.net in a text editor.  basic.net is quite readable.
> Comment out (or delete) the sections "pp chains" and "cno cycles".  The
> comment character is '!'.
> 
> Then, in star_job point MESA to your new net
> 
>  change_net = .true.
>  new_net_name = 'no_burn_h.net'
> 
> Josiah

Excellent — thanks to both of you!

Re: [mesa-users] Suppress H burning

[Josiah S. <jws...@uc...>]

Hi Rich,

> That would work. But as someone who has never played with the nuclear
> stuff in MESA, I’m at a loss how to start. Is there a tutorial on
> modifying nets that I could follow?

Look at which net you're using.

Make a copy of that file from $MESA_DIR/data/net_data/nets into your
work directory.

  cp $MESA_DIR/data/net_data/nets/basic.net no_burn_h.net

Open up no_burn_h.net in a text editor.  basic.net is quite readable.
Comment out (or delete) the sections "pp chains" and "cno cycles".  The
comment character is '!'.

Then, in star_job point MESA to your new net

  change_net = .true.
  new_net_name = 'no_burn_h.net'

Josiah

P.S.  Evan's suggestion is also great.

Re: [mesa-users] Suppress H burning

[Evan B. <eb...@ph...>]

I think the easier way to do this is using these star job controls:

         !### num_special_rate_factors
         !### reaction_for_special_factor
         !### special_rate_factor
         ! For using other special rate factors.
	 ! `num_special_rate_factors` must be <= `max_num_special_rate_factors`.

      num_special_rate_factors = 0
      reaction_for_special_factor(:) = ''
      special_rate_factor(:) = 1

Just set the “special_rate_factors” to 0d0 for anything you want to suppress.

Cheers,
Evan

> On Mar 18, 2017, at 1:29 PM, RICHARD H D TOWNSEND <tow...@as...> wrote:
> 
> That would work. But as someone who has never played with the nuclear stuff in MESA, I’m at a loss how to start. Is there a tutorial on modifying nets that I could follow?
> 
> cheers,
> 
> Rich
> 
>> On Mar 18, 2017, at 1:27 PM, Josiah Schwab <jws...@uc...> wrote:
>> 
>> can you just take those reactions out of your net?
>> 
>> -j
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users