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

mesa-users] restart a run

[jingluan <jin...@ca...>]

Hello,

I use Ctrl+c to pause a run, revise run_star_extras.f to write s% 
lnRdot(1) on terminal, and use ./re x980 to re-start the run by photo 
x980. But it did not print what to be expected....., but mesa can 
recognize the change in inlist_project (I ask it to save model with 
model number=1000) and do what is asked......

How to set mesa to recognize the change in run_star_extras.f too? I 
attached it here.

Thank you very much :-)


-- 
Sincerely
Jing

Ph.D candidate at physics.caltech
email: jin...@ca...
address: MC350-17,Caltech,1200E.California Blvd,
          Pasadena, CA 91125

Re: mesa-users] Manual Change of Accretion Composition

[Max K. <ka...@rp...>]

Bill,

I was intentionally using the WD with the H/He stripped off to see if I
could use a pure C/O white dwarf. At any rate, I tried accreting just helium
onto the surface of the pure C/O WD to avoid the ignition problem, but I
received the same result. I also received the same result by trying to do
the same thing (accrete pure helium, as well as H/He) on a model with H/He
remaining on the surface.

Max Katz
Rensselaer Polytechnic Institute
Physics, Class of 2011


On Fri, Jul 2, 2010 at 2:30 PM, Bill Paxton <pa...@ki...> wrote:

> Hi Max,
>
> Please try a different WD --- one that already has some H/He on the
> surface.
> Most of the ones in data/star_data/white_dwarf_models have some.
> I artificially removed the outer H/He for the 1.000 Msun WD's, and that
> might be the source of the problem you are seeing.
>
> -B
>
>
>
>
>
>
>
> On Jul 2, 2010, at 11:23 AM, Max Katz wrote:
>
> Bill,
>
> After playing around some more I realized a critical flaw - I did not
> change one of the other necessary parameters, mass_change_full_off_dt - this
> parameter gives the number of seconds below which mass change is
> automatically turned off. Since it is initially set at 1d3, the code was
> just going to a lower time-step where the mass change would be turned off.
> To combat this, I decreased this to a very small number (like 1e-7) and also
> changed min_timestep_limit to 1e-10 (the latter is also measured in
> seconds). However, the code just kept on changing to a smaller time-step,
> low enough that it could evade mass addition (at one point it was around
> 10^-13 years).
>
> I also tried starting with accretion composition the same as the surface,
> then after it was satisfied with the accretion, dropping the accretion rate
> to a lower number and manually changing the composition. This, unfortunately
> did not work either - as soon as I changed the composition, it went to very
> low time-steps where mass change was zero. I'm open to other suggestions if
> anyone has ideas on how to relax the mass change in.
>
> I also wanted to see if I could relax in the composition change - so I set
> the following in the controls inlist - the idea was to accrete something of
> similar, but not the same, composition, and then gradually increase the H/He
> and decrease the C/O. However, when I do this the code returns an error and
> crashes (*** glibc detected *** ./star: free(): invalid pointer:
> 0x00007fdfcc000d50 ***).
>
>          accretion_h1 = 0.01 ! mass fraction
>      accretion_h2 = 0.
>      accretion_he3 = 0.
>          accretion_he4 = 0.01
>      accretion_zfracs = 0
>
>          z_fraction_li = 0.
>          z_fraction_be = 0.
>          z_fraction_b = 0.
>          z_fraction_c = 0.63
>          z_fraction_n = 0.
>          z_fraction_o = 0.37
>          z_fraction_f = 0.
>          z_fraction_ne = 0.
>          z_fraction_na = 0.
>          z_fraction_mg = 0.
>          z_fraction_al = 0.
>          z_fraction_si = 0.
>          z_fraction_p = 0.
>          z_fraction_s = 0.
>          z_fraction_cl = 0.
>          z_fraction_ar = 0.
>          z_fraction_k = 0.
>          z_fraction_ca = 0.
>          z_fraction_sc = 0.
>          z_fraction_ti = 0.
>          z_fraction_v = 0.
>          z_fraction_cr = 0.
>          z_fraction_mn = 0.
>          z_fraction_fe = 0.
>          z_fraction_co = 0.
>          z_fraction_ni = 0.
>          z_fraction_cu = 0.
>          z_fraction_zn = 0.
>
> Max Katz
> Rensselaer Polytechnic Institute
> Physics, Class of 2011
>
>
> On Fri, Jul 2, 2010 at 1:06 PM, Max Katz <ka...@rp...> wrote:
>
>> Bill,
>>
>> The simulation works just fine without accretion, and mass change without
>> manual composition change works fine - it just accretes C and O (I noticed
>> that after a while something started happening where the timestep got really
>> small, but I didn't wait around long enough to see what happened).
>>
>> I tried your suggestion, both at your suggested settings and even smaller
>> ones, and the same result occurred. I set max_backups_in_a_row to 50, and I
>> noticed that after a number of retries, it eventually gives up on mass
>> change and continues without it (lg Mdot is -99 on the pgplot screen); I
>> even stopped it, increased the mass_change rate and restarted, and it
>> continued on with zero mass change, without any backups or retries.
>>
>> - Max
>>
>>
>> On Fri, Jul 2, 2010 at 12:08 PM, Bill Paxton <pa...@ki...>wrote:
>>
>>>
>>>
>>> Hi Max,
>>>
>>> The change in accretion composition should be fine.  Perhaps the problem
>>> is the abrupt start of accretion at the 5d-9 rate.
>>>
>>> Let's separate the 2.   What happens if you do the 5d-9 mass change
>>> without changing the accretion composition?
>>>
>>> Also, you should try manually turning up the accretion rate while keeping
>>> the timestep small.
>>>
>>> Try something like max_years_for_timestep = 1d-7 to start with, and
>>> mass_change = 1d-12 -- or whatever it
>>> takes to get things to converge.   (BTW: I'm assuming that everything
>>> works without accretion turned on, right?)
>>> Let things run for a while until it is happy (i.e., running at max
>>> allowed timestep).   Then start increasing the
>>> mass_change -- at each increment, let it run until it is happy, then
>>> increase again.  Once you reach the
>>> desired accretion rate, remove the limit on max_years_for_timestep.
>>>
>>> This is a crude manual version of what the various "relax" operations do.
>>>  And if you feel ambitious, you can
>>> write your own relax routine to do "relax_to_mass_change".
>>>
>>> Let me know how it goes.
>>>
>>> -Bill
>>>
>>>
>>>
>>>
>>>
>>> On Jul 2, 2010, at 6:46 AM, Max Katz wrote:
>>>
>>> > Hello,
>>> >
>>> > In an attempt to create my own nova, I used the model 1.000_Tc_3e7.mod
>>> in mesa/data/star_data/white_dwarf_models. This is a pure C/O white dwarf of
>>> 1 solar mass. The goal is to get it to go nova, so I set an accretion rate
>>> of 5 x 10^-9 (units are solar masses per year). However, the default
>>> behavior for accretion is to use the same composition for the accreted
>>> matter as there is on the surface. Since adding C and O to the surface
>>> wouldn't yield the nova I was looking for, I set the following in the
>>> controls namelist:
>>> >
>>> > mass_change = 5d-9
>>> > accrete_same_as_surface = .false.
>>> > accretion_h1 = 0.75
>>> > accretion_h2 = 0.
>>> > accretion_he3 = 0.
>>> > accretion_he4 = 0.25
>>> >
>>> > However, when I try to run with these settings on, the run cites
>>> "adjust_mass_failed", and crashes after hitting the default max number of
>>> backups (15). I tried the same settings on a different case and got the same
>>> error. If anyone has experience with changing the accretion composition, I
>>> would appreciate it if you could give some insight as to what I might be
>>> doing wrong. Thanks.
>>> >
>>> > Max Katz
>>> > Rensselaer Polytechnic Institute
>>> > Physics, Class of 2011
>>> >
>>> ------------------------------------------------------------------------------
>>> > This SF.net email is sponsored by Sprint
>>> > What will you do first with EVO, the first 4G phone?
>>> > Visit sprint.com/first --
>>> http://p.sf.net/sfu/sprint-com-first_______________________________________________
>>> > mesa-users mailing list
>>> > mes...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/mesa-users
>>>
>>>
>>
>
>

Re: mesa-users] Manual Change of Accretion Composition

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

