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

[mesa-users] Entropy Profiles

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

Hi,

Has anyone had any success with freezing the entropy profile of a star? I
have tried applying an eps_grav_factor = 0 as I thought this would result
in dS/dt = 0, but this doesn't appear to be the case. Speaking to Bill it
sounds as though mixing is the culprit for the change in entropy, so I was
wondering if anyone has had any success in forcing the entropy profile to
remain the same.

Best

Re: [mesa-users] secular modes with GYRE

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

Hi Alfred —

There already is some support in GYRE for this kind of calulation. In the &osc namelist group, there is an (undocumented) parameter ‘time_factor’ which allows one to control the assumed time dependence of modes. The two options are ‘OSC’, which has time dependence proportional to exp(-i omega t), and ‘EXP’, which has time dependence proportional to exp(-omega t). The ‘EXP’ option in effect allows one to scan along the imaginary frequency axis, which I use when searching for dynamically unstable modes.

The more general case of scanning along an arbitrary line in the complex plane isn’t supported by GYRE, but there are some (experimental) executables that ship with GYRE, which provide this sort of functionality. In particular, the file gyre/src/frontend/gyre_map.fpp allows a 2-D sampling of the discriminant D(omega) over the complex plane, which is a robust way to find very non-adiabatic modes. Attached below for your amusement is a map showing the real(D)=0 (blue) and imag(D)=0 (red) contours for radial modes in a massive star, as calculated using gyre_map. The crossings of these contours correspond to the star’s modes. Note the almost-complex-conjugate pairs of modes — we’re in the NAR limit here!

To build gyre_map, all you need do is download the most recent release candidate of GYRE (5.0rc3), edit gyre/src/build/Makefile to add gyre_map to the definitions of the TARGETS variable, and then build as usual; gyre_map will then be placed in gyre/bin. An example of gyre_map in action is given in the gyre/test/map directory; just do ‘./gyre_map gyre_map.in’ to run the example. The resulting map.h5 file can be plotted as a contour map using the plot_map.py python script in the same directory.

Since this is a very GYRE/pulsation specific topic, perhaps we should take further discussion to the GYRE forums (unless people on the MESA list want to hear about very non-adiabatic modes and the numerical challenges they present?).

cheers,

Rich



> On Apr 16, 2017, at 5:13 AM, al...@ga... wrote:
>
>
> For selected phases of a star's evolution I am frequently interested
> to learn about the prevailing secular (in-)stability situation. GYRE
> is a tool that has all components to answer such questions. In
> contrast to pulsation modes it is, however, necessary to be able to
> perform frequency scans along the imaginary axis [assuming the
> temporal behavior to be proportional to exp(i omega t)] on the
> frequency plane. As far as I have figured out, only scans along the
> real frequency axis are currently implemented.
>
> Being able to perform frequency scans along straight lines that are
> arbitrarily oriented in the *complex* frequency plane comes in handy
> also when dealing with strongly nonadiabatic pulsations; i.e. when
> eigenfrequencies lie far off the real frequency axis.
>
> So, here is my plea: Would it be possible, in a future release of
> GYRE, to be able to specify a
> freq_min and a freq_max, both being complex numbers, as lower and
> upper bounds for frequency scans.
>
> Thank you for considering the above as an item on the GYRE wishlist,
> 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] Fast Mass Loss

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

Hi Kenny,

The extreme mass loss rates and "collision" stripping leave me wondering what the photosphere might be in such a situation.  I wouldn't really expect anything to make much sense during such a phase; at best things might start to make sense when you come out the other of this, but all bets off for details during the stripping phase.

b


On Apr 17, 2017, at 10:02 AM, Kenny Van wrote:

> Hi,
> 
> I'm encountering some odd numerical issues with the model that I am trying to run. Essentially what I have done is evolved a solar type star to 2 solar radii, then proceed to strip off the envelope of the star at -1.0 solar masses per year. I realize that the mass loss being enforced here is incredibly high, but this is an attempt to try and simulate collisional stripping between two stars. In the simulation if the timestep is initially low enough the simulation will continue to run but for reasons unknown to me MESA greatly increases effective temperature and luminosity at the very start of the run. Is this a result of the hydro solver trying to force the simulation to work?
> 
> Best
> <2R_1M_star.mod><inlist>------------------------------------------------------------------------------
> 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] Fast Mass Loss

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

Hi,

I'm encountering some odd numerical issues with the model that I am trying
to run. Essentially what I have done is evolved a solar type star to 2
solar radii, then proceed to strip off the envelope of the star at -1.0
solar masses per year. I realize that the mass loss being enforced here is
incredibly high, but this is an attempt to try and simulate collisional
stripping between two stars. In the simulation if the timestep is initially
low enough the simulation will continue to run but for reasons unknown to
me MESA greatly increases effective temperature and luminosity at the very
start of the run. Is this a result of the hydro solver trying to force the
simulation to work?

