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

Re: [mesa-users] Undocumented control in &controls: eos_partials_consistency_level

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

Hi Warrick,

On Apr 7, 2017, at 2:49 AM, Warrick Ball wrote:

> Hi everyone,
> 
> I'm still tinkering with solar models and noticed that I get quite a big 
> difference if I switch the opacity interpolation between linear and cubic 
> in X and Z.  

Good detective work!   Interesting to note that the "calibrated" results depend on the details of the non-physical numerics.  This is particularly noticeable for the eos and opacity results that depend on interpolating tables that are relatively sparse reflecting decisions made 20+ years ago taking into account the amount of RAM required to store them at runtime -- machine memory sizes have increased by factors of 10 while the tables are still at a resolution appropriate for a much different era.  The low resolution of the tables makes the results more vulnerable to interpolation issues.  

> Motivated by the recent thread on the interpolation of the 
> EoS [1] I tried digging around inside the EoS module to see what options 
> were available for deciding which interpolation to use in the EoS.

> 
> Along the way, I came across the control eos_partials_consistency_level in 
> &controls.  The documentation is empty [2] and the only test cases that 
> change its value from the default -1 are ccsn_IIp and envelope_inflation 
> (both of which set it to 1).  I assume consistency refers to thermodynamic 
> consistency.  My question to the forum is: what does this control do?
> 
> In principle, if I work through the code for long enough I should be 
> able to figure out what's going on.  But it'll be much faster if someone 
> else could explain it...  Just searching for consistency_level in 
> $MESA_DIR/eos/private/eosdt_eval.f90, it looks to me that as 
> consistency_level increases, so the order of derivatives that are 
> thermodynamically consistent increases too.  At consistency_level = 1 or 
> 2, the first derivatives are made consistent, and for consistency_level = 
> 3, the second derivatives are made consistent too.  I don't understand 
> what happens above level 4, though.  My suspicion is that a different kind 
> of interpolation is implemented for levels 4, 5 and 6 but I'm hoping 
> someone can correct me.



For an implicit solver like mesa/star, we need to have partials of the tabulated values as well as the basic values themselves -- for example, in addition to the value of the entropy as a function of logT and logRho,, we also need partials of the entropy with respect to logT and logRho.  And the same holds for values that are themselves partials of top level values (energy, gas pressure, entropy) such as adiabatic gradient, grad_ad.


In the case of the eos, the tables try to help with this by providing columns of data for the partials in addition to values for the top level values.  This has the value of giving you highly accurate values of the partials at grid points, but it doesn't solve the problem of interpolating to off grid locations. For mesa/star, we need to have the partials of the interpolating polynomial since that tells us how the results will behave when we make calls to the eos with slightly different arguments.  But the standard practice is to have the eos return interpolation of the partials instead of partials of the interpolating polynomials.   Seems like a minor difference that might actually be an improvement since it is using the information from the table.  But this means that the reported partials based on interpolating the tabulated partials will not be precisely the same as the partials of the interpolants -- in other words, the results will not be consistent, the reported partials will not be an accurate representation of the actual partials of the interpolated values even if they might be a better estimate of the values of the partials that would be calculated by the original routines that produced the data for the table.  Got it?

We have just muddled along with this inconsistency, but it has a downside.  Since mesa/star doesn't get accurate partials it cannot drive down the errors in the stellar models beyond the level set by the uncertainties.  This shows up in the residuals stalling in the newton iterations --- we cannot make the residuals tiny if we cannot predict how the new model because of imprecise partials.  For "normal" work, the inconsistencies in the partials are small enough that we just accept the failure to get tiny partials, i.e., we accept the failure to get models that solve the equations at the level of tiny residual errors.  But for "the era of high precision stellar astrophysics" we need something better.  We need to have consistent partials from the input physics for the eos.    

The "eos_partials_consistency_level" control is a part of an attempt to improve this situation.  As is the fate of most 1st efforts, it failed.   So this problem is still waiting for a good solution.  In the meantime we have a not-very-good partial semi-fix that sort-of works for a few special cases.  This is the "consistency_level = 1" option.  The higher number options have gone away in my current working version (not yet public).  But this one is still around since it is the least ambitious of the things we tried and at least helps sometimes.   It replaces the interpolated values of Cv, dS_dT, chiR, choRho, and gamma3 by expressions caclulated on the fly from the partials of the interpolants of lnE, lnS, and lnPgas.  Those particular cases are easy to do in that they don't require 2nd derivatives of lnE, lnS, or lnPgas.  So we do the easy ones and leave the rest alone (i.e., leave them as interpolated from tables rather than partials of interpolants).  The small section of code for this is in subroutine finish_partials in eos/private//eosdt_eval.f90.

You are of course welcome to try setting consistency level = 1.  It helps some cases and breaks others.  It is not a solution, and it is not even a very good workaround.

The problem of consistent partials from the eos is still with us, and until it is solved, we will be vulnerable to limited ability to drive down residual errors in the equations in mesa/star.

Finally, note that the situation in opacities is less difficult since we don't need 2nd derivatives of the opacity, and the tables don't include partials so there is no issue of interpolating tabulated partials.  The problem here is not the consistency of the partials, it is the low resolution of the tables increasing the opportunity for effects from different interpolating algorithms.   Going to higher order interpolation can help to a limited degree, but it introduces the danger of unphysical values caused by large jumps in the tabulated values such as at the hydrogen ionization temperature where the opacity drops sharply for small decreases in T.   Fine resolution in the tables is really the right solution, at least until we can do away with tables and just calculated everything on the fly (not going to happen soon).

Cheers,
Bill






> 
> Cheers,
> Warrick
> 
> [1] https://sourceforge.net/p/mesa/mailman/message/35754574/
> [2] http://mesa.sourceforge.net/controls_defaults.html#eos_partials_consistency_level
> 
> 
> ------------
> Warrick Ball
> Postdoc, School of Physics and Astronomy
> University of Birmingham, Edgbaston, Birmingham B15 2TT
> wb...@bi...
> +44 (0)121 414 4552
> 
> ------------------------------------------------------------------------------
> 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] Undocumented control in &controls: eos_partials_consistency_level

[Warrick B. <wb...@bi...>]

Hi everyone,

I'm still tinkering with solar models and noticed that I get quite a big 
difference if I switch the opacity interpolation between linear and cubic 
in X and Z.  Motivated by the recent thread on the interpolation of the 
EoS [1] I tried digging around inside the EoS module to see what options 
were available for deciding which interpolation to use in the EoS.

Along the way, I came across the control eos_partials_consistency_level in 
&controls.  The documentation is empty [2] and the only test cases that 
change its value from the default -1 are ccsn_IIp and envelope_inflation 
(both of which set it to 1).  I assume consistency refers to thermodynamic 
consistency.  My question to the forum is: what does this control do?

In principle, if I work through the code for long enough I should be 
able to figure out what's going on.  But it'll be much faster if someone 
else could explain it...  Just searching for consistency_level in 
$MESA_DIR/eos/private/eosdt_eval.f90, it looks to me that as 
consistency_level increases, so the order of derivatives that are 
thermodynamically consistent increases too.  At consistency_level = 1 or 
2, the first derivatives are made consistent, and for consistency_level = 
3, the second derivatives are made consistent too.  I don't understand 
what happens above level 4, though.  My suspicion is that a different kind 
of interpolation is implemented for levels 4, 5 and 6 but I'm hoping 
someone can correct me.