Hi Max,

Please try a different WD --- one that already has some H/He on the surface.
Most of the ones in data/star_data/white_dwarf_models have some.
I artificially removed the outer H/He for the 1.000 Msun WD's, and that
might be the source of the problem you are seeing.

-B







On Jul 2, 2010, at 11:23 AM, Max Katz wrote:

> Bill,
> 
> After playing around some more I realized a critical flaw - I did not change one of the other necessary parameters, mass_change_full_off_dt - this parameter gives the number of seconds below which mass change is automatically turned off. Since it is initially set at 1d3, the code was just going to a lower time-step where the mass change would be turned off. To combat this, I decreased this to a very small number (like 1e-7) and also changed min_timestep_limit to 1e-10 (the latter is also measured in seconds). However, the code just kept on changing to a smaller time-step, low enough that it could evade mass addition (at one point it was around 10^-13 years).
> 
> I also tried starting with accretion composition the same as the surface, then after it was satisfied with the accretion, dropping the accretion rate to a lower number and manually changing the composition. This, unfortunately did not work either - as soon as I changed the composition, it went to very low time-steps where mass change was zero. I'm open to other suggestions if anyone has ideas on how to relax the mass change in.
> 
> I also wanted to see if I could relax in the composition change - so I set the following in the controls inlist - the idea was to accrete something of similar, but not the same, composition, and then gradually increase the H/He and decrease the C/O. However, when I do this the code returns an error and crashes (*** glibc detected *** ./star: free(): invalid pointer: 0x00007fdfcc000d50 ***).
> 
>          accretion_h1 = 0.01 ! mass fraction
>      accretion_h2 = 0.
>      accretion_he3 = 0.
>          accretion_he4 = 0.01
>      accretion_zfracs = 0
> 
>          z_fraction_li = 0.
>          z_fraction_be = 0.
>          z_fraction_b = 0.
>          z_fraction_c = 0.63
>          z_fraction_n = 0.
>          z_fraction_o = 0.37
>          z_fraction_f = 0.
>          z_fraction_ne = 0.
>          z_fraction_na = 0.
>          z_fraction_mg = 0.
>          z_fraction_al = 0.
>          z_fraction_si = 0.
>          z_fraction_p = 0.
>          z_fraction_s = 0.
>          z_fraction_cl = 0.
>          z_fraction_ar = 0.
>          z_fraction_k = 0.
>          z_fraction_ca = 0.
>          z_fraction_sc = 0.
>          z_fraction_ti = 0.
>          z_fraction_v = 0.
>          z_fraction_cr = 0.
>          z_fraction_mn = 0.
>          z_fraction_fe = 0.
>          z_fraction_co = 0.
>          z_fraction_ni = 0.
>          z_fraction_cu = 0.
>          z_fraction_zn = 0.
> 
> Max Katz
> Rensselaer Polytechnic Institute
> Physics, Class of 2011
> 
> 
> On Fri, Jul 2, 2010 at 1:06 PM, Max Katz <ka...@rp...> wrote:
> Bill,
> 
> The simulation works just fine without accretion, and mass change without manual composition change works fine - it just accretes C and O (I noticed that after a while something started happening where the timestep got really small, but I didn't wait around long enough to see what happened).
> 
> I tried your suggestion, both at your suggested settings and even smaller ones, and the same result occurred. I set max_backups_in_a_row to 50, and I noticed that after a number of retries, it eventually gives up on mass change and continues without it (lg Mdot is -99 on the pgplot screen); I even stopped it, increased the mass_change rate and restarted, and it continued on with zero mass change, without any backups or retries.
> 
> - Max
> 
> 
> On Fri, Jul 2, 2010 at 12:08 PM, Bill Paxton <pa...@ki...> wrote:
> 
> 
> Hi Max,
> 
> The change in accretion composition should be fine.  Perhaps the problem is the abrupt start of accretion at the 5d-9 rate.
> 
> Let's separate the 2.   What happens if you do the 5d-9 mass change without changing the accretion composition?
> 
> Also, you should try manually turning up the accretion rate while keeping the timestep small.
> 
> Try something like max_years_for_timestep = 1d-7 to start with, and mass_change = 1d-12 -- or whatever it
> takes to get things to converge.   (BTW: I'm assuming that everything works without accretion turned on, right?)
> Let things run for a while until it is happy (i.e., running at max allowed timestep).   Then start increasing the
> mass_change -- at each increment, let it run until it is happy, then increase again.  Once you reach the
> desired accretion rate, remove the limit on max_years_for_timestep.
> 
> This is a crude manual version of what the various "relax" operations do.  And if you feel ambitious, you can
> write your own relax routine to do "relax_to_mass_change".
> 
> Let me know how it goes.
> 
> -Bill
> 
> 
> 
> 
> 
> On Jul 2, 2010, at 6:46 AM, Max Katz wrote:
> 
> > Hello,
> >
> > In an attempt to create my own nova, I used the model 1.000_Tc_3e7.mod in mesa/data/star_data/white_dwarf_models. This is a pure C/O white dwarf of 1 solar mass. The goal is to get it to go nova, so I set an accretion rate of 5 x 10^-9 (units are solar masses per year). However, the default behavior for accretion is to use the same composition for the accreted matter as there is on the surface. Since adding C and O to the surface wouldn't yield the nova I was looking for, I set the following in the controls namelist:
> >
> > mass_change = 5d-9
> > accrete_same_as_surface = .false.
> > accretion_h1 = 0.75
> > accretion_h2 = 0.
> > accretion_he3 = 0.
> > accretion_he4 = 0.25
> >
> > However, when I try to run with these settings on, the run cites "adjust_mass_failed", and crashes after hitting the default max number of backups (15). I tried the same settings on a different case and got the same error. If anyone has experience with changing the accretion composition, I would appreciate it if you could give some insight as to what I might be doing wrong. Thanks.
> >
> > Max Katz
> > Rensselaer Polytechnic Institute
> > Physics, Class of 2011
> > ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________
> > mesa-users mailing list
> > mes...@li...
> > https://lists.sourceforge.net/lists/listinfo/mesa-users
> 
> 
> 

Re: mesa-users] Manual Change of Accretion Composition

[Max K. <ka...@rp...>]

Bill,

After playing around some more I realized a critical flaw - I did not change
one of the other necessary parameters, mass_change_full_off_dt - this
parameter gives the number of seconds below which mass change is
automatically turned off. Since it is initially set at 1d3, the code was
just going to a lower time-step where the mass change would be turned off.
To combat this, I decreased this to a very small number (like 1e-7) and also
changed min_timestep_limit to 1e-10 (the latter is also measured in
seconds). However, the code just kept on changing to a smaller time-step,
low enough that it could evade mass addition (at one point it was around
10^-13 years).

I also tried starting with accretion composition the same as the surface,
then after it was satisfied with the accretion, dropping the accretion rate
to a lower number and manually changing the composition. This, unfortunately
did not work either - as soon as I changed the composition, it went to very
low time-steps where mass change was zero. I'm open to other suggestions if
anyone has ideas on how to relax the mass change in.

I also wanted to see if I could relax in the composition change - so I set
the following in the controls inlist - the idea was to accrete something of
similar, but not the same, composition, and then gradually increase the H/He
and decrease the C/O. However, when I do this the code returns an error and
crashes (*** glibc detected *** ./star: free(): invalid pointer:
0x00007fdfcc000d50 ***).

         accretion_h1 = 0.01 ! mass fraction
     accretion_h2 = 0.
     accretion_he3 = 0.
         accretion_he4 = 0.01
     accretion_zfracs = 0

         z_fraction_li = 0.
         z_fraction_be = 0.
         z_fraction_b = 0.
         z_fraction_c = 0.63
         z_fraction_n = 0.
         z_fraction_o = 0.37
         z_fraction_f = 0.
         z_fraction_ne = 0.
         z_fraction_na = 0.
         z_fraction_mg = 0.
         z_fraction_al = 0.
         z_fraction_si = 0.
         z_fraction_p = 0.
         z_fraction_s = 0.
         z_fraction_cl = 0.
         z_fraction_ar = 0.
         z_fraction_k = 0.
         z_fraction_ca = 0.
         z_fraction_sc = 0.
         z_fraction_ti = 0.
         z_fraction_v = 0.
         z_fraction_cr = 0.
         z_fraction_mn = 0.
         z_fraction_fe = 0.
         z_fraction_co = 0.
         z_fraction_ni = 0.
         z_fraction_cu = 0.
         z_fraction_zn = 0.

Max Katz
Rensselaer Polytechnic Institute
Physics, Class of 2011


On Fri, Jul 2, 2010 at 1:06 PM, Max Katz <ka...@rp...> wrote:

> Bill,
>
> The simulation works just fine without accretion, and mass change without
> manual composition change works fine - it just accretes C and O (I noticed
> that after a while something started happening where the timestep got really
> small, but I didn't wait around long enough to see what happened).
>
> I tried your suggestion, both at your suggested settings and even smaller
> ones, and the same result occurred. I set max_backups_in_a_row to 50, and I
> noticed that after a number of retries, it eventually gives up on mass
> change and continues without it (lg Mdot is -99 on the pgplot screen); I
> even stopped it, increased the mass_change rate and restarted, and it
> continued on with zero mass change, without any backups or retries.
>
> - Max
>
>
> On Fri, Jul 2, 2010 at 12:08 PM, Bill Paxton <pa...@ki...> wrote:
>
>>
>>
>> Hi Max,
>>
>> The change in accretion composition should be fine.  Perhaps the problem
>> is the abrupt start of accretion at the 5d-9 rate.
>>
>> Let's separate the 2.   What happens if you do the 5d-9 mass change
>> without changing the accretion composition?
>>
>> Also, you should try manually turning up the accretion rate while keeping
>> the timestep small.
>>
>> Try something like max_years_for_timestep = 1d-7 to start with, and
>> mass_change = 1d-12 -- or whatever it
>> takes to get things to converge.   (BTW: I'm assuming that everything
>> works without accretion turned on, right?)
>> Let things run for a while until it is happy (i.e., running at max allowed
>> timestep).   Then start increasing the
>> mass_change -- at each increment, let it run until it is happy, then
>> increase again.  Once you reach the
>> desired accretion rate, remove the limit on max_years_for_timestep.
>>
>> This is a crude manual version of what the various "relax" operations do.
>>  And if you feel ambitious, you can
>> write your own relax routine to do "relax_to_mass_change".
>>
>> Let me know how it goes.
>>
>> -Bill
>>
>>
>>
>>
>>
>> On Jul 2, 2010, at 6:46 AM, Max Katz wrote:
>>
>> > Hello,
>> >
>> > In an attempt to create my own nova, I used the model 1.000_Tc_3e7.mod
>> in mesa/data/star_data/white_dwarf_models. This is a pure C/O white dwarf of
>> 1 solar mass. The goal is to get it to go nova, so I set an accretion rate
>> of 5 x 10^-9 (units are solar masses per year). However, the default
>> behavior for accretion is to use the same composition for the accreted
>> matter as there is on the surface. Since adding C and O to the surface
>> wouldn't yield the nova I was looking for, I set the following in the
>> controls namelist:
>> >
>> > mass_change = 5d-9
>> > accrete_same_as_surface = .false.
>> > accretion_h1 = 0.75
>> > accretion_h2 = 0.
>> > accretion_he3 = 0.
>> > accretion_he4 = 0.25
>> >
>> > However, when I try to run with these settings on, the run cites
>> "adjust_mass_failed", and crashes after hitting the default max number of
>> backups (15). I tried the same settings on a different case and got the same
>> error. If anyone has experience with changing the accretion composition, I
>> would appreciate it if you could give some insight as to what I might be
>> doing wrong. Thanks.
>> >
>> > Max Katz
>> > Rensselaer Polytechnic Institute
>> > Physics, Class of 2011
>> >
>> ------------------------------------------------------------------------------
>> > This SF.net email is sponsored by Sprint
>> > What will you do first with EVO, the first 4G phone?
>> > Visit sprint.com/first --
>> http://p.sf.net/sfu/sprint-com-first_______________________________________________
>> > mesa-users mailing list
>> > mes...@li...
>> > https://lists.sourceforge.net/lists/listinfo/mesa-users
>>
>>
>

Re: mesa-users] Manual Change of Accretion Composition

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

On Jul 2, 2010, at 10:06 AM, Max Katz wrote:

> The simulation works just fine without accretion, and mass change without manual composition change works fine - it just accretes C and O (I noticed that after a while something started happening where the timestep got really small, but I didn't wait around long enough to see what happened).
> 

The default is to accrete the same composition as the surface, so you must have a WD with no H/He on the surface, right?

If it is happy accreting C/O at that rate but fails with H/He, perhaps the surface conditions are such that the H/He immediately ignites.

Try running it for long enough to make sure the surface has cooled below the H ignition range and try again.  Any change?


> 
> I tried your suggestion, both at your suggested settings and even smaller ones, and the same result occurred. I set max_backups_in_a_row to 50, and I noticed that after a number of retries, it eventually gives up on mass change and continues without it (lg Mdot is -99 on the pgplot screen); I even stopped it, increased the mass_change rate and restarted, and it continued on with zero mass change, without any backups or retries.


At each backup, the code reduces the timestep.  Eventually it hits the limit for doing mass change.

         ! these params provide the option to turn off mass change when have small timesteps.
         ! mass change doesn't do much in such cases except make convergence harder.
         mass_change_full_on_dt = 1d4 ! (seconds)
         mass_change_full_off_dt = 1d3 ! (seconds)
         ! between these limits, mass change is gradually reduced

For dt < mass_change_full_off_dt, you'll get lgMdot of -99 meaning it has been shut off.

-B

Re: mesa-users] Manual Change of Accretion Composition

[Max K. <ka...@rp...>]

Bill,

The simulation works just fine without accretion, and mass change without
manual composition change works fine - it just accretes C and O (I noticed
that after a while something started happening where the timestep got really
small, but I didn't wait around long enough to see what happened).

I tried your suggestion, both at your suggested settings and even smaller
ones, and the same result occurred. I set max_backups_in_a_row to 50, and I
noticed that after a number of retries, it eventually gives up on mass
change and continues without it (lg Mdot is -99 on the pgplot screen); I
even stopped it, increased the mass_change rate and restarted, and it
continued on with zero mass change, without any backups or retries.

- Max

On Fri, Jul 2, 2010 at 12:08 PM, Bill Paxton <pa...@ki...> wrote:

>
>
> Hi Max,
>
> The change in accretion composition should be fine.  Perhaps the problem is
> the abrupt start of accretion at the 5d-9 rate.
>
> Let's separate the 2.   What happens if you do the 5d-9 mass change without
> changing the accretion composition?
>
> Also, you should try manually turning up the accretion rate while keeping
> the timestep small.
>
> Try something like max_years_for_timestep = 1d-7 to start with, and
> mass_change = 1d-12 -- or whatever it
> takes to get things to converge.   (BTW: I'm assuming that everything works
> without accretion turned on, right?)
> Let things run for a while until it is happy (i.e., running at max allowed
> timestep).   Then start increasing the
> mass_change -- at each increment, let it run until it is happy, then
> increase again.  Once you reach the
> desired accretion rate, remove the limit on max_years_for_timestep.
>
> This is a crude manual version of what the various "relax" operations do.
>  And if you feel ambitious, you can
> write your own relax routine to do "relax_to_mass_change".
>
> Let me know how it goes.
>
> -Bill
>
>
>
>
>
> On Jul 2, 2010, at 6:46 AM, Max Katz wrote:
>
> > Hello,
> >
> > In an attempt to create my own nova, I used the model 1.000_Tc_3e7.mod in
> mesa/data/star_data/white_dwarf_models. This is a pure C/O white dwarf of 1
> solar mass. The goal is to get it to go nova, so I set an accretion rate of
> 5 x 10^-9 (units are solar masses per year). However, the default behavior
> for accretion is to use the same composition for the accreted matter as
> there is on the surface. Since adding C and O to the surface wouldn't yield
> the nova I was looking for, I set the following in the controls namelist:
> >
> > mass_change = 5d-9
> > accrete_same_as_surface = .false.
> > accretion_h1 = 0.75
> > accretion_h2 = 0.
> > accretion_he3 = 0.
> > accretion_he4 = 0.25
> >
> > However, when I try to run with these settings on, the run cites
> "adjust_mass_failed", and crashes after hitting the default max number of
> backups (15). I tried the same settings on a different case and got the same
> error. If anyone has experience with changing the accretion composition, I
> would appreciate it if you could give some insight as to what I might be
> doing wrong. Thanks.
> >
> > Max Katz
> > Rensselaer Polytechnic Institute
> > Physics, Class of 2011
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first --
> http://p.sf.net/sfu/sprint-com-first_______________________________________________
> > mesa-users mailing list
> > mes...@li...
> > https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>

Re: mesa-users] Manual Change of Accretion Composition

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

Hi Max,

The change in accretion composition should be fine.  Perhaps the problem is the abrupt start of accretion at the 5d-9 rate.

Let's separate the 2.   What happens if you do the 5d-9 mass change without changing the accretion composition?

Also, you should try manually turning up the accretion rate while keeping the timestep small.

Try something like max_years_for_timestep = 1d-7 to start with, and mass_change = 1d-12 -- or whatever it
takes to get things to converge.   (BTW: I'm assuming that everything works without accretion turned on, right?)
Let things run for a while until it is happy (i.e., running at max allowed timestep).   Then start increasing the
mass_change -- at each increment, let it run until it is happy, then increase again.  Once you reach the
desired accretion rate, remove the limit on max_years_for_timestep.

This is a crude manual version of what the various "relax" operations do.  And if you feel ambitious, you can
write your own relax routine to do "relax_to_mass_change".

Let me know how it goes.

-Bill





On Jul 2, 2010, at 6:46 AM, Max Katz wrote:

> Hello,
> 
> In an attempt to create my own nova, I used the model 1.000_Tc_3e7.mod in mesa/data/star_data/white_dwarf_models. This is a pure C/O white dwarf of 1 solar mass. The goal is to get it to go nova, so I set an accretion rate of 5 x 10^-9 (units are solar masses per year). However, the default behavior for accretion is to use the same composition for the accreted matter as there is on the surface. Since adding C and O to the surface wouldn't yield the nova I was looking for, I set the following in the controls namelist:
> 
> mass_change = 5d-9
> accrete_same_as_surface = .false.
> accretion_h1 = 0.75
> accretion_h2 = 0.
> accretion_he3 = 0.
> accretion_he4 = 0.25
> 
> However, when I try to run with these settings on, the run cites "adjust_mass_failed", and crashes after hitting the default max number of backups (15). I tried the same settings on a different case and got the same error. If anyone has experience with changing the accretion composition, I would appreciate it if you could give some insight as to what I might be doing wrong. Thanks.
> 
> Max Katz
> Rensselaer Polytechnic Institute
> Physics, Class of 2011
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

mesa-users] Manual Change of Accretion Composition

[Max K. <ka...@rp...>]

Hello,

In an attempt to create my own nova, I used the model 1.000_Tc_3e7.mod in
mesa/data/star_data/white_dwarf_models. This is a pure C/O white dwarf of 1
solar mass. The goal is to get it to go nova, so I set an accretion rate of
5 x 10^-9 (units are solar masses per year). However, the default behavior
for accretion is to use the same composition for the accreted matter as
there is on the surface. Since adding C and O to the surface wouldn't yield
the nova I was looking for, I set the following in the controls namelist:

mass_change = 5d-9
accrete_same_as_surface = .false.
accretion_h1 = 0.75
accretion_h2 = 0.
accretion_he3 = 0.
accretion_he4 = 0.25

However, when I try to run with these settings on, the run cites
"adjust_mass_failed", and crashes after hitting the default max number of
backups (15). I tried the same settings on a different case and got the same
error. If anyone has experience with changing the accretion composition, I
would appreciate it if you could give some insight as to what I might be
doing wrong. Thanks.

Max Katz
Rensselaer Polytechnic Institute
Physics, Class of 2011

Re: mesa-users] Massive star runs end before planetary nebula stage

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