Best

[mesa-users] secular modes with GYRE

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

For selected phases of a star's evolution I am frequently interested  
to learn about the prevailing secular (in-)stability situation. GYRE  
is a tool that has all components to answer such questions. In  
contrast to pulsation modes it is, however, necessary to be able to  
perform frequency scans along the imaginary axis [assuming the  
temporal behavior to be proportional to exp(i omega t)] on the  
frequency plane. As far as I have figured out, only scans along the  
real frequency axis are currently implemented.

Being able to perform frequency scans along straight lines that are  
arbitrarily oriented in the *complex* frequency plane comes in handy  
also when dealing with strongly nonadiabatic pulsations; i.e. when  
eigenfrequencies lie far off the real frequency axis.

So, here is my plea: Would it be possible, in a future release of  
GYRE, to be able to specify a
freq_min and a freq_max, both being complex numbers, as lower and  
upper bounds for frequency scans.

Thank you for considering the above as an item on the GYRE wishlist,
Alfred

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

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

Rich

Great! I did a mesa installation from scratch (as I ran into conflicts  
when compiling routines in eos)
and eventually successfully compiled and linked everything (incl. GYRE5.0rc2).

For those who update: Not to forget, gyre.in files must also be  
updated: check with appropriate files deeper along the path  
mesa/gyre/gyre/test/


Thanks a lot!
Alfred


> Hi Alfred —
>
> I’ve just committed fixes to the development version of MESA which  
> get the embedded GYRE going again. If you download/install revision  
> 9680 of MESA (or later), then it will include version 5.0rc2 of  
> GYRE, and everything should work without modification.
>
> cheers,
>
> Rich
>
>> On Apr 6, 2017, at 11:34 PM, al...@ga... wrote:
>>
>>
>> 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 —

I’ve just committed fixes to the development version of MESA which get the embedded GYRE going again. If you download/install revision 9680 of MESA (or later), then it will include version 5.0rc2 of GYRE, and everything should work without modification. 

cheers,

Rich

> On Apr 6, 2017, at 11:34 PM, al...@ga... wrote:
> 
> 
> 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] Mod file from preMS to onset of CCSN.

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

you'll need to evolve a massive star from the pre-main sequence onwards.
such inlists are available at mesastar.org, say for example, rob farmer's.

fxt




> On Apr 13, 2017, at 8:47 AM, Subedi, Shiv Kumar <ss3...@oh...> wrote:
> 
> Greetings everyone!
> 
> I've been using mesa version 7624 to study the nucleosynthesis phenomenon in CCSN. Till date I have been working with the mod file of progenitor star mass of 15 solar mass which is provided in the ccsn directory. Now, I want to study the nucleosynthesis phenomenon by changing the progenitor star mass. I am unsure how to  generate the mod file (as provided in the ccsn directory) for a different progenitor mass star. 
> 
> Any suggestions/help will be greatly appreciated.
> 
> Thanking you,
> Shiv Subedi
> ------------------------------------------------------------------------------
> 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] Mod file from preMS to onset of CCSN.

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

Greetings everyone!


I've been using mesa version 7624 to study the nucleosynthesis phenomenon in CCSN. Till date I have been working with the mod file of progenitor star mass of 15 solar mass which is provided in the ccsn directory. Now, I want to study the nucleosynthesis phenomenon by changing the progenitor star mass. I am unsure how to  generate the mod file (as provided in the ccsn directory) for a different progenitor mass star.


Any suggestions/help will be greatly appreciated.


Thanking you,

Shiv Subedi

Re: [mesa-users] Color Magnitude Diagram

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

Just to clear up something that might be of been unclear, MESA doesn't do
any atmosphere modeling. For the CMD we are simply interpolating over a
table of bolometric corrections to make the plot. Thus it is up to the user
to pick a suitable table that includes the correct physics and filter
subtles for their problem.

We ship a default table of bolometric corrections but there are of course
many other tables, based on different atmosphere models and filter sets,
that you could use which is why we provide a mechanism to use your own
table.

Rob

On Wed, Apr 12, 2017 at 12:36 PM, Michal Simon <mic...@st...>
wrote:

> I write to warn you about making C-M diagrams using MESA.  Because of the
> complexities of stellar atmospheres doing so requires careful attention to
> the
> emergent spectrum.  it is not a black body.  Also, given that, calculating
> magnitudes requires careful specification of the filter set.  There are
> subtle
> differences among the observatories.  MESA is great for Rphotosphere
> (suitably defined), L and hence Teff.  But for magnitudes I use Baraffe
> et al's (2015) work.  Mike Simon
> Mike Simon
>
> On Wed, Apr 12, 2017 at 3:14 PM, Kenny Van <kv...@ua...> wrote:
> > Hi,
> >
> > I'm wondering if it was possible to create a color magnitude diagram in
> > MESA. I know there is a color directory within MESA but I'm not sure how
> it
> > works or how to go about setting up the appropriate inlist or history
> file
> > to produce the values to be used.
> >
> > 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
> >
>
> ------------------------------------------------------------
> ------------------
> 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] Color Magnitude Diagram

[Michal S. <mic...@st...>]

I write to warn you about making C-M diagrams using MESA.  Because of the
complexities of stellar atmospheres doing so requires careful attention to the
emergent spectrum.  it is not a black body.  Also, given that, calculating
magnitudes requires careful specification of the filter set.  There are subtle
differences among the observatories.  MESA is great for Rphotosphere
(suitably defined), L and hence Teff.  But for magnitudes I use Baraffe
et al's (2015) work.  Mike Simon
Mike Simon

On Wed, Apr 12, 2017 at 3:14 PM, Kenny Van <kv...@ua...> wrote:
> Hi,
>
> I'm wondering if it was possible to create a color magnitude diagram in
> MESA. I know there is a color directory within MESA but I'm not sure how it
> works or how to go about setting up the appropriate inlist or history file
> to produce the values to be used.
>
> 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
>

Re: [mesa-users] Color Magnitude Diagram

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

Hi

So yes it is possible to get a color-magnitude diagram, working from r9575