Cheers,
Warrick

[1] https://sourceforge.net/p/mesa/mailman/message/35754574/
[2] http://mesa.sourceforge.net/controls_defaults.html#eos_partials_consistency_level


------------
Warrick Ball
Postdoc, School of Physics and Astronomy
University of Birmingham, Edgbaston, Birmingham B15 2TT
wb...@bi...
+44 (0)121 414 4552

Re: [mesa-users] New to Mesa/Python Help

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

Hi Yinka,

> I have zero coding background and I would like to conduct and economic
> simulation (ABM) using this program. Am I able to do it? and second
> would anyone be willing to assist me? I have a research paper due next
> month.

This mailing list (mesa-users) is associated with Modules for
Experiments in Stellar Astrophysics.

You probably meant to contact people associated with this project:

  https://github.com/projectmesa/mesa

Good luck,
Josiah

Re: [mesa-users] Problem binding GYRE5.0rc1 in Mesa r9575

[<al...@ga...>]

Rich,

thanks for your information! I try to help fixing problems whenever  
possible but this one proved to be beyond me. Therefore, I switch to  
standby mode for the time being.

I really appreciate your efforts,
thanks, Alfred


> Hi Alfred —
>
> At the moment, building GYRE 5.0 inside MESA simply will not work —  
> I’ve not updated the interface module for a while. However, I’m  
> working on this and hope to have a fix in a day or so.
>
> cheers,
>
> Rich
>
>> On Apr 5, 2017, at 11:37 PM, al...@ga... wrote:
>>
>> Aaron
>>
>> thanks for the suggestion. I thought the ./clean was superfluous
>> because I started with
>> a Mesa installation from scratch. But I did a ./clean now, as suggested.
>> The ./clean scrubbed away the mesa/gyre/gyre directory where
>> previously the executables and compiled/linked routines from the
>> standalone-installation lived -- this is
>> just what should happen I suppose. Then, starting an ./install in mesa
>> works fine again to the end of
>>
>>         mesa/star has been built, tested, and exported.
>>
>> Then, the installation of the gyre package crashes at an earlier stage
>> than hitherto with:
>>
>>
>> make: *** Keine Regel vorhanden, um das Ziel „gyre_input.mod“,
>>   benötigt von „gyre_lib.o“, zu erstellen.  Schluss.
>>
>> /home/alfred/StarWare/Mesa/mesa/gyre/make
>> FAILED
>>
>>>>> translation: make: *** No rule found to generate target "gyre_input.mod",
>>                   which is used by "gyre_lib.o"
>>
>> Beats me even more than last night's experience.
>>
>> Alfred
>>
>>
>>
>>> Hi Alfred,
>>>
>>> Just a guess!  Did you do a ./clean in mesa/star before linking with the
>>> new version of GYRE?  It might be that your star module was built against
>>> the old version and is now confused by the new.
>>>
>>> Aaron
>>>
>>> On Wed, Apr 5, 2017 at 6:05 PM, <al...@ga...> wrote:
>>>
>>>>
>>>> Dear Blackbelters,
>>>>
>>>> recently I decided to upgrade to r9575 of Mesa; the undertaking was
>>>> painless and successful -- using GYRE 4.4, which comes with the Mesa
>>>> release. Motivated by Warrick's report on GYRE complaints I felt
>>>> forced to update also GYRE to 5.0rc1. Installing this latest GYRE
>>>> version in standalone mode (i.e. make in $GYRE_DIR) was successful and
>>>> all tests were passed successfully.  However, going back to the mesa
>>>> directory and doing a new ./install to bind GYRE to Mesa so that it
>>>> can be called from within Mesa fails; and it just beats me why that
>>>> happens.
>>>>
>>>> Here some lines of the terminal output during the installation
>>>> procedure in the mesa directory:
>>>>
>>>> ...
>>>> export
>>>> done
>>>>
>>>> mesa/star has been built, tested, and exported.
>>>>
>>>> ************************************************
>>>>
>>>> /home/alfred/StarWare/Mesa/mesa/gyre
>>>> building gyre package.
>>>>
>>>> gyre/
>>>> gyre/bin/
>>>> ...
>>>> ...
>>>> Unescaped left brace in regex is deprecated, passed through in regex;
>>>> marked by <-- HERE in m/\G{ <-- HERE / at
>>>> /home/alfred/mesasdk/bin/fpx3 line 261.
>>>> FC gyre_soln_seg.f90
>>>> FC gyre_soln.f90
>>>> FC gyre_evol_model.f90
>>>> gyre_evol_model.f90:2327:13:
>>>>
>>>>        where (pt%x /= 0._WP)
>>>>              1
>>>> Error: WHERE/ELSEWHERE clause at (1) requires a LOGICAL array
>>>> gyre_evol_model.f90:2328:9:
>>>>
>>>>           f = SQRT(MAX(As/c_1, 0._WP))/pt%x
>>>>          1
>>>> Error: WHERE assignment target at (1) has inconsistent shape
>>>> gyre_evol_model.f90:2330:9:
>>>>
>>>>           f = 0._WP
>>>>          1
>>>> Error: WHERE assignment target at (1) has inconsistent shape
>>>> gyre_evol_model.f90:2334:25:
>>>>
>>>>                  integrate(pt%x, f)
>>>>                          1
>>>> Error: There is no specific function for the generic 'integrate' at (1)
>>>> gyre_evol_model.f90:2299:25:
>>>>
>>>>                  integrate(pt%x, f)
>>>>                          1
>>>> Error: There is no specific function for the generic 'integrate' at (1)
>>>> makefile:73: die Regel für Ziel „gyre_evol_model.mod“ scheiterte
>>>> make: *** [gyre_evol_model.mod] Fehler 1
>>>>
>>>> /home/alfred/StarWare/Mesa/mesa/gyre/make
>>>> FAILED
>>>>
>>>>
>>>> What beats me is that apparently, in the standalone installation,
>>>> compiling/linking of *all* routines was successful.
>>>>
>>>> In terms of machine, I'm running ubuntu 16.04 LTS and the latest
>>>> release of mesasdk.
>>>>
>>>> Any hint or help is appreciated.
>>>>
>>>> Thanks, Alfred
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------
>>>> ------------------
>>>> 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
>>>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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] Problem binding GYRE5.0rc1 in Mesa r9575

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

Hi Alfred —

At the moment, building GYRE 5.0 inside MESA simply will not work — I’ve not updated the interface module for a while. However, I’m working on this and hope to have a fix in a day or so.

cheers,

Rich

