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

[mesa-users] rn14ag_lite ! n14 + 1.5 alpha = ne20

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

 Dear Mesa users,

I noticed that there is a line :        
     rn14ag_lite         ! n14 + 1.5 alpha = ne20 
in $HOME/mesa/data/net_data/nets/basic.net.

Can someone please explain exactly what is n14 + 1.5 alpha = ne20 ?

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 
 
 

 

[mesa-users] segmentation fault (core dumped)

[ertaoLee <ert...@gm...>]

Dear MESA users,

I am trying to install the mesa 9793, but I encountered the following problem:

gfortran -fopenmp -o ../sample sample_eos.o -L../../make -leos -L../../../lib -lchem -linterp_2d -linterp_1d -lnum -lf2c
rlibm -lcrlibm -lmtx -lconst -lutils -lmesaklu `mesasdk_lapack_link` `mesasdk_blas_link` `mesasdk_hdf5_link`
../utils/build_and_test_parallel: line 56: 17804 Segmentation fault      (core dumped) ./test_quietly &> test_quietly.tx
t

/mnt/d/mesa/eos/test
FAILED


/mnt/d/mesa/eos
./build_and_test FAILED

I can't solve it. Please help me

The following information may be useful.

The version of MESA I am trying to build
9793
The version of the SDK I am using
x86_64-linux-20160129 and x86_64-linux-20150908 both tried and can't work
My platform (machine type, operating system, version)
Thinkpad T430
windows10(ubuntu 16.04)
uname -a
Linux LENOVO-PC 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
gfortran -v
Using built-in specs.
COLLECT_GCC=/home/let/mesasdk/bin/gfortran.exec
COLLECT_LTO_WRAPPER=/home/let/mesasdk/bin/../libexec/gcc/x86_64-pc-linux-gnu/5.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /root/mesasdk-src/gcc/configure CC=gcc --build=x86_64-pc-linux-gnu --prefix=/root/mesasdk --with-gmp=/
oot/mesasdk --with-mpfr=/root/mesasdk --with-mpc=/root/mesasdk --enable-languages=c,c++,fortran --disable-multilib --dis
able-nls --disable-libsanitizer --enable-clocale=generic
Thread model: posix
gcc version 5.3.1 20160129 (GCC)
echo $MESASDK_ROOT
/home/let/mesasdk
echo $PATH
/home/let/mesasdk/bin:/home/let/mesasdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr
/local/games:/mnt/c/ProgramData/Oracle/Java/javapath:/mnt/c/Program Files (x86)/Intel/iCLS Client:/mnt/c/Program Files/I
ntel/iCLS Client:/mnt/c/Windows/System32:/mnt/c/Windows:/mnt/c/Windows/System32/wbem:/mnt/c/Windows/System32/WindowsPowe
rShell/v1.0:/mnt/c/Program Files/Intel/Intel(R) Management Engine Components/DAL:/mnt/c/Program Files/Intel/Intel(R) Man
agement Engine Components/IPT:/mnt/c/Program Files (x86)/Intel/Intel(R) Management Engine Components/DAL:/mnt/c/Program
Files (x86)/Intel/Intel(R) Management Engine Components/IPT:/mnt/c/CTeX/MiKTeX/miktex/bin:/mnt/c/CTeX/CTeX/ctex/bin:/mnt
/c/CTeX/CTeX/cct/bin:/mnt/c/CTeX/CTeX/ty/bin:/mnt/c/CTeX/Ghostscript/gs9.05/bin:/mnt/c/CTeX/GSview/gsview:/mnt/c/CTeX/Wi
nEdt:/mnt/d/BIN:/mnt/c/Users/LENOVO/AppData/Local/Programs/Python/Python36-32/Scripts:/mnt/c/Users/LENOVO/AppData/Local/
Programs/Python/Python36-32

Thanks in advance for any help that you can offer!




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

Re: [mesa-users] Inlist issue

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

most excellent catch on "/" being a reserved character!

fxt



> On Jul 31, 2017, at 9:47 AM, Josiah Schwab <jws...@uc...> wrote:
> 
> Hi All,
> 
> I wanted to take a minute and pedagogically describe what is going on
> here for future reference.
> 
> The first, and most important point is that you can't do math in
> inlists.  So as Frank says, the solution is to write out your numbers.
> 
> Now if you were to try to do some other math operation, for example,
> 
>  am_D_mix_factor = 1d0 + 1d0
> 
> you'd receive an error.
> 
> However, the character '/' ends a fortran namelist.  That is, one
> normally writes something like
> 
> &controls
> 
>  am_D_mix_factor = 0.03333
> 
> / ! end of controls namelist
> 
> where the comment is informative, but syntactically irrelevant.
> 
> So when you write
> 
> &controls
> 
>  am_D_mix_factor = 1d0/30d0
>  some_other_option = 'something'
> 
> / ! end of controls namelist
> 
> the namelist ends immediately at the first '/'.  So everything beyond
> (i.e. the 30d0 and any subsequent options) will be ignored, because it
> is located outside of the controls namelist.
> 
> As you found, this mistake can be insidious because it will not produce
> an error message.  MESA will simply run with the truncated inlist.
> 
> Josiah

Re: [mesa-users] Inlist issue

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

But if you DO want inlist support for math, variables, and controls statements like if blocks and for loops, check out the MesaScript project, which aims to do exactly that for MESA star (and to a limited extent, MESA binary):

http://wmwolf.github.io/MesaScript/

other bill

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

UCSB Department of Physics 