In the star_job.defaults file in the "color files" section  we set the
files of bolometric corrections mesa uses. By default this is
Johnson-Cousins-ish bands (VBURIKHJLL'M) from Lejeune, Cuisinier, Buser
(1998). You can add your own files if you need filter bands we don't ship.

Assuming you stick with the Johnson-Cousins bands, then first do nothing
with the star_job inlist, then looking in the history columns file in the
Color output section there are the options to add the color data to the
history output. Lets say we want to plot (B-V) vs V then you need to add to
your history output

abs_mag v
abs_mag b
or you could add
add_abs_mag
to get all filters in your output

then in your pgstar plot

Color_magnitude1_win_flag = .true.
Color_magnitude1_xaxis1_name = 'abs_mag_b'
Color_magnitude1_xaxis2_name = 'abs_mag_v'  ! Plots xaxis1-xaxis2, leave
xaxis2 blank to just plot xaxis1
Color_magnitude1_num_panels = 1 ! Like the profile/history panels can have
multiple panels with same xaxis
Color_magnitude1_yaxis1_name(1) = 'abs_mag_v' ! could also set yaxis2 to
plot yaxis1-yaxis2

Rob


On Wed, Apr 12, 2017 at 12:14 PM, Kenny Van <kv...@ua...> wrote:

> Hi,
>
> I'm wondering if it was possible to create a color magnitude diagram in
> MESA. I know there is a color directory within MESA but I'm not sure how it
> works or how to go about setting up the appropriate inlist or history file
> to produce the values to be used.
>
> 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
>
>

[mesa-users] Color Magnitude Diagram

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

Hi,

I'm wondering if it was possible to create a color magnitude diagram in
MESA. I know there is a color directory within MESA but I'm not sure how it
works or how to go about setting up the appropriate inlist or history file
to produce the values to be used.

Thanks

Re: [mesa-users] MESA with very large network.

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

Hi

I'm afraid its a known limitation of mesa, there is a maximum sized problem
based on the number of isotopes**2 * number of zones < some limit.
Basically we use a dense storage system for the matrix in mesa, which
scales in size as isotopes**2 * number of zones, and eventually with a big
enough problem we overflow the 4-byte integer used to index the array which
gives you the segmentation fault.

For ~400 isotopes you can have a maximum of ~1000 zones. So i'm afraid you
cant run a 1700 isotope network on a star in mesa. You best bet is to stick
with a few hundred isotope network and do some sort of post processing step
afterwards if you need the extra isotopes.

Rob


On Tue, Apr 11, 2017 at 1:10 AM, Byeong-Chan Park <pb...@gm...> wrote:

> Dear
>
> Hello. I'm a graduate student using mesa8118. I'm trying to create
> pre-supernova model based on the massive_rotating test suite files with
> very large network.
>
> When I tried to run the code with rp305.net, there is no problem. Thus I
> tried to run same code with very large network including 1700 isotopes. The
> format of net file was based on the rp.net.
>
> However, the termincal showed segmentation fault problem. I attached image
> file including the terminal log (log.pdf) because the terminal was
> frozen......
>
> It seems that the log indicates there is some problem in a subroutine of
> 'hydro_mtx.f90' file, but I cannot find the way how I revise this
> subroutine.
>
> I need your help.
>
> Reagrds
> Park
>
> ------------------------------------------------------------
> ------------------
> 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-users Digest, Vol 92, Issue 5

[Delahaye F. <Fra...@ob...>]

Nigel

Without Auger info I cannot track Auger pop.

Cheers,

Fd
 
 
 
-- 
---
Franck Delahaye
LERMA - Observatoire de Paris - Site de Meudon
Phone: +33 1 4507 7446
Fax: +33 1 4507 7100
LERMA - UPMC Jussieu
Phone: +33 1 4427 7612
--- 
 
Le Mardi 11 Avril 2017 10:10 CEST, mes...@li... a écrit: 
 
> Send mesa-users mailing list submissions to
> 	mes...@li...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/mesa-users
> or, via email, send a message with subject or body 'help' to
> 	mes...@li...
> 
> You can reach the person managing the list at
> 	mes...@li...
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of mesa-users digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: say hello to your new mesastar.org
>       (Rodolfo Hector Barba Suarez)
>    2. Re: say hello to your new mesastar.org (Falk Herwig)
>    3. Re: say hello to your new mesastar.org (al...@ga...)
>    4. Re: say hello to your new mesastar.org (Frank Timmes)
>    5. Re: say hello to your new mesastar.org (Dennis Stello)
>    6. Re: say hello to your new mesastar.org (Frank Timmes)
>    7. Re: Undocumented control in &controls:
>       eos_partials_consistency_level (Warrick Ball)
>    8. MESA with very large network. (Byeong-Chan Park)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sat, 8 Apr 2017 20:27:07 -0300
> From: Rodolfo Hector Barba Suarez <rb...@us...>
> Subject: Re: [mesa-users] say hello to your new mesastar.org
> To: Willie Strickland <cw...@gm...>
> Cc: "mes...@li... users"
> 	<mes...@li...>
> Message-ID:
> 	<CAA...@ma...>
> Content-Type: text/plain; charset="utf-8"
> 
> Dear Frank,
> 
> Very useful for students and researchers. Congratulations!
> Regards.
> 
> Rodolfo
> 
> 
> 2017-04-08 20:17 GMT-03:00 Willie Strickland <cw...@gm...>:
> 
> > Well done!  I look forward to checking it out more in depth.
> >
> > Willie
> >
> > > On Apr 8, 2017, at 16:21, Frank Timmes <fx...@ma...> wrote:
> > >
> > > hi everyone,
> > >
> > > we are reinvigorating the community portal http://mesastar.org .

> > >
> > > new features include:
> > >
> > > 1) automatic updating of the latest refereed papers that cite mesa
> > >
> > > 2) searchable list of all known add-ons
> > >
> > > 3) searchable list of all submitted inlists
> > >
> > > 4) rapid access to the mesa summer school material
> > >
> > > 5) one stop shopping for all videos and guidance
> > >
> > > 6) a disqus-powered comments section
> > >
> > > 7) a blog (gulp).
> > >
> > >
> > > let us know what you think!
> > >
> > > frank timmes, aaron dotter, and bill wolf
> > >
> > >
> > >
> > > ------------------------------------------------------------
> > ------------------
> > > 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
> >
> 
> 
> 
> -- 
> 
> ---------------------------------------------------------------------------
> Rodolfo H. Barb?
> Profesor Asociado - Astr?nomo
> Coordinador ?rea de Astrof?sica de la ULS
> Departamento de F?sica y Astronom?a - Universidad de La Serena
> Cisternas 1200 Norte, La Serena, Chile
> Tel: +56 51 2204547
> ---------------------------------------------------------------------------
> -------------- next part --------------
> An HTML attachment was scrubbed...
> 
> ------------------------------
> 
> Message: 2
> Date: Sun, 9 Apr 2017 00:37:21 +0000
> From: Falk Herwig <fh...@uv...>
> Subject: Re: [mesa-users] say hello to your new mesastar.org
> To: Francis Timmes <fx...@ma...>
> Cc: "mes...@li... users"
> 	<mes...@li...>
> Message-ID: <832...@uv...>
> Content-Type: text/plain; charset="us-ascii"
> 
> kudos to Frank, Aaron, Bill - this a great improvement
> Falk.
> 
> > On Apr 8, 2017, at 2:21 PM, Frank Timmes <fx...@ma...> wrote:
> > 
> > hi everyone,
> > 
> > we are reinvigorating the community portal http://mesastar.org .
> > 
> > new features include:
> > 
> > 1) automatic updating of the latest refereed papers that cite mesa