> On Apr 5, 2017, at 11:37 PM, al...@ga... wrote:
> 
> Aaron
> 
> thanks for the suggestion. I thought the ./clean was superfluous  
> because I started with
> a Mesa installation from scratch. But I did a ./clean now, as suggested.
> The ./clean scrubbed away the mesa/gyre/gyre directory where
> previously the executables and compiled/linked routines from the  
> standalone-installation lived -- this is
> just what should happen I suppose. Then, starting an ./install in mesa  
> works fine again to the end of
> 
>         mesa/star has been built, tested, and exported.
> 
> Then, the installation of the gyre package crashes at an earlier stage  
> than hitherto with:
> 
> 
> make: *** Keine Regel vorhanden, um das Ziel „gyre_input.mod“,
>   benötigt von „gyre_lib.o“, zu erstellen.  Schluss.
> 
> /home/alfred/StarWare/Mesa/mesa/gyre/make
> FAILED
> 
>>>> translation: make: *** No rule found to generate target "gyre_input.mod",
>                   which is used by "gyre_lib.o"
> 
> Beats me even more than last night's experience.
> 
> Alfred
> 
> 
> 
>> Hi Alfred,
>> 
>> Just a guess!  Did you do a ./clean in mesa/star before linking with the
>> new version of GYRE?  It might be that your star module was built against
>> the old version and is now confused by the new.
>> 
>> Aaron
>> 
>> On Wed, Apr 5, 2017 at 6:05 PM, <al...@ga...> wrote:
>> 
>>> 
>>> Dear Blackbelters,
>>> 
>>> recently I decided to upgrade to r9575 of Mesa; the undertaking was
>>> painless and successful -- using GYRE 4.4, which comes with the Mesa
>>> release. Motivated by Warrick's report on GYRE complaints I felt
>>> forced to update also GYRE to 5.0rc1. Installing this latest GYRE
>>> version in standalone mode (i.e. make in $GYRE_DIR) was successful and
>>> all tests were passed successfully.  However, going back to the mesa
>>> directory and doing a new ./install to bind GYRE to Mesa so that it
>>> can be called from within Mesa fails; and it just beats me why that
>>> happens.
>>> 
>>> Here some lines of the terminal output during the installation
>>> procedure in the mesa directory:
>>> 
>>> ...
>>> export
>>> done
>>> 
>>> mesa/star has been built, tested, and exported.
>>> 
>>> ************************************************
>>> 
>>> /home/alfred/StarWare/Mesa/mesa/gyre
>>> building gyre package.
>>> 
>>> gyre/
>>> gyre/bin/
>>> ...
>>> ...
>>> Unescaped left brace in regex is deprecated, passed through in regex;
>>> marked by <-- HERE in m/\G{ <-- HERE / at
>>> /home/alfred/mesasdk/bin/fpx3 line 261.
>>> FC gyre_soln_seg.f90
>>> FC gyre_soln.f90
>>> FC gyre_evol_model.f90
>>> gyre_evol_model.f90:2327:13:
>>> 
>>>        where (pt%x /= 0._WP)
>>>              1
>>> Error: WHERE/ELSEWHERE clause at (1) requires a LOGICAL array
>>> gyre_evol_model.f90:2328:9:
>>> 
>>>           f = SQRT(MAX(As/c_1, 0._WP))/pt%x
>>>          1
>>> Error: WHERE assignment target at (1) has inconsistent shape
>>> gyre_evol_model.f90:2330:9:
>>> 
>>>           f = 0._WP
>>>          1
>>> Error: WHERE assignment target at (1) has inconsistent shape
>>> gyre_evol_model.f90:2334:25:
>>> 
>>>                  integrate(pt%x, f)
>>>                          1
>>> Error: There is no specific function for the generic 'integrate' at (1)
>>> gyre_evol_model.f90:2299:25:
>>> 
>>>                  integrate(pt%x, f)
>>>                          1
>>> Error: There is no specific function for the generic 'integrate' at (1)
>>> makefile:73: die Regel für Ziel „gyre_evol_model.mod“ scheiterte
>>> make: *** [gyre_evol_model.mod] Fehler 1
>>> 
>>> /home/alfred/StarWare/Mesa/mesa/gyre/make
>>> FAILED
>>> 
>>> 
>>> What beats me is that apparently, in the standalone installation,
>>> compiling/linking of *all* routines was successful.
>>> 
>>> In terms of machine, I'm running ubuntu 16.04 LTS and the latest
>>> release of mesasdk.
>>> 
>>> Any hint or help is appreciated.
>>> 
>>> Thanks, Alfred
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------
>>> ------------------
>>> 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
>>> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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] Problem binding GYRE5.0rc1 in Mesa r9575

[<al...@ga...>]

Aaron

thanks for the suggestion. I thought the ./clean was superfluous  
because I started with
a Mesa installation from scratch. But I did a ./clean now, as suggested.
The ./clean scrubbed away the mesa/gyre/gyre directory where
previously the executables and compiled/linked routines from the  
standalone-installation lived -- this is
just what should happen I suppose. Then, starting an ./install in mesa  
works fine again to the end of

         mesa/star has been built, tested, and exported.

Then, the installation of the gyre package crashes at an earlier stage  
than hitherto with:


make: *** Keine Regel vorhanden, um das Ziel „gyre_input.mod“,
   benötigt von „gyre_lib.o“, zu erstellen.  Schluss.

/home/alfred/StarWare/Mesa/mesa/gyre/make
FAILED

>>> translation: make: *** No rule found to generate target "gyre_input.mod",
                   which is used by "gyre_lib.o"

Beats me even more than last night's experience.

Alfred



> Hi Alfred,
>
> Just a guess!  Did you do a ./clean in mesa/star before linking with the
> new version of GYRE?  It might be that your star module was built against
> the old version and is now confused by the new.
>
> Aaron
>
> On Wed, Apr 5, 2017 at 6:05 PM, <al...@ga...> wrote:
>
>>
>> Dear Blackbelters,
>>
>> recently I decided to upgrade to r9575 of Mesa; the undertaking was
>> painless and successful -- using GYRE 4.4, which comes with the Mesa
>> release. Motivated by Warrick's report on GYRE complaints I felt
>> forced to update also GYRE to 5.0rc1. Installing this latest GYRE
>> version in standalone mode (i.e. make in $GYRE_DIR) was successful and
>> all tests were passed successfully.  However, going back to the mesa
>> directory and doing a new ./install to bind GYRE to Mesa so that it
>> can be called from within Mesa fails; and it just beats me why that
>> happens.
>>
>> Here some lines of the terminal output during the installation
>> procedure in the mesa directory:
>>
>> ...
>> export
>> done
>>
>> mesa/star has been built, tested, and exported.
>>
>> ************************************************
>>
>> /home/alfred/StarWare/Mesa/mesa/gyre
>> building gyre package.
>>
>> gyre/
>> gyre/bin/
>> ...
>> ...
>> Unescaped left brace in regex is deprecated, passed through in regex;
>> marked by <-- HERE in m/\G{ <-- HERE / at
>> /home/alfred/mesasdk/bin/fpx3 line 261.
>> FC gyre_soln_seg.f90
>> FC gyre_soln.f90
>> FC gyre_evol_model.f90
>> gyre_evol_model.f90:2327:13:
>>
>>         where (pt%x /= 0._WP)
>>               1
>> Error: WHERE/ELSEWHERE clause at (1) requires a LOGICAL array
>> gyre_evol_model.f90:2328:9:
>>
>>            f = SQRT(MAX(As/c_1, 0._WP))/pt%x
>>           1
>> Error: WHERE assignment target at (1) has inconsistent shape
>> gyre_evol_model.f90:2330:9:
>>
>>            f = 0._WP
>>           1
>> Error: WHERE assignment target at (1) has inconsistent shape
>> gyre_evol_model.f90:2334:25:
>>
>>                   integrate(pt%x, f)
>>                           1
>> Error: There is no specific function for the generic 'integrate' at (1)
>> gyre_evol_model.f90:2299:25:
>>
>>                   integrate(pt%x, f)
>>                           1
>> Error: There is no specific function for the generic 'integrate' at (1)
>> makefile:73: die Regel für Ziel „gyre_evol_model.mod“ scheiterte
>> make: *** [gyre_evol_model.mod] Fehler 1
>>
>> /home/alfred/StarWare/Mesa/mesa/gyre/make
>> FAILED
>>
>>
>> What beats me is that apparently, in the standalone installation,
>> compiling/linking of *all* routines was successful.
>>
>> In terms of machine, I'm running ubuntu 16.04 LTS and the latest
>> release of mesasdk.
>>
>> Any hint or help is appreciated.
>>
>> Thanks, Alfred
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> 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] Problem binding GYRE5.0rc1 in Mesa r9575

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