On July 31, 2017 at 9:55:28 AM, Bill Paxton (pa...@ki...) wrote:


On Jul 31, 2017, at 9:47 AM, Josiah Schwab wrote:

The first, and most important point is that you can't do math in
inlists

and don't blame me for that!  ;)   it is a limitation of the fortran runtime that reads the inlist.

it is not an interpreter that can parse and evaluate anything as complicated as "1 + 1".   

i've been tempted to replace inlists by a python script to be executed each time we currently read the inlist,
but that's too much baggage for now.   we're going to stick to the limited but simple fortran inlist scheme.

you just need to be aware of the limitations.    thanks to josiah and others for explaining this issue.

bill



------------------------------------------------------------------------------  
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] Inlist issue

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

On Jul 31, 2017, at 9:47 AM, Josiah Schwab wrote:

> The first, and most important point is that you can't do math in
> inlists

and don't blame me for that!  ;)   it is a limitation of the fortran runtime that reads the inlist.

it is not an interpreter that can parse and evaluate anything as complicated as "1 + 1".   

i've been tempted to replace inlists by a python script to be executed each time we currently read the inlist,
but that's too much baggage for now.   we're going to stick to the limited but simple fortran inlist scheme.

you just need to be aware of the limitations.    thanks to josiah and others for explaining this issue.

bill

Re: [mesa-users] Inlist issue

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

Hi All,

I wanted to take a minute and pedagogically describe what is going on
here for future reference.

The first, and most important point is that you can't do math in
inlists.  So as Frank says, the solution is to write out your numbers.

Now if you were to try to do some other math operation, for example,

  am_D_mix_factor = 1d0 + 1d0

you'd receive an error.

However, the character '/' ends a fortran namelist.  That is, one
normally writes something like

&controls

  am_D_mix_factor = 0.03333

/ ! end of controls namelist

where the comment is informative, but syntactically irrelevant.

So when you write

&controls

  am_D_mix_factor = 1d0/30d0
  some_other_option = 'something'

/ ! end of controls namelist

the namelist ends immediately at the first '/'.  So everything beyond
(i.e. the 30d0 and any subsequent options) will be ignored, because it
is located outside of the controls namelist.

As you found, this mistake can be insidious because it will not produce
an error message.  MESA will simply run with the truncated inlist.

Josiah

Re: [mesa-users] Barring reactions from adaptive net

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

Is it necessary to do this in run_star_extras? I seem to recall using the following star_job options to do something like this once.

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

      num_special_rate_factors = 1
      reaction_for_special_factor(1) = ’name_of_reaction'
      special_rate_factor(1) = 0

That should effectively turn off the reaction and accomplish what I think Amber is looking for.

Cheers,
Evan


> On Jul 31, 2017, at 7:58 AM, Robert Farmer <rjf...@as...> wrote:
> 
> Hi
> Your best bet i think is to turn the rate off using the rate_factors array.
> 
> Something like (untested) in extras_startup
> 
> use net_lib
> use net_def
> 
> type (Net_General_Info), pointer  :: g
> 
>            do i=1,g% num_reactions
>                if(trim(reaction_Name(g% reaction_id(i)))==trim('YOUR_REACTION_HERE')) then
>                   s%rate_factors(i)=0d0
>                end if
>             end do
> 
> s%rate_factors is an array with a multiplier for each rate in use, so by setting to 0 we turn the rate off.
> 
> Rob
> 
> 
> On Mon, Jul 31, 2017 at 3:47 PM, amber lauer <al...@ls... <mailto:al...@ls...>> wrote:
> Is there a way to use the adaptive net but eliminate a specific reaction? If not, I'm thinking an alternative would be to just set the rate of said reaction to 0, or, barring that as well, could such a thing be done using a hook?
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot <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>
> 
> 
> ------------------------------------------------------------------------------
> 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] Barring reactions from adaptive net

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

Hi
Your best bet i think is to turn the rate off using the rate_factors array.

Something like (untested) in extras_startup

use net_lib
use net_def

type (Net_General_Info), pointer  :: g

           do i=1,g% num_reactions
               if(trim(reaction_Name(g%
reaction_id(i)))==trim('YOUR_REACTION_HERE')) then
                  s%rate_factors(i)=0d0
               end if
            end do

s%rate_factors is an array with a multiplier for each rate in use, so by
setting to 0 we turn the rate off.

Rob


On Mon, Jul 31, 2017 at 3:47 PM, amber lauer <al...@ls...> wrote:

> Is there a way to use the adaptive net but eliminate a specific reaction?
> If not, I'm thinking an alternative would be to just set the rate of said
> reaction to 0, or, barring that as well, could such a thing be done using a
> hook?
>
> ------------------------------------------------------------
> ------------------
> 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] Barring reactions from adaptive net

[amber l. <al...@ls...>]

Is there a way to use the adaptive net but eliminate a specific reaction?
If not, I'm thinking an alternative would be to just set the rate of said
reaction to 0, or, barring that as well, could such a thing be done using a
hook?

Re: [mesa-users] Inlist issue

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

the inlist contains at least one error:


>       am_D_mix_factor = 1d0/30d0


you need to enter this value as a decimal, am_D_mix_factor = 0.03333


>          photostep = 20

is an obsolete parameter in recent versions of mesa. use photo_interval = 50.

the inlist ran fine in 9793 after making these changes.

in future, please include any error messages emitted when reporting an issue.

fxt