Hi Eric,

Here's some more information about the convergence problems for large stars at the tip of the AGB.

It appears that there is a very narrow zone at the base of the envelope where Pgas/Ptotal gets very small (6% or so).
The model is on the brink of physical instability there, and the code is having a very hard time coping.
I checked, and the convergence issues are arising in exactly the area where Pgas/Ptotal gets small.
In order to deal with the situation, the code needs to keep the timesteps small, hence the extremely slow progress.

Here are some plots from the 4 Msun run I'm using to study this porblem.   Note the huge jump in opacity at the trouble spot.

Re: mesa-users] Massive star runs end before planetary nebula stage

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

One more thing --- the particular failure mode for the run you sent is related to the convergence problem.
During an attempt to find a solution, the newton iteration has gotten horribly confused and has created a
cell with logT = 3.0 and logRho = 228.3 -- that's a rather large density!   The eos not unreasonably gave 
back junk leading to a NaN.  Rather than doing a stop (which is what happened), the code was supposed
to reject the candidate solution and try again.   This is fixed in the newest version (2483).  But as I said
in the previous email, that's just a symptom of a deeper problem that remains unsolved.

-B








On Jul 1, 2010, at 10:20 AM, Eric Blais wrote:

> Hi,
> 
> I'm having trouble figuring out why the more high mass stars (5 solar masses and up) end their lives in the thermally-pulsing AGB.  From the logs, I don't see why the run ends at this point, and toying with some parameters has not solved this problem.  Perhaps someone could help me?
> 
> I've attached the inlist file.  There's nothing special there, except that I changed the net to agb.net once the star went up the AGB, but the run with the basic net ended in the same way.
> 
> I've included a saved model also.  The error happens 194 steps later and the terminal output for the last few steps is in log5M.dat.  I don't know where these variables can be found in the code, which is why I'm having trouble interpreting this error.
> 
> On the computer I use, the star is halfway up the asymptotic giant branch in 15 minutes, reaches the point of maximum luminosity on this graph in about 2 hours and then spends many hours on that last, downward curve you can see on the HR diagram.
> 
> It would be great if I could get these stars to go just a little bit further in their evolution (say, once the envelope has been reduced to a tenth of a solar mass).
> 
> Cheers,
> Eric Blais
> <log5M.dat><inlist_test><tpagb5Msun.mod><HR_5MsunNoOversh.JPG>------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