Hi Alfred,

Just a guess!  Did you do a ./clean in mesa/star before linking with the
new version of GYRE?  It might be that your star module was built against
the old version and is now confused by the new.

Aaron

On Wed, Apr 5, 2017 at 6:05 PM, <al...@ga...> wrote:

>
> Dear Blackbelters,
>
> recently I decided to upgrade to r9575 of Mesa; the undertaking was
> painless and successful -- using GYRE 4.4, which comes with the Mesa
> release. Motivated by Warrick's report on GYRE complaints I felt
> forced to update also GYRE to 5.0rc1. Installing this latest GYRE
> version in standalone mode (i.e. make in $GYRE_DIR) was successful and
> all tests were passed successfully.  However, going back to the mesa
> directory and doing a new ./install to bind GYRE to Mesa so that it
> can be called from within Mesa fails; and it just beats me why that
> happens.
>
> Here some lines of the terminal output during the installation
> procedure in the mesa directory:
>
> ...
> export
> done
>
> mesa/star has been built, tested, and exported.
>
> ************************************************
>
> /home/alfred/StarWare/Mesa/mesa/gyre
> building gyre package.
>
> gyre/
> gyre/bin/
> ...
> ...
> Unescaped left brace in regex is deprecated, passed through in regex;
> marked by <-- HERE in m/\G{ <-- HERE / at
> /home/alfred/mesasdk/bin/fpx3 line 261.
> FC gyre_soln_seg.f90
> FC gyre_soln.f90
> FC gyre_evol_model.f90
> gyre_evol_model.f90:2327:13:
>
>         where (pt%x /= 0._WP)
>               1
> Error: WHERE/ELSEWHERE clause at (1) requires a LOGICAL array
> gyre_evol_model.f90:2328:9:
>
>            f = SQRT(MAX(As/c_1, 0._WP))/pt%x
>           1
> Error: WHERE assignment target at (1) has inconsistent shape
> gyre_evol_model.f90:2330:9:
>
>            f = 0._WP
>           1
> Error: WHERE assignment target at (1) has inconsistent shape
> gyre_evol_model.f90:2334:25:
>
>                   integrate(pt%x, f)
>                           1
> Error: There is no specific function for the generic 'integrate' at (1)
> gyre_evol_model.f90:2299:25:
>
>                   integrate(pt%x, f)
>                           1
> Error: There is no specific function for the generic 'integrate' at (1)
> makefile:73: die Regel für Ziel „gyre_evol_model.mod“ scheiterte
> make: *** [gyre_evol_model.mod] Fehler 1
>
> /home/alfred/StarWare/Mesa/mesa/gyre/make
> FAILED
>
>
> What beats me is that apparently, in the standalone installation,
> compiling/linking of *all* routines was successful.
>
> In terms of machine, I'm running ubuntu 16.04 LTS and the latest
> release of mesasdk.
>
> Any hint or help is appreciated.
>
> Thanks, Alfred
>
>
>
> ------------------------------------------------------------
> ------------------
> 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] Problem binding GYRE5.0rc1 in Mesa r9575

[<al...@ga...>]

Dear Blackbelters,

recently I decided to upgrade to r9575 of Mesa; the undertaking was  
painless and successful -- using GYRE 4.4, which comes with the Mesa  
release. Motivated by Warrick's report on GYRE complaints I felt  
forced to update also GYRE to 5.0rc1. Installing this latest GYRE  
version in standalone mode (i.e. make in $GYRE_DIR) was successful and  
all tests were passed successfully.  However, going back to the mesa  
directory and doing a new ./install to bind GYRE to Mesa so that it  
can be called from within Mesa fails; and it just beats me why that  
happens.

Here some lines of the terminal output during the installation  
procedure in the mesa directory:

...
export
done

mesa/star has been built, tested, and exported.

************************************************

/home/alfred/StarWare/Mesa/mesa/gyre
building gyre package.

gyre/
gyre/bin/
...
...
Unescaped left brace in regex is deprecated, passed through in regex;  
marked by <-- HERE in m/\G{ <-- HERE / at  
/home/alfred/mesasdk/bin/fpx3 line 261.
FC gyre_soln_seg.f90
FC gyre_soln.f90
FC gyre_evol_model.f90
gyre_evol_model.f90:2327:13:

        where (pt%x /= 0._WP)
              1
Error: WHERE/ELSEWHERE clause at (1) requires a LOGICAL array
gyre_evol_model.f90:2328:9:

           f = SQRT(MAX(As/c_1, 0._WP))/pt%x
          1
Error: WHERE assignment target at (1) has inconsistent shape
gyre_evol_model.f90:2330:9:

           f = 0._WP
          1
Error: WHERE assignment target at (1) has inconsistent shape
gyre_evol_model.f90:2334:25:

                  integrate(pt%x, f)
                          1
Error: There is no specific function for the generic 'integrate' at (1)
gyre_evol_model.f90:2299:25:

                  integrate(pt%x, f)
                          1
Error: There is no specific function for the generic 'integrate' at (1)
makefile:73: die Regel für Ziel „gyre_evol_model.mod“ scheiterte
make: *** [gyre_evol_model.mod] Fehler 1

/home/alfred/StarWare/Mesa/mesa/gyre/make
FAILED


What beats me is that apparently, in the standalone installation,  
compiling/linking of *all* routines was successful.

In terms of machine, I'm running ubuntu 16.04 LTS and the latest  
release of mesasdk.

Any hint or help is appreciated.

Thanks, Alfred

Re: [mesa-users] Bug report? GYRE file header has incorrect number of columns

[Warrick B. <wb...@bi...>]

Hi Rich,

Aha!  I downloaded GYRE 5.0rc1 and can confirm that the MESA output file 
works fine with that version.  Thanks for the quick response.

Cheers,
Warrick


------------
Warrick Ball
Postdoc, School of Physics and Astronomy
University of Birmingham, Edgbaston, Birmingham B15 2TT
wb...@bi...
+44 (0)121 414 4552

On Mon, 3 Apr 2017, RICHARD H D TOWNSEND wrote:

> Hi Warrick —
> 
> Thanks for your detailed report. In this case, its a big “mea culpa”.
> 
> The latest version of MESA (r9575) is behaving quite correctly, in that it is writing out stellar models in an updated version (v1.00) of the GYRE format. In this updated format, the integer at the end of
> the header line now indicates the version number divided by 100, and not the number of columns. Version 1.00 differs from the previous version (v0.19) in that it allows double points to represent density
> discontinuities, plus the interpretation of the opacity derivatives in columns 14 and 15 has changed (see the attached document).
> 
> The reason why you’re running into difficulty with GYRE is that the version (4.4) which shipped with MESA r9575 is rather old, and cannot properly handle v1.00-format model files. The fix is to upgrade to
> the latet version of GYRE, which is 5.0rc1. If you just edit the model file to change 100 to 19, that will cause problems in non-adiabatic calculations due to the change in the opacity derivative
> interpretation.
> 
> I’m hoping to get a more up-to-date version of GYRE into MESA for the next release.
> 
> cheers,
> 
> Rich
> 
> 
> 
> > On Apr 3, 2017, at 1:45 AM, Warrick Ball <wb...@bi...> wrote:
> >
> > Hi,
> >
> > I'm not sure if I'm misusing something but I tried to use GYRE's non-adiabatic binary to calculate the mode frequencies for a GYRE-format file from MESA and ran into an error.  I've attached an inlist for
> r9575 that I used to produce the attached GYRE input file (`inlist_project`), the GYRE-format stellar model file (`test.gyre`), and the GYRE inlist that I used to compute frequencies (`gyre_nad.in`,
> basically just a copy of $GYRE_DIR/test/nad/mesa/spb/gyre_nad.in).
> >
> > Using the version of GYRE distributed with MESA (i.e. I have GYRE_DIR=$MESA_DIR/gyre/gyre, which I presume is okay?), I tried to compute the mode frequencies with `gyre_nad gyre_nad.in` and got the error:
> >
> >    Reading from MESA file test.gyre
> >       Detected new-variant file
> >     ASSERT 'k == k_chk' failed at line 303 <gyre_mesa_file:read_mesa_data:read_mesa_data_new_>:
> >     Index mismatch
> >
> > at which point the calculation halts.  I followed the error message in GYRE and I think the problem is that the last integer in the first row of the GYRE file should be the number of columns (also, it's in
> the docs [1]).  But in the file produced by MESA, I have
> >
> >      1046     2.9837999999999999E+34     3.5101730384066974E+11     6.9329640876084185E+37    100
> >
> > Looking at the file, there are clearly not 100 columns, and if I change the last 100 to the correct number of columns (19), the calculation proceeds.
> >
> > So, using my standard MESA sleuthing methods (i.e. grep a relevant control and start following function calls), I found the the GYRE data is written by write_gyre_data in
> $MESA_DIR/star/private/pulse_gyre.f90:397-451.  In particular, the subroutine writes the first line of the GYRE file on line 434 in the code:
> >
> >    write(iounit, 100) nn, global_data, 100
> >
> > So I think the bug is that hardcoded 100.  I'm not so familiar with standard Fortran operations but I would guess that the 100 should be replaced with `SIZE(point_data, 1)+1`.  (The extra column is the row
> number, which isn't in `point_data`.)
> >
> > Cheers,
> > Warrick
> >
> > [1] $GYRE_DIR/doc/mesa-format.pdf
> >
> > ------------
> > Warrick Ball
> > Postdoc, School of Physics and Astronomy
> > University of Birmingham, Edgbaston, Birmingham B15 2TT
> > wb...@bi...
> > +44 (0)121 414 4552<inlist_project.txt><test.gyre><gyre_nad.in>------------------------------------------------------------------------------
> > 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] New to Mesa/Python Help