> On Jul 28, 2017, at 11:43 AM, Yevgeni Kissin <jen...@gm...> wrote:
> 
> Hello Frank and everyone again,
> 
> I tried implementing the star_job parameters you recommended for rotation and running a fresh model.
> Rotation is definitely active and relaxed once the model reaches the MS. However, I am still getting the
> same issue. 
> 
> Again, none of the controls below the mixing ones are recorded. That includes mass loss, history and
> profile formatting, etc.
> 
> I am including the new inlist file. If anybody has an idea what could be causing this, I would appreciate
> some guidance.
> 
> Thank you,
> 
> Yevgeni.
> 
> On 20 July 2017 at 19:07, Yevgeni Kissin <jen...@gm...> wrote:
> Hi Frank,
> 
> Thank you for responding.
> 
> Is it rotation that triggers an issue with the ZAMS flag?
> 
> I set up accretion on a pre-MS 3M_o core. I then choose the model closest in mass to what I
> am after and restart from the corresponding photo. I used this setup numerous times before,
> but this is the first time I attempt to include rotation.
> 
> I figured I don't want to include rotation in the pre-MS model, since I am looking for a certain rate
> on the ZAMS (which is shortly after the first model I restart from - the model relaxes quickly).
> 
> Thank you,
> 
> Yevgeni.
> 
> On 20 July 2017 at 15:02, Frank Timmes <fx...@ma...> wrote:
> inlist_massive_star creates a pre-main sequence model
> 
>       create_pre_main_sequence_model = .true.
> 
> rather than load a previous model. in such cases it can be useful
> to turn on rotation when the pre-ms model is near zams. for example,
> 
>       new_rotation_flag = .true.
>       change_rotation_flag = .false.                 ! rotation off until near zams
>       near_zams_relax_omega_div_omega_crit = .true.  ! true to turn on rotation at zams
>       num_steps_to_relax_rotation = 100              ! use this many steps in relaxing
>       new_omega_div_omega_crit = 0.10d0
> 
> explore http://mesa.sourceforge.net/star_job_defaults.html#rotation_controls
> to find the relevant controls for omega instead of the omega_div_omega_crit
> used in the above example.
> 
> fxt
> 
> 
> 
> 
> > On Jul 20, 2017, at 10:26 AM, Yevgeni Kissin <jen...@gm...> wrote:
> >
> > Hi everyone,
> >
> > I am attempting to modify an inlist that has worked for me numerous times, by adding controls for
> > rotation and resulting mixing. Once I do so, all the controls below the mixing values fail to be
> > registered (i.e. their values revert to defaults).
> >
> > I am including the inlist here, and I enclosed the new values in '!!!!' (should be evident).
> >
> > I tried moving the new values to the bottom of the inlist, but when I run I get a series of messages:
> > " s% omega(k)        ###     NaN "
> > which I believe is due to me setting a rotation rate, without activating mixing (hence the control
> > command does not get recognized).
> >
> > Is there a limit to the length of the inlist, or what could be the issue here?
> >
> > I will point out that this inlist is used to restart from an image of a 3M_o pre-MS model which experienced
> > accretion up to 13M_o (hence it's a 13M_o ZAMS model).
> >
> > Thank you very much.
> >
> > Yevgeni.
> > <inlist_massive_star>------------------------------------------------------------------------------
> > 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
> 
> 
> 
> <inlist_massive_star>

Re: [mesa-users] mesa-users Digest, Vol 95, Issue 21

[Bruno L. <bru...@gm...>]

Hi Yevgeni 

May you send me your inlist for I 
So that I can better verify or understand what you want?

Att,
=======================
Bruno

> Em 29 de jul de 2017, às 09:12, mes...@li... escreveu:
> 
> 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: Inlist issue (Yevgeni Kissin)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 28 Jul 2017 14:43:15 -0400
> From: Yevgeni Kissin <jen...@gm...>
> To: Frank Timmes <fx...@ma...>
> Cc: "mes...@li... users"
>    <mes...@li...>
> Subject: Re: [mesa-users] Inlist issue
> Message-ID:
>    <CAE...@ma...>
> Content-Type: text/plain; charset="utf-8"
> 
> Hello Frank and everyone again,
> 
> I tried implementing the star_job parameters you recommended for rotation
> and running a fresh model.
> Rotation is definitely active and relaxed once the model reaches the MS.
> However, I am still getting the
> same issue.
> 
> Again, none of the controls below the mixing ones are recorded. That
> includes mass loss, history and
> profile formatting, etc.
> 
> I am including the new inlist file. If anybody has an idea what could be
> causing this, I would appreciate
> some guidance.
> 
> Thank you,
> 
> Yevgeni.
> 
>> On 20 July 2017 at 19:07, Yevgeni Kissin <jen...@gm...> wrote:
>> 
>> Hi Frank,
>> 
>> Thank you for responding.
>> 
>> Is it rotation that triggers an issue with the ZAMS flag?
>> 
>> I set up accretion on a pre-MS 3M_o core. I then choose the model closest
>> in mass to what I
>> am after and restart from the corresponding photo. I used this setup
>> numerous times before,
>> but this is the first time I attempt to include rotation.
>> 
>> I figured I don't want to include rotation in the pre-MS model, since I am
>> looking for a certain rate
>> on the ZAMS (which is shortly after the first model I restart from - the
>> model relaxes quickly).
>> 
>> Thank you,
>> 
>> Yevgeni.
>> 
>>> On 20 July 2017 at 15:02, Frank Timmes <fx...@ma...> wrote:
>>> 
>>> inlist_massive_star creates a pre-main sequence model
>>> 
>>>      create_pre_main_sequence_model = .true.
>>> 
>>> rather than load a previous model. in such cases it can be useful
>>> to turn on rotation when the pre-ms model is near zams. for example,
>>> 
>>>      new_rotation_flag = .true.
>>>      change_rotation_flag = .false.                 ! rotation off until
>>> near zams
>>>      near_zams_relax_omega_div_omega_crit = .true.  ! true to turn on
>>> rotation at zams
>>>      num_steps_to_relax_rotation = 100              ! use this many
>>> steps in relaxing
>>>      new_omega_div_omega_crit = 0.10d0
>>> 
>>> explore http://mesa.sourceforge.net/star_job_defaults.html#rotation_
>>> controls
>>> to find the relevant controls for omega instead of the
>>> omega_div_omega_crit
>>> used in the above example.
>>> 
>>> fxt
>>> 
>>> 
>>> 
>>> 
>>>> On Jul 20, 2017, at 10:26 AM, Yevgeni Kissin <jen...@gm...>
>>> wrote:
>>>> 
>>>> Hi everyone,
>>>> 
>>>> I am attempting to modify an inlist that has worked for me numerous
>>> times, by adding controls for
>>>> rotation and resulting mixing. Once I do so, all the controls below the
>>> mixing values fail to be
>>>> registered (i.e. their values revert to defaults).
>>>> 
>>>> I am including the inlist here, and I enclosed the new values in '!!!!'
>>> (should be evident).
>>>> 
>>>> I tried moving the new values to the bottom of the inlist, but when I
>>> run I get a series of messages:
>>>> " s% omega(k)        ###     NaN "
>>>> which I believe is due to me setting a rotation rate, without
>>> activating mixing (hence the control
>>>> command does not get recognized).
>>>> 
>>>> Is there a limit to the length of the inlist, or what could be the
>>> issue here?
>>>> 
>>>> I will point out that this inlist is used to restart from an image of a
>>> 3M_o pre-MS model which experienced
>>>> accretion up to 13M_o (hence it's a 13M_o ZAMS model).
>>>> 
>>>> Thank you very much.
>>>> 
>>>> Yevgeni.
>>>> <inlist_massive_star>---------------------------------------
>>> ---------------------------------------
>>>> 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...
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: inlist_massive_star
> Type: application/octet-stream
> Size: 7348 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
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
> 
> 
> ------------------------------
> 
> End of mesa-users Digest, Vol 95, Issue 21
> ******************************************

Re: [mesa-users] Inlist issue

[Yevgeni K. <jen...@gm...>]

Hello Frank and everyone again,

I tried implementing the star_job parameters you recommended for rotation
and running a fresh model.
Rotation is definitely active and relaxed once the model reaches the MS.
However, I am still getting the
same issue.

Again, none of the controls below the mixing ones are recorded. That
includes mass loss, history and
profile formatting, etc.

I am including the new inlist file. If anybody has an idea what could be
causing this, I would appreciate
some guidance.

Thank you,

Yevgeni.

On 20 July 2017 at 19:07, Yevgeni Kissin <jen...@gm...> wrote:

> Hi Frank,
>
> Thank you for responding.
>
> Is it rotation that triggers an issue with the ZAMS flag?
>
> I set up accretion on a pre-MS 3M_o core. I then choose the model closest
> in mass to what I
> am after and restart from the corresponding photo. I used this setup
> numerous times before,
> but this is the first time I attempt to include rotation.
>
> I figured I don't want to include rotation in the pre-MS model, since I am
> looking for a certain rate
> on the ZAMS (which is shortly after the first model I restart from - the
> model relaxes quickly).
>
> Thank you,
>
> Yevgeni.
>
> On 20 July 2017 at 15:02, Frank Timmes <fx...@ma...> wrote:
>
>> inlist_massive_star creates a pre-main sequence model
>>
>>       create_pre_main_sequence_model = .true.
>>
>> rather than load a previous model. in such cases it can be useful
>> to turn on rotation when the pre-ms model is near zams. for example,
>>
>>       new_rotation_flag = .true.
>>       change_rotation_flag = .false.                 ! rotation off until
>> near zams
>>       near_zams_relax_omega_div_omega_crit = .true.  ! true to turn on
>> rotation at zams
>>       num_steps_to_relax_rotation = 100              ! use this many
>> steps in relaxing
>>       new_omega_div_omega_crit = 0.10d0
>>
>> explore http://mesa.sourceforge.net/star_job_defaults.html#rotation_
>> controls
>> to find the relevant controls for omega instead of the
>> omega_div_omega_crit
>> used in the above example.
>>
>> fxt
>>
>>
>>
>>
>> > On Jul 20, 2017, at 10:26 AM, Yevgeni Kissin <jen...@gm...>
>> wrote:
>> >
>> > Hi everyone,
>> >
>> > I am attempting to modify an inlist that has worked for me numerous
>> times, by adding controls for
>> > rotation and resulting mixing. Once I do so, all the controls below the
>> mixing values fail to be
>> > registered (i.e. their values revert to defaults).
>> >
>> > I am including the inlist here, and I enclosed the new values in '!!!!'
>> (should be evident).
>> >
>> > I tried moving the new values to the bottom of the inlist, but when I
>> run I get a series of messages:
>> > " s% omega(k)        ###     NaN "
>> > which I believe is due to me setting a rotation rate, without
>> activating mixing (hence the control
>> > command does not get recognized).
>> >
>> > Is there a limit to the length of the inlist, or what could be the
>> issue here?
>> >
>> > I will point out that this inlist is used to restart from an image of a
>> 3M_o pre-MS model which experienced
>> > accretion up to 13M_o (hence it's a 13M_o ZAMS model).
>> >
>> > Thank you very much.
>> >
>> > Yevgeni.
>> > <inlist_massive_star>---------------------------------------
>> ---------------------------------------
>> > 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] Angular momentum loss due to winds

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

On Jul 28, 2017 5:01 AM, "Glenn-Michael Oomen" <
gle...@ku...> wrote:

Hi Pablo,

The issue with the mdot_system_wind is indeed fixed in this way. I have
been working with it a couple days now together with the
other_binary_wind_transfer hook.

The absence of the Eddington limit is also a good catch, I hadn't thought
about that yet. Getting a proper framework for wind mass transfer in Mesa
is a good idea, since it is starting to become important in the evolution
of binaries with an evolved component.


Also, if you have simple examples that can be used to validate the
implementation of these processes, we could include them in the test_suite
such that they are automatically tested with each release.


To be honest, I am not really sure how the test_suite actually works. To
check whether the implementation works, I simply print stuff out. For the
example of the mdot_system_wind, I can give a specific mass loss rate of
the donor star and a specific wind accretion fraction, such that I exactly
know what the wind mass lost from the system should be...

Finally, I noticed you revamped the edot section in the newest version,
which is a great improvement. The previous fix in edot_tidal seems to be
reversed there, though. Another small issue is in
edot_enhancement_Isotropic, where edot_theta should be calculated with the
mass lost from the system instead of the total mass loss from the donor.
But I have the impression that this is still under construction, so it does
not matter that much.


Yes, I'm going through most of this code in detail now, and will be
building tests for it. Keep the bugfixes coming though! The reversal of
edot_tidal is a consequence of me having a thousand different copies of
MESA at the same time...

The idea for the test_suite is that if you know the result you should get
for a given system, one can check for that in run_star_extras. Analytical
results are the best for this, but a well established theoretical result
that can be loosely checked works as well.


Cheers,
Glenn


------------------------------
*Van:* Pablo Marchant <pa...@gm...>
*Verzonden:* donderdag 27 juli 2017 05:08
*Aan:* Glenn-Michael Oomen
*CC:* mes...@li...
*Onderwerp:* Re: [mesa-users] Angular momentum loss due to winds

Hi Glenn-Michael, thanks for reporting this.

Version 9921 contains the fix you suggest, could you please verify it works
as you expect. Note that while changing this I noticed an additional error,
wind mass transfer is ignoring the Eddington limit. Depending on what
you're doing that could be an issue for you as well. Will try to fix it as
soon as I can.

Also, if you have simple examples that can be used to validate the
implementation of these processes, we could include them in the test_suite
such that they are automatically tested with each release.

Cheers

On Wed, Jul 12, 2017 at 4:41 AM, Glenn-Michael Oomen <
gle...@ku...> wrote:

> Note:
>
> Subtracting b% mdot_wind_transfer(b% d_i)​ should also do the trick.
> ------------------------------
> *Van:* Glenn-Michael Oomen
> *Verzonden:* woensdag 12 juli 2017 11:09
> *Aan:* mes...@li...
> *Onderwerp:* Angular momentum loss due to winds
>
>
> Hi Mesa,
>
>
> There might be a small problem with how the loss of angular momentum due
> to stellar winds is computed. It appears to me that b% mdot_system_wind is
> not actually the mass lost due to stellar winds from the system, but the total
> wind mass loss.
>
>
> So suppose I would for some reason impose a conservative wind mass
> transfer such that all the wind is transferred to the companion, then I
> would expect b% mdot_system_wind(b% d_i) to be zero, which is not the
> case. The bottom line is that this gives an overestimate for b% jdot_ml.
>
>
> The issue is in line 290 (and 293) in binary_evolve.f90, where b%
> mdot_system_wind appears to be defined simply as the wind mass loss of
> the star. I think that the whole equation should be multiplied by (1 - b%
> wind_xfer_fraction(s_i)) as to account for wind mass transfer to the
> companion and vice versa.
>
>
> Cheers,
>
> Glenn-Michael Oomen
>
>
>
>
>
>
> ------------------------------------------------------------
> ------------------
> 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 on Astrophysics, Argelander-Institut für Astronomie, Universität Bonn

Re: [mesa-users] Angular momentum loss due to winds

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

Hi Pablo,

The issue with the mdot_system_wind is indeed fixed in this way. I have been working with it a couple days now together with the other_binary_wind_transfer hook.

The absence of the Eddington limit is also a good catch, I hadn't thought about that yet. Getting a proper framework for wind mass transfer in Mesa is a good idea, since it is starting to become important in the evolution of binaries with an evolved component.

Also, if you have simple examples that can be used to validate the implementation of these processes, we could include them in the test_suite such that they are automatically tested with each release.

To be honest, I am not really sure how the test_suite actually works. To check whether the implementation works, I simply print stuff out. For the example of the mdot_system_wind, I can give a specific mass loss rate of the donor star and a specific wind accretion fraction, such that I exactly know what the wind mass lost from the system should be...

Finally, I noticed you revamped the edot section in the newest version, which is a great improvement. The previous fix in edot_tidal seems to be reversed there, though. Another small issue is in edot_enhancement_Isotropic, where edot_theta should be calculated with the mass lost from the system instead of the total mass loss from the donor. But I have the impression that this is still under construction, so it does not matter that much.

Cheers,
Glenn


________________________________
Van: Pablo Marchant <pa...@gm...>
Verzonden: donderdag 27 juli 2017 05:08
Aan: Glenn-Michael Oomen
CC: mes...@li...
Onderwerp: Re: [mesa-users] Angular momentum loss due to winds

Hi Glenn-Michael, thanks for reporting this.

Version 9921 contains the fix you suggest, could you please verify it works as you expect. Note that while changing this I noticed an additional error, wind mass transfer is ignoring the Eddington limit. Depending on what you're doing that could be an issue for you as well. Will try to fix it as soon as I can.

Also, if you have simple examples that can be used to validate the implementation of these processes, we could include them in the test_suite such that they are automatically tested with each release.

Cheers

On Wed, Jul 12, 2017 at 4:41 AM, Glenn-Michael Oomen <gle...@ku...<mailto:gle...@ku...>> wrote:

Note:

Subtracting b% mdot_wind_transfer(b% d_i)? should also do the trick.

________________________________
Van: Glenn-Michael Oomen
Verzonden: woensdag 12 juli 2017 11:09
Aan: mes...@li...<mailto:mes...@li...>
Onderwerp: Angular momentum loss due to winds


Hi Mesa,


There might be a small problem with how the loss of angular momentum due to stellar winds is computed. It appears to me that b% mdot_system_wind is not actually the mass lost due to stellar winds from the system, but the total wind mass loss.


So suppose I would for some reason impose a conservative wind mass transfer such that all the wind is transferred to the companion, then I would expect b% mdot_system_wind(b% d_i) to be zero, which is not the case. The bottom line is that this gives an overestimate for b% jdot_ml.


The issue is in line 290 (and 293) in binary_evolve.f90, where b% mdot_system_wind appears to be defined simply as the wind mass loss of the star. I think that the whole equation should be multiplied by (1 - b% wind_xfer_fraction(s_i)) as to account for wind mass transfer to the companion and vice versa.


Cheers,

Glenn-Michael Oomen





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




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

Re: [mesa-users] Angular momentum loss due to winds

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

Hi Glenn-Michael, thanks for reporting this.

Version 9921 contains the fix you suggest, could you please verify it works
as you expect. Note that while changing this I noticed an additional error,
wind mass transfer is ignoring the Eddington limit. Depending on what
you're doing that could be an issue for you as well. Will try to fix it as
soon as I can.

Also, if you have simple examples that can be used to validate the
implementation of these processes, we could include them in the test_suite
such that they are automatically tested with each release.

Cheers

On Wed, Jul 12, 2017 at 4:41 AM, Glenn-Michael Oomen <
gle...@ku...> wrote:

> Note:
>
> Subtracting b% mdot_wind_transfer(b% d_i)​ should also do the trick.
> ------------------------------
> *Van:* Glenn-Michael Oomen
> *Verzonden:* woensdag 12 juli 2017 11:09
> *Aan:* mes...@li...
> *Onderwerp:* Angular momentum loss due to winds
>
>
> Hi Mesa,
>
>
> There might be a small problem with how the loss of angular momentum due
> to stellar winds is computed. It appears to me that b% mdot_system_wind is
> not actually the mass lost due to stellar winds from the system, but the total
> wind mass loss.
>
>
> So suppose I would for some reason impose a conservative wind mass
> transfer such that all the wind is transferred to the companion, then I
> would expect b% mdot_system_wind(b% d_i) to be zero, which is not the
> case. The bottom line is that this gives an overestimate for b% jdot_ml.
>
>
> The issue is in line 290 (and 293) in binary_evolve.f90, where b%
> mdot_system_wind appears to be defined simply as the wind mass loss of
> the star. I think that the whole equation should be multiplied by (1 - b%
> wind_xfer_fraction(s_i)) as to account for wind mass transfer to the
> companion and vice versa.
>
>
> Cheers,
>
> Glenn-Michael Oomen
>
>
>
>
>
>
> ------------------------------------------------------------
> ------------------
> 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 on Astrophysics, Argelander-Institut für Astronomie, Universität Bonn

Re: [mesa-users] magnetic braking Kawaler1988?

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

Ans just as a reference for those interested in implementing this in a
binary system, for that you would need to use the hook use_other_jdot_mb,
the usage of which is explained in
$MESA_DIR/binary/other/mod_other_binary_jdot.f90

cheers

On Mon, Jul 24, 2017 at 10:46 AM, Jacqueline Den Hartogh <
j.d...@ke...> wrote:

> Thanks Bill! Yes it's single stars I'm after :)
>
> On 24 Jul 2017 16:40, "Bill Paxton" <pa...@ki...> wrote:
>
>> Hi Jacqueline,
>>
>> At the level of binaries, I'll let Pablo respond (if that's of interest
>> to you).
>> For the single star case, you should use the hook "other_torque".
>> Or if necessary because of time-scales similar to time-steps,
>> 'other_torque_implicit'.
>>
>> Cheers,
>> Bill
>>
>>
>> On Jul 24, 2017, at 6:30 AM, Jacqueline Den Hartogh wrote:
>>
>> > Hi mesa friends,
>> >
>> > I'm looking into magnetic braking in low mass stars and was wondering
>> if Kawaler1988's equations are included in MESA? So far I've done a search
>> in the default sections on the mesa-website as well as an egrep in
>> mesa8845/star, but I haven't been able to find anything... Before I try to
>> implement them myself, I figured sending an email to this mailing list
>> would be smart. Any advice is welcome!
>> >
>> > Thanks!
>> >
>> > Jacqueline
>> > ------------------------------------------------------------
>> ------------------
>> > 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
>
>


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