> > 
> > 2) searchable list of all known add-ons
> > 
> > 3) searchable list of all submitted inlists
> > 
> > 4) rapid access to the mesa summer school material
> > 
> > 5) one stop shopping for all videos and guidance
> > 
> > 6) a disqus-powered comments section
> > 
> > 7) a blog (gulp).
> > 
> > 
> > let us know what you think!
> > 
> > frank timmes, aaron dotter, and bill wolf
> > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > 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
> 
> --
> Falk Herwig
> Dept of Physics & Astronomy, U of Victoria
> fh...@uv..., tel: +1 (250) 721-7743
> 
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Sun, 09 Apr 2017 10:22:56 +0200
> From: al...@ga...
> Subject: Re: [mesa-users] say hello to your new mesastar.org
> To: mesa-user forum <mes...@li...>
> Message-ID:
> 	<201...@we...>
> Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
> 
> The upgraded mesastar.org is very nice indeed, thanks to all who invested
> their energy and time -- and even their artistic ambitions; visually it's
> very attractive and "one-stop shopping" is definitely very helpful in a
> huge project that has so many different facets.
> 
> If I could place one wish then I would ask for incorporating also the forum
> aka mailing-list to it -- in a more phpBB-like organisation. Even after
> years living with it, I find it arduous to follow threads, if they do not
> happen to unfold in a tight block of backs-and-forths.
> 
> Having Mesa Home -- Mesa Marketplace -- Mesa Mailing-List linked together
> (referring to each other) in an obivous, prominently placed way that also
> not so well experienced users can easily navigate through all the resources
> should also be helpful.
> 
> Alfred
> 
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Sun, 09 Apr 2017 10:38:59 -0700
> From: Frank Timmes <fx...@ma...>
> Subject: Re: [mesa-users] say hello to your new mesastar.org
> To: al...@ga...
> Cc: mesa-user forum <mes...@li...>
> Message-ID: <AD9...@ma...>
> Content-Type: text/plain; charset=us-ascii
> 
> hi alfred,
> 
> thanks.
> 
> a forum versus, or in addition to, a mailing-list is a topic that 
> we've had discussions on before and probably will continue to contemplate.
> plusses and minuses to both communications venues.
> 
> not quite the same as a forum, but one can search the ~7500 messages on 
> https://sourceforge.net/p/mesa/mailman/mesa-users/ in a threaded view. 
> 
> the main official mesa site http://mesa.sourceforge.net has been updated
> to reference the marketplace, and the marketplace references the main site.
> a more prominent link to the mailing-list archives would be good though.
> 
> fxt
>  
> 
> 
> > On Apr 9, 2017, at 1:22 AM, al...@ga... wrote:
> > 
> > The upgraded mesastar.org is very nice indeed, thanks to all who invested
> > their energy and time -- and even their artistic ambitions; visually it's
> > very attractive and "one-stop shopping" is definitely very helpful in a
> > huge project that has so many different facets.
> > 
> > If I could place one wish then I would ask for incorporating also the forum
> > aka mailing-list to it -- in a more phpBB-like organisation. Even after
> > years living with it, I find it arduous to follow threads, if they do not
> > happen to unfold in a tight block of backs-and-forths.
> > 
> > Having Mesa Home -- Mesa Marketplace -- Mesa Mailing-List linked together
> > (referring to each other) in an obivous, prominently placed way that also
> > not so well experienced users can easily navigate through all the resources
> > should also be helpful.
> > 
> > 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
> 
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Mon, 10 Apr 2017 14:38:58 +1000
> From: Dennis Stello <den...@sy...>
> Subject: Re: [mesa-users] say hello to your new mesastar.org
> To: Frank Timmes <fx...@ma...>, "mes...@li...
> 	users"	<mes...@li...>
> Message-ID: <e33...@sy...>
> Content-Type: text/plain; charset="windows-1252"
> 
> Hi Frank et al.,
> 
> Suggestion: as the Add-on list grows, it might become handy to enable 
> click on the column headings to sort the table according to those 
> columns (particularly: Author, Function, Lanuage, MESA version).
> 
> Dennis/
> 
> On 09/04/17 7:21 AM, Frank Timmes wrote:
> > hi everyone,
> >
> > we are reinvigorating the community portal http://mesastar.org .
> >
> > new features include:
> >
> > 1) automatic updating of the latest refereed papers that cite mesa