[yinka d. <yi...@ya...>]

Greetings all,
I have zero coding background and I would like to conduct and economic simulation (ABM) using this program. Am I able to do it? and second would anyone be willing to assist me? I have a research paper due next month.
Thank you.

Re: [mesa-users] Angular momentum loss from mass loss clarification

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

Hi Kenny. mdot_system_transfer contains the amount of mass lost from mass
transfer, in terms of the mass_transfer_alpha and mass_transfer_beta
parameters (check the explanation for these in the defaults
http://mesa.sourceforge.net/binary_controls_defaults.html). So, barring
Eddington limited mass transfer, you have that

b% mdot_system_transfer(b% d_i) = b% mtransfer_rate * b% mass_transfer_alpha
b% mdot_system_transfer(b% a_i) = b% mtransfer_rate * b% mass_transfer_beta

In the case where mass accretion is limited by the Eddington rate, then b%
mdot_system_transfer(b% a_i) includes the amount of mass lost due to that
as well.

Cheers

On Mon, Apr 3, 2017 at 5:21 PM, Kenny Van <kv...@ua...> wrote:

> Hi,
>
> A question for clarity, in the binary_jdot.f90 the subroutine that
> describes angular momentum loss from mass loss in the system is calculated
> using:
>
>          !mass lost from vicinity of donor
>
>          b% jdot_ml = (b% mdot_system_transfer(b% d_i) + b%
> mdot_system_wind(b% d_i))*&
>              (b% m(b% a_i)/(b% m(b% a_i)+b% m(b% d_i))*b%
> separation)**2*2*pi/b% period *&
>              sqrt(1 - b% eccentricity**2)
>          !mass lost from vicinity of accretor
>
>          b% jdot_ml = b% jdot_ml + (b% mdot_system_transfer(b% a_i) + b%
> mdot_system_wind(b% a_i))*&
>              (b% m(b% d_i)/(b% m(b% a_i)+b% m(b% d_i))*b%
> separation)**2*2*pi/b% period *&
>              sqrt(1 - b% eccentricity**2)
>
> ignoring the cct term.
>
> I have a bit of confusion with the two mdot_system_transfer values. From
> going through the code in the binary_mdot.f90 file it looks like
>
> mdot_system_transfer(b% d_i)
> describes the mass loss from the donor, where some percentage of this mass
> (1- alpha) is just lost from the system.
>
> mdot_system_transfer(b% a_i)
> describes the mass that is lost from the donor and some percentage of this
> is not accreted by the compact object and thus lost from the system.
>
> Could someone verify this?
>
> Thanks
>
> ------------------------------------------------------------
> ------------------
> 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] Angular momentum loss from mass loss clarification

[Kenny V. <kv...@ua...>]

Hi,

A question for clarity, in the binary_jdot.f90 the subroutine that
describes angular momentum loss from mass loss in the system is calculated
using:

         !mass lost from vicinity of donor

         b% jdot_ml = (b% mdot_system_transfer(b% d_i) + b%
mdot_system_wind(b% d_i))*&
             (b% m(b% a_i)/(b% m(b% a_i)+b% m(b% d_i))*b%
separation)**2*2*pi/b% period *&
             sqrt(1 - b% eccentricity**2)
         !mass lost from vicinity of accretor

         b% jdot_ml = b% jdot_ml + (b% mdot_system_transfer(b% a_i) + b%
mdot_system_wind(b% a_i))*&
             (b% m(b% d_i)/(b% m(b% a_i)+b% m(b% d_i))*b%
separation)**2*2*pi/b% period *&
             sqrt(1 - b% eccentricity**2)

ignoring the cct term.

I have a bit of confusion with the two mdot_system_transfer values. From
going through the code in the binary_mdot.f90 file it looks like

mdot_system_transfer(b% d_i)
describes the mass loss from the donor, where some percentage of this mass
(1- alpha) is just lost from the system.

mdot_system_transfer(b% a_i)
describes the mass that is lost from the donor and some percentage of this
is not accreted by the compact object and thus lost from the system.

Could someone verify this?

Thanks

Re: [mesa-users] Bug report? GYRE file header has incorrect number of columns

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

Hi Warrick —

Thanks for your detailed report. In this case, its a big “mea culpa”.

The latest version of MESA (r9575) is behaving quite correctly, in that it is writing out stellar models in an updated version (v1.00) of the GYRE format. In this updated format, the integer at the end of the header line now indicates the version number divided by 100, and not the number of columns. Version 1.00 differs from the previous version (v0.19) in that it allows double points to represent density discontinuities, plus the interpretation of the opacity derivatives in columns 14 and 15 has changed (see the attached document).