Re: [mesa-users] magnetic braking Kawaler1988?

[Jacqueline D. H. <j.d...@ke...>]

Thanks Bill! Yes it's single stars I'm after :)

On 24 Jul 2017 16:40, "Bill Paxton" <pa...@ki...> wrote:

> Hi Jacqueline,
>
> At the level of binaries, I'll let Pablo respond (if that's of interest to
> you).
> For the single star case, you should use the hook "other_torque".
> Or if necessary because of time-scales similar to time-steps,
> 'other_torque_implicit'.
>
> Cheers,
> Bill
>
>
> On Jul 24, 2017, at 6:30 AM, Jacqueline Den Hartogh wrote:
>
> > Hi mesa friends,
> >
> > I'm looking into magnetic braking in low mass stars and was wondering if
> Kawaler1988's equations are included in MESA? So far I've done a search in
> the default sections on the mesa-website as well as an egrep in
> mesa8845/star, but I haven't been able to find anything... Before I try to
> implement them myself, I figured sending an email to this mailing list
> would be smart. Any advice is welcome!
> >
> > Thanks!
> >
> > Jacqueline
> > ------------------------------------------------------------
> ------------------
> > 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] magnetic braking Kawaler1988?

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

Hi Jacqueline,

At the level of binaries, I'll let Pablo respond (if that's of interest to you).
For the single star case, you should use the hook "other_torque".  
Or if necessary because of time-scales similar to time-steps, 'other_torque_implicit'.