Re: mesa-users] Massive star runs end before planetary nebula stage

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

Hi Eric,

You've hit on a major open issue.  When your email arrived, I was staring at the same problem in the context of a 4 Msun case.  There seem to be some convergence problems, but I've haven't yet been able to figure out where they are coming from -- the implicit solver makes this sort of debugging very difficult since everything gets coupled to everything else.

If you are interested in the evolution at the tip of the AGB, I'm afraid I don't yet know a solution.

If you are willing to do "stellar engineering" to get at the proto-WD core under the envelope, then you can try the recipe I've included in the release -- see data/star_data/white_dwarf_models/make_a_wd.notes.

Let us all know if you figure out a way to solve the agb tip problem!  (btw: the lower masses manage to leave the tip of the agb okay -- e.g., the 1 Msun has no problem.  so there is something about the more massive envelope that is causing the trouble.)

-Bill






On Jul 1, 2010, at 10:20 AM, Eric Blais wrote:

> Hi,
> 
> I'm having trouble figuring out why the more high mass stars (5 solar masses and up) end their lives in the thermally-pulsing AGB.  From the logs, I don't see why the run ends at this point, and toying with some parameters has not solved this problem.  Perhaps someone could help me?
> 
> I've attached the inlist file.  There's nothing special there, except that I changed the net to agb.net once the star went up the AGB, but the run with the basic net ended in the same way.
> 
> I've included a saved model also.  The error happens 194 steps later and the terminal output for the last few steps is in log5M.dat.  I don't know where these variables can be found in the code, which is why I'm having trouble interpreting this error.
> 
> On the computer I use, the star is halfway up the asymptotic giant branch in 15 minutes, reaches the point of maximum luminosity on this graph in about 2 hours and then spends many hours on that last, downward curve you can see on the HR diagram.
> 
> It would be great if I could get these stars to go just a little bit further in their evolution (say, once the envelope has been reduced to a tenth of a solar mass).
> 
> Cheers,
> Eric Blais
> <log5M.dat><inlist_test><tpagb5Msun.mod><HR_5MsunNoOversh.JPG>------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