> >
> > 2) searchable list of all known add-ons
> >
> > 3) searchable list of all submitted inlists
> >
> > 4) rapid access to the mesa summer school material
> >
> > 5) one stop shopping for all videos and guidance
> >
> > 6) a disqus-powered comments section
> >
> > 7) a blog (gulp).
> >
> >
> > let us know what you think!
> >
> > frank timmes, aaron dotter, and bill wolf
> >
> >
> >
> > ------------------------------------------------------------------------------
> > 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
> >
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> 
> ------------------------------
> 
> Message: 6
> Date: Sun, 09 Apr 2017 22:53:37 -0700
> From: Frank Timmes <fx...@ma...>
> Subject: Re: [mesa-users] say hello to your new mesastar.org
> To: Dennis Stello <den...@sy...>
> Cc: "mes...@li... users"
> 	<mes...@li...>
> Message-ID: <7EF...@ma...>
> Content-Type: text/plain; charset=utf-8
> 
> hi dennis,
> 
> yep! we?ve already played with sortable and scrollable tables in hopeful anticipation. 
> whether that?s needed depends on the mesa community?s willingness to share their inlists, 
> run_star_extras, and other add-ons. i hope they do.
> 
> fxt
> 
> 
> 
> 
> > On Apr 9, 2017, at 9:38 PM, Dennis Stello <den...@sy...> wrote:
> > 
> > Hi Frank et al.,
> > 
> > Suggestion: as the Add-on list grows, it might become handy to enable click on the column headings to sort the table according to those columns (particularly: Author, Function, Lanuage, MESA version). 
> > 
> > Dennis/
> > 
> > On 09/04/17 7:21 AM, Frank Timmes wrote:
> >> hi everyone,
> >> 
> >> we are reinvigorating the community portal 
> >> http://mesastar.org
> >>  .
> >> 
> >> new features include:
> >> 
> >> 1) automatic updating of the latest refereed papers that cite mesa
> >> 
> >> 2) searchable list of all known add-ons
> >> 
> >> 3) searchable list of all submitted inlists
> >> 
> >> 4) rapid access to the mesa summer school material
> >> 
> >> 5) one stop shopping for all videos and guidance
> >> 
> >> 6) a disqus-powered comments section
> >> 
> >> 7) a blog (gulp).
> >> 
> >> 
> >> let us know what you think!
> >> 
> >> frank timmes, aaron dotter, and bill wolf
> >> 
> >> 
> >> 
> >> ------------------------------------------------------------------------------
> >> 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
> >> 
> >> 
> >> 
> > 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Mon, 10 Apr 2017 07:57:52 +0000 (UTC)
> From: Warrick Ball <wb...@bi...>
> Subject: Re: [mesa-users] Undocumented control in &controls:
> 	eos_partials_consistency_level
> To: Bill Paxton <pa...@ki...>
> Cc: MESA Users List <mes...@li...>
> Message-ID: <alp...@bi...>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi Bill,
> 
> Brilliant explanation, thanks very much!  It's clear that I misinterpreted 
> "consistency" as thermodynamic consistency, rather than a kind of 
> numerical consistency.  I tried a solar calibration with level 1 and it 
> made no difference whatsoever (as expected, I guess).
> 
> Thanks for taking the time to explain in such detail.
> 
> 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 Fri, 7 Apr 2017, Bill Paxton wrote:
> 
> > 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 part!
>  ials 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
> >
> >
> 
> ------------------------------
> 
> Message: 8
> Date: Tue, 11 Apr 2017 17:10:21 +0900
> From: Byeong-Chan Park <pb...@gm...>
> Subject: [mesa-users] MESA with very large network.
> To: mes...@li...
> Message-ID:
> 	<CACC5kTwE3Q8ZDMHEf-0C=EM8...@ma...>
> Content-Type: text/plain; charset="utf-8"
> 
> Dear
> 
> Hello. I'm a graduate student using mesa8118. I'm trying to create
> pre-supernova model based on the massive_rotating test suite files with
> very large network.
> 
> When I tried to run the code with rp305.net, there is no problem. Thus I
> tried to run same code with very large network including 1700 isotopes. The
> format of net file was based on the rp.net.
> 
> However, the termincal showed segmentation fault problem. I attached image
> file including the terminal log (log.pdf) because the terminal was
> frozen......
> 
> It seems that the log indicates there is some problem in a subroutine of
> 'hydro_mtx.f90' file, but I cannot find the way how I revise this
> subroutine.
> 
> I need your help.
> 
> Reagrds
> Park
> -------------- next part --------------
> An HTML attachment was scrubbed...
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: log.pdf
> Type: application/pdf
> Size: 144580 bytes
> Desc: not available
> 
> ------------------------------
> 
> ------------------------------------------------------------------------------
> 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
> 
> 
> End of mesa-users Digest, Vol 92, Issue 5
> *****************************************
 
 

[mesa-users] MESA with very large network.

[Byeong-Chan P. <pb...@gm...>]

Dear