The reason why you’re running into difficulty with GYRE is that the version (4.4) which shipped with MESA r9575 is rather old, and cannot properly handle v1.00-format model files. The fix is to upgrade to the latet version of GYRE, which is 5.0rc1. If you just edit the model file to change 100 to 19, that will cause problems in non-adiabatic calculations due to the change in the opacity derivative interpretation.

I’m hoping to get a more up-to-date version of GYRE into MESA for the next release.

cheers,

Rich



> On Apr 3, 2017, at 1:45 AM, Warrick Ball <wb...@bi...> wrote:
>
> Hi,
>
> I'm not sure if I'm misusing something but I tried to use GYRE's non-adiabatic binary to calculate the mode frequencies for a GYRE-format file from MESA and ran into an error.  I've attached an inlist for r9575 that I used to produce the attached GYRE input file (`inlist_project`), the GYRE-format stellar model file (`test.gyre`), and the GYRE inlist that I used to compute frequencies (`gyre_nad.in`, basically just a copy of $GYRE_DIR/test/nad/mesa/spb/gyre_nad.in).
>
> Using the version of GYRE distributed with MESA (i.e. I have GYRE_DIR=$MESA_DIR/gyre/gyre, which I presume is okay?), I tried to compute the mode frequencies with `gyre_nad gyre_nad.in` and got the error:
>
>    Reading from MESA file test.gyre
>       Detected new-variant file
>     ASSERT 'k == k_chk' failed at line 303 <gyre_mesa_file:read_mesa_data:read_mesa_data_new_>:
>     Index mismatch
>
> at which point the calculation halts.  I followed the error message in GYRE and I think the problem is that the last integer in the first row of the GYRE file should be the number of columns (also, it's in the docs [1]).  But in the file produced by MESA, I have
>
>      1046     2.9837999999999999E+34     3.5101730384066974E+11     6.9329640876084185E+37    100
>
> Looking at the file, there are clearly not 100 columns, and if I change the last 100 to the correct number of columns (19), the calculation proceeds.
>
> So, using my standard MESA sleuthing methods (i.e. grep a relevant control and start following function calls), I found the the GYRE data is written by write_gyre_data in $MESA_DIR/star/private/pulse_gyre.f90:397-451.  In particular, the subroutine writes the first line of the GYRE file on line 434 in the code:
>
>    write(iounit, 100) nn, global_data, 100
>
> So I think the bug is that hardcoded 100.  I'm not so familiar with standard Fortran operations but I would guess that the 100 should be replaced with `SIZE(point_data, 1)+1`.  (The extra column is the row number, which isn't in `point_data`.)
>
> Cheers,
> Warrick
>
> [1] $GYRE_DIR/doc/mesa-format.pdf
>
> ------------
> Warrick Ball
> Postdoc, School of Physics and Astronomy
> University of Birmingham, Edgbaston, Birmingham B15 2TT
> wb...@bi...
> +44 (0)121 414 4552<inlist_project.txt><test.gyre><gyre_nad.in>------------------------------------------------------------------------------
> 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] Cepheid variability with MESA's hydrodynamic mode?

[Warrick B. <wb...@bi...>]

Hi everyone,