Re: mesa-users] multi-mass

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

Hi,

Forget multi-mass for now. You need to do a bunch of cases one-at-a-time to get a good feeling for how things go.

I suggest you run some of the test_suite cases -- solar, he_core_flash, pre_zahb, hb_2M, and agb would all be good.
Make plots as the runs progress.  Use pgplot to watch as the star evolves.

Then move to a complete run by doing 1M_pre_ms_to_wd  -- it will take several hours to finish.
Again, you need to make lots of plots as the run progresses.  Don't just let it run without checking plots regularly!
Compare what you see on your screen to the movies on the website (http://mesa.sourceforge.net/).
Once you can duplicate those results, try increasing the initial mass: 1st to 2, then 3, then 4 ....


-Bill

mesa-users] cannot terminate

[jingluan <jin...@ca...>]

Hi :-)

Question 1: I run a muli-mass case, but the log info is not shown in the 
terminal as it does for a sing-mass case, what's wrong? Here is what 
comes out:


                         done read_masses           2    
2.0000000000000000E-02

                                     mass           1    
1.0000000000000000E+00
                                     mass           2    
2.0000000000000000E+00


                           isochrone mass           1    
1.0000000000000000E+00
             star_log_name: i001_star.log
profiles_index_name: i001_profiles.index
                log_data_prefix: i001_log

           create pre main sequence model
  done build_pre_ms_model
__________________________________________________________________________________________________________________________________________________

        step    lg_Tcntr    Teff       lg_LH     lg_Lnuc     Mass       
H_rich     H_cntr     N_cntr     Y_surf     X_avg     eta_cntr   pts  retry
    lg_dt_yr    lg_Dcntr    lg_Rsurf   lg_L3a    lg_Lneu     lg_Mdot    
H_poor     He_cntr    O_cntr     Z_surf     Y_avg     gam_cntr  jacs  bckup
      age_yr    lg_Pcntr    lg_L       lg_LZ     lg_Psurf    lg_Dsurf   
He_poor    C_cntr     Ne_cntr    Z_cntr     Z_avg     v_div_cs     dt_limit
__________________________________________________________________________________________________________________________________________________

save photos/x020
save photos/x040
save photos/x060
save photos/x080
save photos/x100
save photos/x120
save photos/x140
save photos/x160
save photos/x180

Question 2: I add a condition to stop the run at run_star_extras.f 
(attached ), see the part:

   if (s% model_number==1) then
               extras_finish_step=terminate
           end if

but it does not terminate when s% model_number==1

Thank you very much :-)

-- 
Sincerely
Jing

Ph.D candidate at physics.caltech
email: jin...@ca...
address: MC350-17,Caltech,1200E.California Blvd,
          Pasadena, CA 91125

Re: mesa-users] multi-mass

[jingluan <jin...@ca...>]

On 06/30/2010 08:19 PM, Bill Paxton wrote:
> Hi Jing,
>
> Here's the 1st line of your file multi_mass_inlist.txt
>
> &  isochrone_job
>
>
> Please try it without a space after the&   and let us know how that works.
>
> -B
>
>
>    
Dear Bill,

1, Works now :-) But the 5Msun solar model seems to converge slowly , 
there comes out the following info:

  retry
  retry
  first model is slow to converge: num_jacobians          70         250
  first model is slow to converge: num_jacobians          80         250
  first model is slow to converge: num_jacobians          90         250
  first model is slow to converge: num_jacobians         100         250
  first model is slow to converge: num_jacobians         110         250
  first model is slow to converge: num_jacobians         120         250
  first model is slow to converge: num_jacobians         130         250
  first model is slow to converge: num_jacobians         140         250
save photos/x020
save photos/x040
save photos/x060

What is the problem? Shall I use another one like work_massive_star? but 
5 Msun is not very large..

Thank you very much :-)


-- 
Sincerely
Jing

Ph.D candidate at physics.caltech
email: jin...@ca...
address: MC350-17,Caltech,1200E.California Blvd,
          Pasadena, CA 91125

Re: mesa-users] multi-mass

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

On Jun 30, 2010, at 7:09 PM, jingluan wrote:

> I have another question as mentioned before the one about initial_mass. That is how to run different masses one by one in one run..

Take a look at the inlists in test_suite/isochrone

In the file inlist_isochrone, you'll find this:

&isochrone_job

   masses_filename = 'iso_low_mass.list'
   initial_Z = 0.02
   isochrone_age = 10d9 ! years


In the file iso_low_mass.list, you'll find

   masses(
      0.09, 0.07, 0.05, 0.03
   )

those will be the initial masses for the different cases.

sorry for the poor state of the documentation.   Keep asking and eventually we'll get there!  ; - )

-Bill

Re: mesa-users] multi-mass

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

Hi,

On Jun 30, 2010, at 3:13 PM, jingluan wrote:

> Hello,
> 
> I was trying to run mass=5,6 by an single run. I attached inlist_project, isochrone.f, inlist_masses, mass.list below.
> 
> There is the err info:
> 
> Failed while trying to read control namelist file inlist_masses
> The following runtime error message might help you find the problem
> 
> At line 189 of file ../../../star/test/src/isochrone.f (unit = 9, file = 'inlist_masses')
> Fortran runtime error: End of file
> 
> I open star/test/src/isochrone.f, but there is no 'inlist_mass' in this file. So I have no idea what the problem is.
> 
> 
To get an idea of how to use the isochrone option, please take a look at the inlists in star/test_suite/isochrone.



> BTW, is the parameter s% initial_mass always 1? 

As you mention, the default is 1 -- the file star/public/star_defaults.dek has the defaults for all of the &controls section parameters,
star/public/pgstar_defaults.dek has the &pgstar defaults, and star/test/src/run_star_defaults.dek has the &run_star defaults.
The default is only used if you don't give a value for the parameter in your inlist.   The value of s% initial_mass is 1st set to the default,
then it can be changed if you have initial_mass in your inlist.