Cheers,
Bill


On Jul 24, 2017, at 6:30 AM, Jacqueline Den Hartogh wrote:

> Hi mesa friends,
> 
> I'm looking into magnetic braking in low mass stars and was wondering if Kawaler1988's equations are included in MESA? So far I've done a search in the default sections on the mesa-website as well as an egrep in mesa8845/star, but I haven't been able to find anything... Before I try to implement them myself, I figured sending an email to this mailing list would be smart. Any advice is welcome!
> 
> Thanks!
> 
> Jacqueline
> ------------------------------------------------------------------------------
> 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] magnetic braking Kawaler1988?

[Jacqueline D. H. <j.d...@ke...>]

Hi mesa friends,

I'm looking into magnetic braking in low mass stars and was wondering if
Kawaler1988's equations are included in MESA? So far I've done a search in
the default sections on the mesa-website as well as an egrep in
mesa8845/star, but I haven't been able to find anything... Before I try to
implement them myself, I figured sending an email to this mailing list
would be smart. Any advice is welcome!

Thanks!

Jacqueline

Re: [mesa-users] new net

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

Hi Bruno,

> The reactions seem correct ...

The reaction

  ne20(p,g)ne21

doesn't make sense.  It doesn't conserve charge.

Josiah

Re: [mesa-users] new net

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