Hello. I'm a graduate student using mesa8118. I'm trying to create
pre-supernova model based on the massive_rotating test suite files with
very large network.

When I tried to run the code with rp305.net, there is no problem. Thus I
tried to run same code with very large network including 1700 isotopes. The
format of net file was based on the rp.net.

However, the termincal showed segmentation fault problem. I attached image
file including the terminal log (log.pdf) because the terminal was
frozen......

It seems that the log indicates there is some problem in a subroutine of
'hydro_mtx.f90' file, but I cannot find the way how I revise this
subroutine.

I need your help.

Reagrds
Park

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

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

Hi Bill,

Brilliant explanation, thanks very much!  It's clear that I misinterpreted 
"consistency" as thermodynamic consistency, rather than a kind of 
numerical consistency.  I tried a solar calibration with level 1 and it 
made no difference whatsoever (as expected, I guess).

Thanks for taking the time to explain in such detail.

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 Fri, 7 Apr 2017, Bill Paxton wrote:

> 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 part!
 ials 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
>
>

Re: [mesa-users] say hello to your new mesastar.org

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

hi dennis,

yep! we’ve already played with sortable and scrollable tables in hopeful anticipation. 
whether that’s needed depends on the mesa community’s willingness to share their inlists, 
run_star_extras, and other add-ons. i hope they do.

fxt




> On Apr 9, 2017, at 9:38 PM, Dennis Stello <den...@sy...> wrote:
> 
> Hi Frank et al.,
> 
> Suggestion: as the Add-on list grows, it might become handy to enable click on the column headings to sort the table according to those columns (particularly: Author, Function, Lanuage, MESA version). 
> 
> Dennis/
> 
> On 09/04/17 7:21 AM, Frank Timmes wrote:
>> hi everyone,
>> 
>> we are reinvigorating the community portal 
>> http://mesastar.org
>>  .
>> 
>> new features include:
>> 
>> 1) automatic updating of the latest refereed papers that cite mesa
>> 
>> 2) searchable list of all known add-ons
>> 
>> 3) searchable list of all submitted inlists
>> 
>> 4) rapid access to the mesa summer school material
>> 
>> 5) one stop shopping for all videos and guidance
>> 
>> 6) a disqus-powered comments section
>> 
>> 7) a blog (gulp).
>> 
>> 
>> let us know what you think!
>> 
>> frank timmes, aaron dotter, and bill wolf
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> 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] say hello to your new mesastar.org

[Dennis S. <den...@sy...>]

Hi Frank et al.,

Suggestion: as the Add-on list grows, it might become handy to enable 
click on the column headings to sort the table according to those 
columns (particularly: Author, Function, Lanuage, MESA version).

Dennis/

On 09/04/17 7:21 AM, Frank Timmes wrote:
> hi everyone,
>
> we are reinvigorating the community portal http://mesastar.org .
>
> new features include:
>
> 1) automatic updating of the latest refereed papers that cite mesa
>
> 2) searchable list of all known add-ons
>
> 3) searchable list of all submitted inlists
>
> 4) rapid access to the mesa summer school material
>
> 5) one stop shopping for all videos and guidance
>
> 6) a disqus-powered comments section
>
> 7) a blog (gulp).
>
>
> let us know what you think!
>
> frank timmes, aaron dotter, and bill wolf
>
>
>
> ------------------------------------------------------------------------------
> 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] say hello to your new mesastar.org

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

hi alfred,

thanks.

a forum versus, or in addition to, a mailing-list is a topic that 
we've had discussions on before and probably will continue to contemplate.
plusses and minuses to both communications venues.

not quite the same as a forum, but one can search the ~7500 messages on 
https://sourceforge.net/p/mesa/mailman/mesa-users/ in a threaded view. 

the main official mesa site http://mesa.sourceforge.net has been updated
to reference the marketplace, and the marketplace references the main site.
a more prominent link to the mailing-list archives would be good though.

fxt
 


> On Apr 9, 2017, at 1:22 AM, al...@ga... wrote:
> 
> The upgraded mesastar.org is very nice indeed, thanks to all who invested
> their energy and time -- and even their artistic ambitions; visually it's
> very attractive and "one-stop shopping" is definitely very helpful in a
> huge project that has so many different facets.
> 
> If I could place one wish then I would ask for incorporating also the forum
> aka mailing-list to it -- in a more phpBB-like organisation. Even after
> years living with it, I find it arduous to follow threads, if they do not
> happen to unfold in a tight block of backs-and-forths.
> 
> Having Mesa Home -- Mesa Marketplace -- Mesa Mailing-List linked together
> (referring to each other) in an obivous, prominently placed way that also
> not so well experienced users can easily navigate through all the resources
> should also be helpful.
> 
> 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] say hello to your new mesastar.org

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