Hope that helps,
Bill

mesa-users] multi-mass

[jingluan <jin...@ca...>]

Hello,

I was trying to run mass=5,6 by an single run. I attached 
inlist_project, isochrone.f, inlist_masses, mass.list below.

There is the err info:

Failed while trying to read control namelist file inlist_masses
The following runtime error message might help you find the problem

At line 189 of file ../../../star/test/src/isochrone.f (unit = 9, file = 
'inlist_masses')
Fortran runtime error: End of file

I open star/test/src/isochrone.f, but there is no 'inlist_mass' in this 
file. So I have no idea what the problem is.

BTW, is the parameter s% initial_mass always 1? It is set to be one in 
star_defaults.dek. But I want it to be the initial mass set in 
inlist_project.

Thank you very much :-)

-- 
Sincerely
Jing

Ph.D candidate at physics.caltech
email: jin...@ca...
address: MC350-17,Caltech,1200E.California Blvd,
          Pasadena, CA 91125

Re: mesa-users] Is s% eps_h_max_m in unit of gram

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

Hi Jing,

On Jun 30, 2010, at 12:15 PM, jingluan wrote:

> Is s% eps_h_max_m in unit of gram please?

Let's assume the comment in star_data.dek is correct until we see evidence to the contrary.   ; - )

      double precision :: eps_h_max_m ! mass coordinate at location of max burn (Msun units)


-Bill

mesa-users] save files into another directory

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

On Jun 30, 2010, at 12:14 PM, jingluan wrote:

> Dear Bill
> 
> I asked about how to write data into a file, and this file is automatically created and saved under the current directory.

> 
> Then how to create and save a file with data in another directory (e.g. a sub directory of the current one)?
> 

here are the relevant controls from star_defaults.dek

      ! output of photos, logs, and profiles

         photo_directory = 'photos'
      
         do_log_files = .true. ! log files are created only if this is true
      
         do_profiles = .true. ! profiles are written only if this is true

         log_directory = 'LOGS'
         star_log_name = 'star.log'
         star_log_header_name = '' 
            ! if not empty, then put star log header info in this file
            ! in this case the star log has only data -- making it easier
            ! to use with some plotting packages.
         star_log_dbl_format = '(1pes27.16e3, 1x)'
         star_log_int_format = '(i27, 1x)'
         star_log_txt_format = '(a27, 1x)'
         
         profiles_index_name = 'profiles.index'
         log_data_prefix = 'log'
         log_data_suffix = '.data'
         log_data_header_suffix = ''
            ! if not empty, then put log data header info here
            ! in this case the log data file has only data -- making it easier
            ! to use with some plotting packages.
         profile_dbl_format = '(1pes27.16e3, 1x)'
         profile_int_format = '(i27, 1x)'
         profile_txt_format = '(a27, 1x)'

> 

I hope that helps.

-B

mesa-users] H burning shell

[jingluan <jin...@ca...>]

Hello,

Below the shell indexed by s% h_shell_k4, there is almost no H burning. 
Is that right?

Is this parameter calculated by mesa from the beginning of a run?

Thank you very much :-)

-- 
Sincerely
Jing

Ph.D candidate at physics.caltech
email: jin...@ca...
address: MC350-17,Caltech,1200E.California Blvd,
          Pasadena, CA 91125

mesa-users] mesa and late stages of evolution of giant stars

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

On Jun 30, 2010, at 8:24 AM, Michelle Dolan wrote:

> late stages of evolution of giant stars

Hi Shelley,

It takes a rather long time for mesa to evolve a massive star from pre-ms to onset of core collapse.
Perhaps it would be useful to have a model that was saved about 1000 steps or so before collapse.
You can play with that a bit to see how things go before you do the entire evolution yourself.

Here's a model that started at 20 Msun and has evolved for 42000 timesteps.   


You can use it as a starting model by editing your inlist_massive:

         load_saved_model = .true.
         !saved_model_name = '25m_z2m2_pre_ms.mod'
         saved_model_name = '20_z2m2_si_burn.mod'


then just do
	
	./rn

you should get a terminal line saying

	load saved model 20_z2m2_si_burn.mod


and then it will start with output something like the following:

 
       step    lg_Tcntr    Teff       lg_LH     lg_Lnuc     Mass       H_rich     H_cntr     N_cntr     Y_surf     X_avg     eta_cntr   pts  retry
   lg_dt_yr    lg_Dcntr    lg_Rsurf   lg_L3a    lg_Lneu     lg_Mdot    H_poor     He_cntr    O_cntr     Z_surf     Y_avg     gam_cntr  jacs  bckup
     age_yr    lg_Pcntr    lg_L       lg_LZ     lg_Psurf    lg_Dsurf   He_poor    C_cntr     Ne_cntr    Si_cntr    Z_avg     v_div_cs     dt_limit
__________________________________________________________________________________________________________________________________________________
 
      42023   9.817492   3178.888  18.726917  26.365246  15.499273   9.327864   0.000000   0.000000   0.386320   0.353310   5.811636   1426      0
  -7.851571   9.034721   3.098539  15.152327  13.568666 -99.000000   6.171409   0.000917   0.000003   0.019955   0.383153   5.146621     10      0
 8.9557E+06  26.713394   5.159661  26.365246   2.503420  -8.754533   0.000000   0.000000   0.000000   0.000001  2.635E-01  0.189E+02    varcontrol



This plot shows the abundances



and this one shows that the infall velocity is about 1 km/sec -- the run will automatically stop when that reaches 1000 km/sec.


I hope that will be useful!

Cheers,
Bill

mesa-users] strange radius

[jingluan <jin...@ca...>]

Hello :-)

I run a one-solar-mass star and print the s% R(k)/(7*10**10), (s% 
mlt_mixing_length(k))/(7*10**10), (s% mlt_mixing_length(k))/(s% 
scale_height(k)), here is a sample of the output at the beginning of the run

      8.0738873839706695       0.44332401385765779        
138958140368.74124
      8.0718427816721459       0.44463429001342880        
138957723368.84402
      8.0697921319668957       0.44594916505956783        
138957729700.33823
      8.0677354208661853       0.44726719350617850        
138957765906.98047
      8.0656726249463055       0.44858946730054233        
138957436889.61722

7*10**10 cm is the solar radius.

1, Why could R(k) be larger than Rsun please?
2, Why the mixing_length_alpha so large, it should be order of unity. I 
checked star_defaults.dek, mixing_length_alpha is set to be 2.

Thank you very much :-)

-- 
Sincerely
Jing

Ph.D candidate at physics.caltech
email: jin...@ca...
address: MC350-17,Caltech,1200E.California Blvd,
          Pasadena, CA 91125

mesa-users] save to a file

[jingluan <jin...@ca...>]

Hello :-)

Here is something with writing data into a txt file by fortran. I use

  open(unit=6, file='ce2', action='write', position='append')
                write (*,*) alphabar, (s% conv_vel(k))/vorb, (s% 
rho(k))!, (s% conv_vel(k)), (s% R(k)), (s% mlt_mixing_length(k))
                close(unit=6)

in the subroutine extras_finish_step in run_star_extras (see the 
attachment), but the screen does not show those data like: step    
lg_Tcntr    Teff       lg_LH  .... any more. Am I doing anything wrong?

Thank you very much :-)

-- 
Sincerely
Jing

Ph.D candidate at physics.caltech
email: jin...@ca...
address: MC350-17,Caltech,1200E.California Blvd,
          Pasadena, CA 91125

Re: mesa-users] Missing a tmp.txt file in the kap module?

[Eric B. <er....@gm...>]