you need to provide enough information for 
someone to replicate the issue. try sending
your inlists and any other pertinent files.

fxt



> On Jul 23, 2017, at 7:29 PM, Bruno Lustosa <bru...@gm...> wrote:
> 
> 
> Hello everyone
> 
> I copied a network of reactions I came across these errors. What could be wrong? The reactions seem correct ...
> 
>  add_reaction_for_handle failed in reaclib_parse_handle rne20pg_to_ne21
>  failed in add_reaction_for_handle for rne20pg_to_ne21
>  ierr from add_reaction_for_this_handle rne20pg_to_ne21
>  add_reaction failed: unknown reaction name rne20pg_to_ne21
>  set_net failed in net_tables
>  failed in set_net
>  star_create_pre_ms_model ierr          -1
>  do_load1_star ierr          -1
>  before_evolve_loop ierr          -1
> 
> Best,
> 
> Bruno
> ------------------------------------------------------------------------------
> 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 net

[Bruno L. <bru...@gm...>]

Hello everyone

I copied a network of reactions I came across these errors. What could be
wrong? The reactions seem correct ...

 *add_reaction_for_handle failed in reaclib_parse_handle rne20pg_to_ne21*
* failed in add_reaction_for_handle for rne20pg_to_ne21*
* ierr from add_reaction_for_this_handle rne20pg_to_ne21*
* add_reaction failed: unknown reaction name rne20pg_to_ne21*
* set_net failed in net_tables*
* failed in set_net*
* star_create_pre_ms_model ierr          -1*
* do_load1_star ierr          -1*
* before_evolve_loop ierr          -1*