The upgraded mesastar.org is very nice indeed, thanks to all who invested
their energy and time -- and even their artistic ambitions; visually it's
very attractive and "one-stop shopping" is definitely very helpful in a
huge project that has so many different facets.

If I could place one wish then I would ask for incorporating also the forum
aka mailing-list to it -- in a more phpBB-like organisation. Even after
years living with it, I find it arduous to follow threads, if they do not
happen to unfold in a tight block of backs-and-forths.

Having Mesa Home -- Mesa Marketplace -- Mesa Mailing-List linked together
(referring to each other) in an obivous, prominently placed way that also
not so well experienced users can easily navigate through all the resources
should also be helpful.

Alfred

Re: [mesa-users] say hello to your new mesastar.org

[Falk H. <fh...@uv...>]

kudos to Frank, Aaron, Bill - this a great improvement
Falk.

> On Apr 8, 2017, at 2:21 PM, Frank Timmes <fx...@ma...> wrote:
> 
> hi everyone,
> 
> we are reinvigorating the community portal http://mesastar.org .
> 
> new features include:
> 
> 1) automatic updating of the latest refereed papers that cite mesa
> 
> 2) searchable list of all known add-ons
> 
> 3) searchable list of all submitted inlists
> 
> 4) rapid access to the mesa summer school material
> 
> 5) one stop shopping for all videos and guidance
> 
> 6) a disqus-powered comments section
> 
> 7) a blog (gulp).
> 
> 
> let us know what you think!
> 
> frank timmes, aaron dotter, and bill wolf
> 
> 
> 
> ------------------------------------------------------------------------------
> 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

--
Falk Herwig
Dept of Physics & Astronomy, U of Victoria
fh...@uv..., tel: +1 (250) 721-7743

Re: [mesa-users] say hello to your new mesastar.org

[Rodolfo H. B. S. <rb...@us...>]

Dear Frank,

Very useful for students and researchers. Congratulations!
Regards.

Rodolfo


2017-04-08 20:17 GMT-03:00 Willie Strickland <cw...@gm...>:

> Well done!  I look forward to checking it out more in depth.
>
> Willie
>
> > On Apr 8, 2017, at 16:21, Frank Timmes <fx...@ma...> wrote:
> >
> > hi everyone,
> >
> > we are reinvigorating the community portal http://mesastar.org .
> >
> > new features include:
> >
> > 1) automatic updating of the latest refereed papers that cite mesa
> >
> > 2) searchable list of all known add-ons
> >
> > 3) searchable list of all submitted inlists
> >
> > 4) rapid access to the mesa summer school material
> >
> > 5) one stop shopping for all videos and guidance
> >
> > 6) a disqus-powered comments section
> >
> > 7) a blog (gulp).
> >
> >
> > let us know what you think!
> >
> > frank timmes, aaron dotter, and bill wolf
> >
> >
> >
> > ------------------------------------------------------------
> ------------------
> > 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
>



-- 

---------------------------------------------------------------------------
Rodolfo H. Barbá
Profesor Asociado - Astrónomo
Coordinador Área de Astrofísica de la ULS
Departamento de Física y Astronomía - Universidad de La Serena
Cisternas 1200 Norte, La Serena, Chile
Tel: +56 51 2204547
---------------------------------------------------------------------------

Re: [mesa-users] say hello to your new mesastar.org

[Willie S. <cw...@gm...>]

Well done!  I look forward to checking it out more in depth. 

Willie 

> On Apr 8, 2017, at 16:21, Frank Timmes <fx...@ma...> wrote:
> 
> hi everyone,
> 
> we are reinvigorating the community portal http://mesastar.org .
> 
> new features include:
> 
> 1) automatic updating of the latest refereed papers that cite mesa
> 
> 2) searchable list of all known add-ons
> 
> 3) searchable list of all submitted inlists
> 
> 4) rapid access to the mesa summer school material
> 
> 5) one stop shopping for all videos and guidance
> 
> 6) a disqus-powered comments section
> 
> 7) a blog (gulp).
> 
> 
> let us know what you think!
> 
> frank timmes, aaron dotter, and bill wolf
> 
> 
> 
> ------------------------------------------------------------------------------
> 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] say hello to your new mesastar.org

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

hi everyone,

we are reinvigorating the community portal http://mesastar.org .

new features include:

1) automatic updating of the latest refereed papers that cite mesa

2) searchable list of all known add-ons

3) searchable list of all submitted inlists

4) rapid access to the mesa summer school material

5) one stop shopping for all videos and guidance

6) a disqus-powered comments section

7) a blog (gulp).


let us know what you think!

frank timmes, aaron dotter, and bill wolf