On Fri, Jun 25, 2010 at 5:47 PM, Bill Paxton <pa...@ki...> wrote:

>
> On Jun 25, 2010, at 2:33 PM, Eric Blais wrote:
>
> > I got totally different results after switching to this version.  rn no
> longer returns an error message, but install still fails.
>
> try turning off the debugging output and trying it again.
>
> set the flag false in load_co_kap.f
>
>      logical, parameter :: CO_dbg = .false.
>
>
> -Bill
>
>
>
Hi,

That did the trick, and allowed me to install mesa successfully.  However,
trying to run any of the provided sample star resulted in failure because
there was a problem with the use_fxt_rates control parameter (while reading
its value from inlist, the compiler claimed this was an invalid reference to
the variable...)  But upgrading to 2479 fixed that.  I've installed mesa and
ran my first star, so all is well.

Thanks for your help.
Eric Blais

Re: mesa-users] Missing a tmp.txt file in the kap module?

[Eric B. <er....@gm...>]

ifort  -vec-report0 -traceback -error-limit 6 -openmp -threads  -I../public -I../private -I../../include -warn all -warn nounused -implicitnone  -check uninit -check pointers -check bounds -check all -O2 -g -c -free ../public/kap_def.f
ifort  -vec-report0 -traceback -error-limit 6 -openmp -threads  -I../public -I../private -I../../include -warn all -warn nounused -implicitnone  -check uninit -check pointers -check bounds -check all -O2 -g -c -free ../private/load_co_kap.f
ifort  -vec-report0 -traceback -error-limit 6 -openmp -threads  -I../public -I../private -I../../include -warn all -warn nounused -implicitnone  -check uninit -check pointers -check bounds -check all -O2 -g -c -free ../private/load_kap.f
ifort  -vec-report0 -traceback -error-limit 6 -openmp -threads  -I../public -I../private -I../../include -warn all -warn nounused -implicitnone  -check uninit -check pointers -check bounds -check all -O2 -g -c -free ../private/kap_eval_support.f
ifort  -vec-report0 -traceback -error-limit 6 -openmp -threads  -I../public -I../private -I../../include -warn all -warn nounused -implicitnone  -check uninit -check pointers -check bounds -check all -O2 -g -c -free ../private/kap_eval_fixed.f
ifort  -vec-report0 -traceback -error-limit 6 -openmp -threads  -I../public -I../private -I../../include -warn all -warn nounused -implicitnone  -check uninit -check pointers -check bounds -check all -O2 -g -c -free ../private/kap_eval_co.f
ifort  -vec-report0 -traceback -error-limit 6 -openmp -threads  -I../public -I../private -I../../include -warn all -warn nounused -implicitnone  -check uninit -check pointers -check bounds -check all -O2 -g -c -free ../private/kap_eval.f
ifort  -vec-report0 -traceback -error-limit 6 -openmp -threads  -I../public -I../private -I../../include -warn all -warn nounused -implicitnone  -check uninit -check pointers -check bounds -check all -O2 -g -c -free ../public/kap_lib.f
ar crs libkap.a kap_def.o load_co_kap.o load_kap.o kap_eval_support.o kap_eval_fixed.o kap_eval_co.o kap_eval.o kap_lib.o
ifort  -vec-report0 -traceback -error-limit 6 -openmp -threads -I../../make -I../../public -I../../../include  -check uninit -check pointers -check bounds -check all -g -c -free ../src/test_kap_support.f
ifort  -vec-report0 -traceback -error-limit 6 -openmp -threads -I../../make -I../../public -I../../../include  -check uninit -check pointers -check bounds -check all -g -c -free ../src/test_kap.f
ifort -openmp -threads -o ../tester test_kap_support.o test_kap.o -L../../make -lkap -L../../../lib -linterp_2d -linterp_1d -lnum -lutils -lalert -lconst -lmtx -lmesalapack -lmesablas -leos -lchem 
ifort  -vec-report0 -traceback -error-limit 6 -openmp -threads -I../../make -I../../public -I../../../include  -check uninit -check pointers -check bounds -check all -g -c -free ../src/test_kap_quietly.f
ifort -openmp -threads -o ../test_quietly test_kap_support.o test_kap_quietly.o -L../../make -lkap -L../../../lib -linterp_2d -linterp_1d -lnum -lutils -lalert -lconst -lmtx -lmesalapack -lmesablas -leos -lchem 
ifort  -vec-report0 -traceback -error-limit 6 -openmp -threads -I../../make -I../../public -I../../../include  -check uninit -check pointers -check bounds -check all -g -c -free ../src/plot_kap.f
ifort -openmp -threads -o ../plotter test_kap_support.o plot_kap.o -L../../make -lkap -L../../../lib -linterp_2d -linterp_1d -lnum -lutils -lalert -lconst -lmtx -lmesalapack -lmesablas -leos -lchem 
 load_one_CO gn93_co_z0m0_x00.data           1           1 T
 Setup_Kap_CO_X_Table: allocate co_tables           1           1          58
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           1
 after Setup_Kap_CO_X_Table: associated co_tables T           1
 load_one_CO gn93_co_z0m0_x10.data           1           2 T
 Setup_Kap_CO_X_Table: allocate co_tables           1           2          58
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           2
 after Setup_Kap_CO_X_Table: associated co_tables T           2
 load_one_CO gn93_co_z0m0_x35.data           1           3 T
 Setup_Kap_CO_X_Table: allocate co_tables           1           3          51
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           3
 after Setup_Kap_CO_X_Table: associated co_tables T           3
 load_one_CO gn93_co_z0m0_x70.data           1           4 T
 Setup_Kap_CO_X_Table: allocate co_tables           1           4          32
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           4
 after Setup_Kap_CO_X_Table: associated co_tables T           4
 load_one_CO gn93_co_z1m3_x00.data           2           1 T
 Setup_Kap_CO_X_Table: allocate co_tables           2           1          58
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           1
 after Setup_Kap_CO_X_Table: associated co_tables T           1
 load_one_CO gn93_co_z1m3_x10.data           2           2 T
 Setup_Kap_CO_X_Table: allocate co_tables           2           2          58
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           2
 after Setup_Kap_CO_X_Table: associated co_tables T           2
 load_one_CO gn93_co_z1m3_x35.data           2           3 T
 Setup_Kap_CO_X_Table: allocate co_tables           2           3          51
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           3
 after Setup_Kap_CO_X_Table: associated co_tables T           3
 load_one_CO gn93_co_z1m3_x70.data           2           4 T
 Setup_Kap_CO_X_Table: allocate co_tables           2           4          30
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           4
 after Setup_Kap_CO_X_Table: associated co_tables T           4
 load_one_CO gn93_co_z4m3_x00.data           3           1 T
 Setup_Kap_CO_X_Table: allocate co_tables           3           1          58
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           1
 after Setup_Kap_CO_X_Table: associated co_tables T           1
 load_one_CO gn93_co_z4m3_x10.data           3           2 T
 Setup_Kap_CO_X_Table: allocate co_tables           3           2          58
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           2
 after Setup_Kap_CO_X_Table: associated co_tables T           2
 load_one_CO gn93_co_z4m3_x35.data           3           3 T
 Setup_Kap_CO_X_Table: allocate co_tables           3           3          51
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           3
 after Setup_Kap_CO_X_Table: associated co_tables T           3
 load_one_CO gn93_co_z4m3_x70.data           3           4 T
 Setup_Kap_CO_X_Table: allocate co_tables           3           4          30
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           4
 after Setup_Kap_CO_X_Table: associated co_tables T           4
 load_one_CO gn93_co_z1m2_x00.data           4           1 T
 Setup_Kap_CO_X_Table: allocate co_tables           4           1          58
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           1
 after Setup_Kap_CO_X_Table: associated co_tables T           1
 load_one_CO gn93_co_z1m2_x10.data           4           2 T
 Setup_Kap_CO_X_Table: allocate co_tables           4           2          58
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           2
 after Setup_Kap_CO_X_Table: associated co_tables T           2
 load_one_CO gn93_co_z1m2_x35.data           4           3 T
 Setup_Kap_CO_X_Table: allocate co_tables           4           3          51
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           3
 after Setup_Kap_CO_X_Table: associated co_tables T           3
 load_one_CO gn93_co_z1m2_x70.data           4           4 T
 Setup_Kap_CO_X_Table: allocate co_tables           4           4          30
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           4
 after Setup_Kap_CO_X_Table: associated co_tables T           4
 load_one_CO gn93_co_z2m2_x00.data           5           1 T
 Setup_Kap_CO_X_Table: allocate co_tables           5           1          58
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           1
 after Setup_Kap_CO_X_Table: associated co_tables T           1
 load_one_CO gn93_co_z2m2_x10.data           5           2 T
 Setup_Kap_CO_X_Table: allocate co_tables           5           2          58
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           2
 after Setup_Kap_CO_X_Table: associated co_tables T           2
 load_one_CO gn93_co_z2m2_x35.data           5           3 T
 Setup_Kap_CO_X_Table: allocate co_tables           5           3          51
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           3
 after Setup_Kap_CO_X_Table: associated co_tables T           3
 load_one_CO gn93_co_z2m2_x70.data           5           4 T
 Setup_Kap_CO_X_Table: allocate co_tables           5           4          30
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           4
 after Setup_Kap_CO_X_Table: associated co_tables T           4
 load_one_CO gn93_co_z3m2_x00.data           6           1 T
 Setup_Kap_CO_X_Table: allocate co_tables           6           1          58
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           1
 after Setup_Kap_CO_X_Table: associated co_tables T           1
 load_one_CO gn93_co_z3m2_x10.data           6           2 T
 Setup_Kap_CO_X_Table: allocate co_tables           6           2          58
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           2
 after Setup_Kap_CO_X_Table: associated co_tables T           2
 load_one_CO gn93_co_z3m2_x35.data           6           3 T
 Setup_Kap_CO_X_Table: allocate co_tables           6           3          49
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           3
 after Setup_Kap_CO_X_Table: associated co_tables T           3
 load_one_CO gn93_co_z3m2_x70.data           6           4 T
 Setup_Kap_CO_X_Table: allocate co_tables           6           4          30
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           4
 after Setup_Kap_CO_X_Table: associated co_tables T           4
 load_one_CO gn93_co_z1m1_x00.data           7           1 T
 Setup_Kap_CO_X_Table: allocate co_tables           7           1          58
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           1
 after Setup_Kap_CO_X_Table: associated co_tables T           1
 load_one_CO gn93_co_z1m1_x10.data           7           2 T
 Setup_Kap_CO_X_Table: allocate co_tables           7           2          53
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           2
 after Setup_Kap_CO_X_Table: associated co_tables T           2
 load_one_CO gn93_co_z1m1_x35.data           7           3 T
 Setup_Kap_CO_X_Table: allocate co_tables           7           3          43
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           3
 after Setup_Kap_CO_X_Table: associated co_tables T           3
 load_one_CO gn93_co_z1m1_x70.data           7           4 T
 Setup_Kap_CO_X_Table: allocate co_tables           7           4          26
           0
 Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           4
 after Setup_Kap_CO_X_Table: associated co_tables T           4