Best,

Bruno

Re: [mesa-users] Information

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

HI Abdel,

From $MESA_DIR/star/defaults/history_columns.list right before epsnuc_M_1 and friends:

   !## regions of strong nuclear burning

      ! 2 zones where eps_nuc > burn_min1 erg/g/s
      ! for each zone have 4 numbers: start1, start2, end2, end1
      ! start1 is mass of inner edge where first goes > burn_min1 (or -20 if none such)
      ! start2 is mass of inner edge where first zone reaches burn_min2 erg/g/sec (or -20 if none such)
      ! end2 is mass of outer edge where first zone drops back below burn_min2 erg/g/s
      ! end1 is mass of outer edge where first zone ends (i.e. eps_nuc < burn_min1)
      ! similar for the second zone

and then from $MESA_DIR/star/defaults/controls.list:


         !### burn_min1

         ! used for reporting where burning zone occur, for example in the pgstar TRho profiles.
         ! see `star/public/star_data.inc` for details.
         ! must be < `burn_min2`.
         ! In ergs/g/sec.

      burn_min1 = 50

         !### burn_min2

         ! used for reporting where burning zone occur, for example in the pgstar TRho profiles.
         ! see `star/public/star_data.inc` for details.
         ! In ergs/g/sec.

      burn_min2 = 1000