I won't bore you with how, but at some point I came to wonder whether 
MESA, given its hydrodynamic abilities, would be able to follow the 
pulsations of large-amplitude classical oscillators like Cepheids.  After 
all, Paper III already showed that it's possible to get red supergiant 
pulsations.  So, a few weeks ago, I finally got around to trying to land a 
model in the classical instability strip, then taking that model and 
running it with the velocity variable turned on and nuclear reactions 
turned off (which probably doesn't matter), just to see if it would start 
to oscillate.  I had already read in Yoon & Cantiello (2010) and 
references therein that the timestep would have to be small (much shorter 
than the pulsation period) for the implicit time integration not to 
squelch the pulsations.

Luckily, I seemed to land a suitable model more or less from the get go, 
which I ran with something like the attached inlist.  It took a long time 
for the pulsations to build up (that run has now been going for many 
days), so I've also attached a model from somewhere during the "evolution" 
so you can reproduce this result.  Finally, I've also attached a plot of 
the luminosity as a function of age using this inlist and model, for the 
first 5000 steps (or about 2 periods) so you can see that the star does 
indeed pulsate.  It's quite messy, though the radius as a function of age 
is much smoother.  Also, though it takes a long time to appear, there are 
plenty of long term modulations, even after the apparent limiting 
amplitude (about 0.8 dex) is reached.  (If anyone is interested in the 
much longer "time series" I've computed, I have a 1.2GB history file to 
offer...)

Once I found the model pulsating, I tried to consult some literature to 
see if I could work out what was going on, since I know nearly nothing 
about modelling this kind of thing but I think I'd need much more time to 
really understand what's going on.  My experiment is probably the most 
naive possible way of approaching the problem.  I'm aware, for example, 
that by using MLT the model lacks any interaction between pulsation and 
convection.  I also haven't used (or don't think I've used?) any of the 
artificial viscosity terms available in MESA, though I'm under the 
impression that Cepheid/RR Lyrae hydro models use a different kind of 
artificial viscosity from what's described in MESA III.  I also simply 
allowed the numerical noise to slowly grow into the large amplitude 
pulsations now present in the model.  So I didn't initiate the pulsation 
using eigenfunctions from a linear analysis, nor am I in any way filtering 
out other modes (as seemed to be the case in Stobie 1969). I also honestly 
haven't had time to try to work out the details of what's going on inside 
the model.  All I've really glanced at so far are the surface properties.

My question, then, is: what would it take to make MESA capable of 
modelling Cepheid light curves, even to some basic level?  Is it 
interesting, worthwhile, or even possible?  I'd love to hear from anyone 
who has some experience in this area!

Cheers,
Warrick

PS:  One of the more useful starting points I found for my literature 
search was Radosław Smolec's PhD thesis:

http://users.camk.edu.pl/smolec/phd_smolec.pdf


------------
Warrick Ball
Postdoc, School of Physics and Astronomy
University of Birmingham, Edgbaston, Birmingham B15 2TT
wb...@bi...
+44 (0)121 414 4552

[mesa-users] Bug report? GYRE file header has incorrect number of columns

[Warrick B. <wb...@bi...>]

Hi,

I'm not sure if I'm misusing something but I tried to use GYRE's 
non-adiabatic binary to calculate the mode frequencies for a GYRE-format 
file from MESA and ran into an error.  I've attached an inlist for r9575 
that I used to produce the attached GYRE input file (`inlist_project`), 
the GYRE-format stellar model file (`test.gyre`), and the GYRE inlist that 
I used to compute frequencies (`gyre_nad.in`, basically just a copy of 
$GYRE_DIR/test/nad/mesa/spb/gyre_nad.in).

Using the version of GYRE distributed with MESA (i.e. I have 
GYRE_DIR=$MESA_DIR/gyre/gyre, which I presume is okay?), I tried to 
compute the mode frequencies with `gyre_nad gyre_nad.in` and got the 
error:

     Reading from MESA file test.gyre
        Detected new-variant file
      ASSERT 'k == k_chk' failed at line 303 <gyre_mesa_file:read_mesa_data:read_mesa_data_new_>:
      Index mismatch

at which point the calculation halts.  I followed the error message in 
GYRE and I think the problem is that the last integer in the first row of 
the GYRE file should be the number of columns (also, it's in the docs 
[1]).  But in the file produced by MESA, I have

       1046     2.9837999999999999E+34     3.5101730384066974E+11     6.9329640876084185E+37    100

Looking at the file, there are clearly not 100 columns, and if I change 
the last 100 to the correct number of columns (19), the calculation 
proceeds.

So, using my standard MESA sleuthing methods (i.e. grep a relevant control 
and start following function calls), I found the the GYRE data is written 
by write_gyre_data in $MESA_DIR/star/private/pulse_gyre.f90:397-451.  In 
particular, the subroutine writes the first line of the GYRE file on line 
434 in the code:

     write(iounit, 100) nn, global_data, 100

So I think the bug is that hardcoded 100.  I'm not so familiar with 
standard Fortran operations but I would guess that the 100 should be 
replaced with `SIZE(point_data, 1)+1`.  (The extra column is the row 
number, which isn't in `point_data`.)

Cheers,
Warrick

[1] $GYRE_DIR/doc/mesa-format.pdf

------------
Warrick Ball
Postdoc, School of Physics and Astronomy
University of Birmingham, Edgbaston, Birmingham B15 2TT
wb...@bi...
+44 (0)121 414 4552

Re: [mesa-users] running on xsede?

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

I’m running on SDSC Comet through XSEDE from time to time.

Evan


> On Mar 31, 2017, at 7:37 PM, Frank Timmes <fx...@ma...> wrote:
> 
> anyone running mesa on xsede resources?
> 
> fxt
> 
> 
> ------------------------------------------------------------------------------
> 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] running on xsede?

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

Hi Frank,

I run MESA on comet regularly.

Aaron

On Friday, March 31, 2017, Frank Timmes <fx...@ma...> wrote:

> anyone running mesa on xsede resources?
>
> fxt
>
>
> ------------------------------------------------------------
> ------------------
> 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... <javascript:;>
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>

[mesa-users] running on xsede?

[Frank T. <fx...@ma...>]

anyone running mesa on xsede resources?

fxt

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

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

 Dear Rob,

I got it. Thank you!




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 

From: Robert Farmer
Date: 2017-04-01 02:09
To: let
CC: mesa-users
Subject: Re: Re: [mesa-users] which file creates the reaction rates binary files?
Hi

So firstly the easiest way to see the exact rate mesa used is to do:


cd $MESA_DIR/rates/test

./show_rates ../../data/rates_data/cache/r_he3_ag_be7_1.bin



This outputs as plain text the rate mesa uses.


As to where mesa gets the rate from, by default MESA uses NACRE rates and falls back on JINA rates if NACRE is missing them/outside of JINAs temperature range



You need to set:
      set_rates_preference = .true.
      new_rates_preference = 2


in you star_job inlist to get only the JINA rates (or new_rates_preference = 1 to get only NACRE). So in this case i think we are using the rate from the  subroutine rate_he3he4_nacre in $MESA_DIR/rates/private/ratelib.f90


You can of course always set your own rates (see the custom_rate_c14ago18 test suite case as an example) for complete control over what MESA is doing



Rob



On Thu, Mar 30, 2017 at 7:22 PM, 李二涛 <le...@sz...> wrote:



 Dear Rob,

What I really want to know is the exact reaction rates expression which is used to create the binary file. I noticed that there are several sets of data for a reaction in mesa/data/rates_data/jina_reaclib_results_20130213default2. Take 3He(a,g)7Be reaction for example, there are four sets of data about the reaction:
4
       he4  he3  be7                       cd08n     1.58610e+00          
 1.770750e+01 0.000000e+00-1.282710e+01-3.812600e+00                      
 9.422850e-02-3.010180e-03 1.333330e+00                                   
4
       he4  he3  be7                       cd08n     1.58610e+00          
 1.560990e+01 0.000000e+00-1.282710e+01-3.082250e-02                      
-6.546850e-01 8.963310e-02-6.666670e-01  
2
       be7  he4  he3                       cd08nv   -1.58610e+00          
 4.083550e+01-1.840590e+01-1.282710e+01-3.812600e+00                      
 9.422850e-02-3.010180e-03 2.833330e+00                                   
2
       be7  he4  he3                       cd08nv   -1.58610e+00          
 3.873790e+01-1.840590e+01-1.282710e+01-3.082250e-02                      
-6.546850e-01 8.963310e-02 8.333330e-01 
I think that one of the first two sets of data is used to create the 3He(a,g)7Be reaction rates, and one of the last two sets of data is used to create the reverse reaction rates. But after I put the numbers into the formula: rate = Exp[ a0 + a1/T9 + a2/T91/3 + a3*T91/3 + a4*T9 + a5*T95/3 + a6*log(T9) ], I can't get the same results with the binary file. So I am wondering how can I get the exact reaction rates expression which is used by the MESA.

Thanks.




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 

From: Robert Farmer
Date: 2017-03-29 11:42
To: let
CC: mesa-users
Subject: Re: [mesa-users] which file creates the reaction rates binary files?
Hi


There is a binary file version of the jina rates stored in $MESA_DIR/data/rates_data/cache/jina_reaclib.bin which we use after the first run so once the text file is gone we use that (if you didn't add an empty file you would get an error message about the text file missing)


Deleting these files seems an unusual thing to do, if you explain what you want to do with the rates, we might be able to suggest a better way to do things.


Rob



On Tue, Mar 28, 2017 at 7:44 PM, 李二涛 <le...@sz...> wrote:



 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 
 
 

 


------------------------------------------------------------------------------
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] which file creates the reaction rates binary files?

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

Hi
So firstly the easiest way to see the exact rate mesa used is to do:

cd $MESA_DIR/rates/test
./show_rates ../../data/rates_data/cache/r_he3_ag_be7_1.bin

This outputs as plain text the rate mesa uses.

As to where mesa gets the rate from, by default MESA uses NACRE rates and
falls back on JINA rates if NACRE is missing them/outside of JINAs
temperature range

You need to set:
      set_rates_preference = .true.
      new_rates_preference = 2

in you star_job inlist to get only the JINA rates (or new_rates_preference
= 1 to get only NACRE). So in this case i think we are using the rate from
the  subroutine rate_he3he4_nacre in $MESA_DIR/rates/private/ratelib.f90

You can of course always set your own rates (see the custom_rate_c14ago18
test suite case as an example) for complete control over what MESA is doing

Rob

On Thu, Mar 30, 2017 at 7:22 PM, 李二涛 <le...@sz...> wrote:

>
>
> Dear Rob,
>
> What I really want to know is the exact reaction rates expression which is
> used to create the binary file. I noticed that there are several sets of
> data for a reaction in mesa/data/rates_data/jina_reaclib_results_
> 20130213default2. Take 3He(a,g)7Be reaction for example, there are four
> sets of data about the reaction:
> 4
>        he4  he3  be7                       cd08n     1.58610e+00
>  1.770750e+01 0.000000e+00-1.282710e+01-3.812600e+00
>  9.422850e-02-3.010180e-03 1.333330e+00
> 4
>        he4  he3  be7                       cd08n     1.58610e+00
>  1.560990e+01 0.000000e+00-1.282710e+01-3.082250e-02
> -6.546850e-01 8.963310e-02-6.666670e-01
> 2
>        be7  he4  he3                       cd08nv   -1.58610e+00
>  4.083550e+01-1.840590e+01-1.282710e+01-3.812600e+00
>  9.422850e-02-3.010180e-03 2.833330e+00
> 2
>        be7  he4  he3                       cd08nv   -1.58610e+00
>  3.873790e+01-1.840590e+01-1.282710e+01-3.082250e-02
> -6.546850e-01 8.963310e-02 8.333330e-01
> I think that one of the first two sets of data is used to create the
> 3He(a,g)7Be reaction rates, and one of the last two sets of data is used to
> create the reverse reaction rates. But after I put the numbers into the
> formula: *rate = Exp[ a0 + a1/T9 + a2/T91/3 + a3*T91/3 + a4*T9 +
> a5*T95/3 + a6*log(T9) ], I can't get the same results with the binary file.
> So I am wondering how can I get the exact reaction rates expression which
> is used by the MESA.*
>
> Thanks.
>
> ------------------------------
> 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
>
> *From:* Robert Farmer <rjf...@as...>
> *Date:* 2017-03-29 11:42
> *To:* let <le...@sz...>
> *CC:* mesa-users <mes...@li...>
> *Subject:* Re: [mesa-users] which file creates the reaction rates binary
> files?
> Hi
>
> There is a binary file version of the jina rates stored in
> $MESA_DIR/data/rates_data/cache/jina_reaclib.bin which we use after the
> first run so once the text file is gone we use that (if you didn't add an
> empty file you would get an error message about the text file missing)
>
> Deleting these files seems an unusual thing to do, if you explain what you
> want to do with the rates, we might be able to suggest a better way to do
> things.
>
> Rob
>
> On Tue, Mar 28, 2017 at 7:44 PM, 李二涛 <le...@sz...> wrote:
>
>>
>>
>> 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
>>
>>
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> 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] which file creates the reaction rates binary files?

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

 Dear Rob,