1c1
<  load_one_CO gn93_co_z0m0_x00.data           1           1 T
--- field 5
>  test number           1
2c2
<  Setup_Kap_CO_X_Table: allocate co_tables           1           1          58
--- field 6
>  fixed metals
3c3
<            0
--- field 1
>  
4c4
<  Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           1
--- field 6
>                                     logT    6.0000000000000000E+00
5c5
<  after Setup_Kap_CO_X_Table: associated co_tables T           1
--- field 6
>                                   logRho   -6.0000000000000000E+00
6c6
<  load_one_CO gn93_co_z0m0_x10.data           1           2 T
--- field 5
>                                    zbase    1.0000000000000000E-02
7c7
<  Setup_Kap_CO_X_Table: allocate co_tables           1           2          58
--- field 6
>                                       xh    6.9999999999999996E-01
8c8
<            0
--- field 2
>                                      dxc    0.0000000000000000E+00
9c9
<  Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           2
--- field 6
>                                      dxo    0.0000000000000000E+00
10c10
<  after Setup_Kap_CO_X_Table: associated co_tables T           2
--- field 6
>  
11c11
<  load_one_CO gn93_co_z0m0_x35.data           1           3 T
--- field 5
>                                 log10kap   -4.4899999621474185E-01
12c12
<  Setup_Kap_CO_X_Table: allocate co_tables           1           3          51
--- field 6
>                            dlnkap_dlnRho    1.9495729357004166E-02
13c13
<            0
--- field 2
>                              dlnkap_dlnT    2.8335783630609512E-02
14c14
<  Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           3
--- field 6
>  
15c15
<  after Setup_Kap_CO_X_Table: associated co_tables T           3
--- field 6
>                                      kap    3.5563132166862488E-01
16c16
<  load_one_CO gn93_co_z0m0_x70.data           1           4 T
--- field 5
>                                dkap_dlnd    6.9332919981252017E-03
17c17
<  Setup_Kap_CO_X_Table: allocate co_tables           1           4          32
--- field 6
>                                dkap_dlnT    1.0077092183069847E-02
18c18
<            0
--- field 1
>  
19c19
<  Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           4
--- field 6
>  test number           2
20c20
<  after Setup_Kap_CO_X_Table: associated co_tables T           4
--- field 6
>  C/O enhanced
21c21
<  load_one_CO gn93_co_z1m3_x00.data           2           1 T
--- field 5
>  
22c22
<  Setup_Kap_CO_X_Table: allocate co_tables           2           1          58
--- field 6
>                                     logT    6.0000000000000000E+00
23c23
<            0
--- field 2
>                                   logRho   -6.0000000000000000E+00
24c24
<  Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           1
--- field 6
>                                    zbase    1.0000000000000000E-02
25c25
<  after Setup_Kap_CO_X_Table: associated co_tables T           1
--- field 6
>                                       xh    6.9999999999999996E-01
26c26
<  load_one_CO gn93_co_z1m3_x10.data           2           2 T
--- field 5
>                                      dxc    2.1000000000000001E-02
27c27
<  Setup_Kap_CO_X_Table: allocate co_tables           2           2          58
--- field 6
>                                      dxo    1.9000000000000000E-02
28c28
<            0
--- field 1
>  
29c29
<  Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           2
--- field 6
>                                 log10kap   -4.4458955792323568E-01
30c30
<  after Setup_Kap_CO_X_Table: associated co_tables T           2
--- field 6
>                            dlnkap_dlnRho    2.8060473501682281E-02
31c31
<  load_one_CO gn93_co_z1m3_x35.data           2           3 T
--- field 5
>                              dlnkap_dlnT   -1.1150315403938293E-03
32c32
<  Setup_Kap_CO_X_Table: allocate co_tables           2           3          51
--- field 6
>  
33c33
<            0
--- fsecond file is short
ield 2
>                                      kap    3.5926130414009094E-01
34c34
<  Setup_Kap_CO_X_Table: associated(x_tables(ix)% co_tables) T T           3
--- field 6
>                                dkap_dlnd    1.0081042305002841E-02
35c35
<  after Setup_Kap_CO_X_Table: associated co_tables T           3
--- field 6
>                                dkap_dlnT   -4.0058768535922162E-04
36c36
<  load_one_CO gn93_co_z1m3_x70.data           2           4 T
--- field 5
>  

/home/blaiseri/mesa/kap/test
TEST FAILED -- compare test_output to tmp.txt