So you set burn_min1 and burn_min2 in your inlist, and then in your output, you get the mass coordinates showing where eps_nuc is greater than these values. It’s a way of tracking the size and locations of regions of strong burning. Between M(r) = eps_nuc_M1 and M(r) = eps_nuc_M4, eps_nuc > burn_min1. Between M(r) = eps_nuc_M2 and M(r) = eps_nuc_M3, eps_nuc > burn_min2.

Similar story for the next 4, which deal with the next most massive burning zone (I would assume).

Regards,

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

UCSB Department of Physics 

On July 23, 2017 at 5:03:27 PM, AbdelBassit Abdessamed Senhadji (se...@ho...) wrote:

Hi MESA users :

 

Please, is it possible to know what is the meaning of : epsnuc_M_1 and it goes to epsnuc_M_8.

 

Thanks

 

Abdel

 

------------------------------------------------------------------------------  
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] Information

[AbdelBassit A. S. <se...@ho...>]

Hi MESA users :

Please, is it possible to know what is the meaning of : epsnuc_M_1 and it goes to epsnuc_M_8.

Thanks

Abdel

Re: [mesa-users] Proper use of eosDE

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

hi phil,

presumably you are following up on the intentions stated in the recent arxiv posting
https://arxiv.org/abs/1707.05333

two points for now:


> When this energy is use to try to find a temperature in the Helmholtz equation of state,
> the code essentially crashed (as it should).  

let's be clear. helmeos does not crash. what crashes is the root-find 
for the temperature because the specified (energy, density) pair has
no thermodynamic solution. this situation usually arises because an 
explicit hydrocode just takes timestep without regard to the thermodynamic 
validity of the extrapolated state. no eos, including mesa's, will 
solve this problem. the usual fix in explicit hydrocodes, as noted 
in the changa paper mentioned above, is to impose a floor level on 
the evolved variables such that any state remains thermodynamically valid.


> How does one decide on a proper T_guess?

if there is no prior information on a valid thermodynamic state, 
say from the initial conditions or the previous timestep, then my 
usual approach is to guess the temperature using simple expressions
for the conditions of interest, e.g., ideal gas, or a one term expansion
in degenerate regimes to pick up the first temperature dependent term.

fxt






> On Jul 23, 2017, at 8:28 AM, Bill Paxton <pa...@ki...> wrote:
> 
> Hi Phil,
> 
> Great to hear from you.  I was recently wondering what you were up to these days.
> 
> Your questions are an excellent synopsis of why I dislike using density and energy as primary EOS variables in an evolution code.
> Given my bias against it, you'll probably get better advice from someone else, for example someone who uses HELM for their hydro code.
> The best way to avoid the problems you mention is to use density and temperature as your basic variables so you are in harmony with the input physics.
> I can do that with my implicit hydro, including the new version using approximate Riemann HLLC, but it may not be possible for you.  Life is hard.
> 
> Good luck - I'm sure you'll find a way to make it work.
> 
> Bill
> 
> 
> 
> 
> On Jul 22, 2017, at 11:04 PM, Philip Chang wrote:
> 
>> Hi,
>> 
>> I'm integrating the mesa eos module into a hydro code that I am writing/written.  I have lots of experience with Frank Timmes Helmholtz eos (which I got from his website), but for my new code I am going to use the MESA eos.  Anyhow, my hydro code gives me an internal energy and density and I want to get other thermal quantities, i.e., temperature, entropy, adiabatic index, etc.
>> 
>> The way to do this is using eosDE_get, but I'm not sure what the proper use of this was and was hoping that someone knew offhand. I am using the latest public release 9793.  In particular, my questions are:
>> 
>> 1. How does one decide on a proper T_guess?  I looked in the mesa-star code, and it appears that one want to use the temperature from the previous step.  I'm wondering how good is this as a shock can move though a cell and totally mess everything up.
>> 
>> 2. An improper T_guess can usually be corrected, i.e., it produced values that are obviously wrong.  I have tried a guess of 1e2 and 1e8 and usually if one fails then the other gives you a good value. But this is not always the case, for instance, consider this particular pathological case: rho = 794.32840915212967, T=158489.31924611141, solar metallicity.
>> 
>> For T_guess = 1e7, I find T = 202665.40667059086
>> 
>> For T_guess = 1e2, I find T = 257198.81215480756
>> 
>> In this case both are wrong by order unity.  This is a particular bad case as both guess give poor answers.  But there are cases where one guess give a good answer, but the other does not, and it is not obvious which one I should trust.  Any ideas?
>> 
>> 3. What happens when the internal energy is too low?  For instance, in my previous experience with the Helmholtz equation of state (from Frank Timmes website), small fluctuations can drop the internal energy below the fermi energy.  When this energy is use to try to find a temperature in the Helmholtz equation of state, the code essentially crashed (as it should).  In this case, I prechecked the internal energy to ensure that it is valid.  What happens if I give the eosDE_get an internal energy that is physically too small.
>> 
>> Thanks in advance for any help.
>> 
>> Cheers,
>> 
>> Phil Chang
>> 
>> 
>> ------------------------------------------------------------------------------
>> 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