What I really want to know is the exact reaction rates expression which is used to create the binary file. I noticed that there are several sets of data for a reaction in mesa/data/rates_data/jina_reaclib_results_20130213default2. Take 3He(a,g)7Be reaction for example, there are four sets of data about the reaction:
4
       he4  he3  be7                       cd08n     1.58610e+00          
 1.770750e+01 0.000000e+00-1.282710e+01-3.812600e+00                      
 9.422850e-02-3.010180e-03 1.333330e+00                                   
4
       he4  he3  be7                       cd08n     1.58610e+00          
 1.560990e+01 0.000000e+00-1.282710e+01-3.082250e-02                      
-6.546850e-01 8.963310e-02-6.666670e-01  
2
       be7  he4  he3                       cd08nv   -1.58610e+00          
 4.083550e+01-1.840590e+01-1.282710e+01-3.812600e+00                      
 9.422850e-02-3.010180e-03 2.833330e+00                                   
2
       be7  he4  he3                       cd08nv   -1.58610e+00          
 3.873790e+01-1.840590e+01-1.282710e+01-3.082250e-02                      
-6.546850e-01 8.963310e-02 8.333330e-01 
I think that one of the first two sets of data is used to create the 3He(a,g)7Be reaction rates, and one of the last two sets of data is used to create the reverse reaction rates. But after I put the numbers into the formula: rate = Exp[ a0 + a1/T9 + a2/T91/3 + a3*T91/3 + a4*T9 + a5*T95/3 + a6*log(T9) ], I can't get the same results with the binary file. So I am wondering how can I get the exact reaction rates expression which is used by the MESA.

Thanks.




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 

From: Robert Farmer
Date: 2017-03-29 11:42
To: let
CC: mesa-users
Subject: Re: [mesa-users] which file creates the reaction rates binary files?
Hi


There is a binary file version of the jina rates stored in $MESA_DIR/data/rates_data/cache/jina_reaclib.bin which we use after the first run so once the text file is gone we use that (if you didn't add an empty file you would get an error message about the text file missing)


Deleting these files seems an unusual thing to do, if you explain what you want to do with the rates, we might be able to suggest a better way to do things.


Rob



On Tue, Mar 28, 2017 at 7:44 PM, 李二涛 <le...@sz...> wrote:



 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 
 
 

 


------------------------------------------------------------------------------
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] Modules in the other_hooks

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

  Hi Rob,

  Thanks! Seems like modifying the makefile in my working directory
WORK_DIR made it (Aaron just helped me with it). I am sharing it for future
MESA users that might encounter this issue. I copied
$(MESA_DIR)/star/work_standard_makefile to WORK_DIR/make and did


#   work_standard_makefile

# change this as necessary.  see utils/makefile_header for definitions.

include $(MESA_DIR)/utils/makefile_header

LOAD_MESA = $(LOAD_EXTRAS1) $(LOAD_MESA_STAR) $(LOAD_EXTRAS)

#################################################################

ifndef STAR
STAR = star
endif

# STAR_WORK_OBJS defined in makefile_header
OBJS = $(STAR_WORK_OBJS) run.o *mymodule.o*

WORK_DIR = ..
WORK_SRC_DIR = $(WORK_DIR)/src
STAR_JOB_DIR = $(MESA_DIR)/star/job

$(STAR) : $(OBJS)
    $(LOADER) $(FCopenmp) -o $(WORK_DIR)/$(STAR) $(OBJS) $(LOAD_MESA)

#################################################################

# WORK_COMPILE defined in makefile_header


*mymodule.o: $(WORK_SRC_DIR)/moduledir/mymodule.f    $(WORK_COMPILE) $<*

ifeq ($(SKIP_NAN_TRAPS),YES)
run.o: $(WORK_SRC_DIR)/run.f
    $(WORK_COMPILE) $<
else
run.o: $(WORK_SRC_DIR)/run.f
    $(WORK_COMPILE) $(FCtrapNANs) $<
endif

run_star_extras.o: $(WORK_SRC_DIR)/run_star_extras.f *mymodule.o*
    $(WORK_COMPILE) $<

%.o: $(STAR_JOB_DIR)/%.f
    $(WORK_COMPILE) $<

clean:
    -@rm -f *.o *.mod $(WORK_DIR)/$(STAR)

remk:
    -@rm -f run.o $(WORK_DIR)/$(STAR)


  --
  H.

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

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

Hi Aaron,
thanks for the quick reply.
Indeed this is an impressive demonstration of how our age estimates are 
prone to systematic effects due to the choices we made internally in our 
codes!

Cheers
Matteo


On 03/28/2017 07:25 PM, Aaron Dotter wrote:
> 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... <mailto: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...
>     <mailto:mes...@li...>
>     https://lists.sourceforge.net/lists/listinfo/mesa-users
>     <https://lists.sourceforge.net/lists/listinfo/mesa-users>
>
>

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

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

Hi

There is a binary file version of the jina rates stored in
$MESA_DIR/data/rates_data/cache/jina_reaclib.bin which we use after the
first run so once the text file is gone we use that (if you didn't add an
empty file you would get an error message about the text file missing)

Deleting these files seems an unusual thing to do, if you explain what you
want to do with the rates, we might be able to suggest a better way to do
things.

Rob

On Tue, Mar 28, 2017 at 7:44 PM, 李二涛 <le...@sz...> wrote:

>
>
> 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
>
>
>
>
>
> ------------------------------------------------------------
> ------------------
> 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] Modules in the other_hooks

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

Hi

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

You can do that, you could also copy the functions into the run_star_extras
file or you could copy the whole module and place before the
run_star_extras module in the run_star_extras.f file then add a use module
to the other hook function.

Rob

On Tue, Mar 28, 2017 at 3:52 PM, Héctor MR <hec...@pi...> wrote:

>   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.
>
> ------------------------------------------------------------
> ------------------
> 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
>
>