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

[mesa-users] Fwd: Important Account Information - Reconfirm Mailing List Subscriptions

[Brian J. <bja...@bo...>]

Apologies for spamming the list, but is this an e-mail that everyone
got about the MESA users' list? I don't remember receiving such an
e-mail in the past.

Thanks,
Brian Jackson

---------- Forwarded message ----------
From: SourceForge.net <no...@sl...>
Date: Thu, Jun 8, 2017 at 11:03 PM
Subject: Important Account Information - Reconfirm Mailing List Subscriptions
To: dec...@gm...


Hi,

Thanks for being a SourceForge user. Our records indicate that you are
subscribed to the following project mailing list:

    mesa-users

We are contacting you to confirm you are still interested in receiving
emails from this SourceForge project list.  If you do not confirm your
subscription by June 29th, you will be unsubscribed from the above
mailing list.

Please click here to confirm your subscription:


Thanks,
The SourceForge Team
A Slashdot Media Company

[mesa-users] postdoc position

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

forwarding an advertisement for a postdoc position
where mesa expertise would be a useful skill set.

fxt

Re: [mesa-users] diffusion causing model to get stuck

[Jean M. <je...@nm...>]

Thanks for the tips!

Setting diffusion_min_dq_at_surface to a larger value seems to have fixed
the issue.

-Jean

2017-06-05 14:34 GMT-06:00 Evan Bauer <eb...@ph...>:

> Hi Jean,
>
> Another control you might find useful is
>
>          !### diffusion_v_max
>
>          ! Max velocity (cm/sec).
>          ! We can get extremely large velocities in the extreme outer
> envelope
>          ! that cause problems numerically without really effecting the
> results,
>          ! so we allow a max for the velocities that should help the
> numerics
>          ! without changing the results.
>          ! Note: change `diffusion_v_max` to at least 1d-2 when using
> radiative levitation.
>
>       diffusion_v_max = 1d-5
>
> Setting this to a smaller number can help models that are having trouble
> with fast moving material in the outer atmosphere. In your model, I suspect
> the stuff that’s causing problems at the surface will eventually sediment
> away from where it’s moving so fast, and there will be nothing left that
> requires enforcing an artificial velocity cap, so you shouldn’t hurt the
> overall physics of diffusion much.
>
> Another option is just to force the model to take smaller time steps for a
> while until things sediment away from the very surface layers. When all
> else fails, I find it is often useful to set max_years_for_timestep to
> something rather small to keep diffusion well behaved for a while. Then I
> turn that control off and restart after the fast sedimentation at the
> surface has taken place.
>
> Cheers,
> Evan
>
>
> On Jun 5, 2017, at 12:52 PM, Aaron Dotter <aar...@gm...> wrote:
>
> Hi Jean,
>
> I recommend trying the following control;
>
>          ! treat at least this much at surface as a single cell for
> purposes of
>
>       diffusion_min_dq_at_surface = 1d-9
>
> 1d-9 is the default value.  Try setting it to a larger number, say 10^-4
> or 10^-3.  This tells the diffusion module to use treat the outer fraction
> of the star by mass as one zone in the diffuison calculation.  That
> calculation can get messy near the stellar surface, especially in stars in
> around ~1.5 Msun (as yours is) because they have a very thin -- or no --
> surface convection.
>
> Good luck!
>
> Aaron
>
>
>
>
>
>
> On Mon, Jun 5, 2017 at 3:42 PM, Jean McKeever <je...@nm...> wrote:
>
>> Hello,
>>
>> I was trying to create a grid of models using the astero module and the
>> grid got stuck on a particular point. After some testing of turning things
>> on and off I have discovered that do_element_diffusion appears to be the
>> culprit. For a 1.4 solar mass star with a metallicity of -.4, the model
>> seems to get caught in a series of retries where dt keeps decreasing to be
>> prohibitively small. This happens very early on in the model. If I turn off
>> diffusion, the model proceeds normally.
>>
>> Can anyone provide insight as to why diffusion is causing the model to
>> get stuck? I have attached some modified inlists and starting model to help
>> reproduce this. I checked the newest version of mesa and it is still a
>> problem in 9793.
>>
>> Thank you,
>> Jean
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> mesa-users mailing list
>> mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>
>>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
> _________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>
>

Re: [mesa-users] save model for gyre

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

Hi Rich,

I guess I need to include some .mod in the beginning of run_star_extras.f
like this one: use star_lib

Which mod file shall I claim please? Thank you very much.

Sincerely,
Jing

On Mon, Jun 5, 2017 at 12:43 PM, Jing Luan <jin...@gm...> wrote:

> Dear Frank, Jim and Rich
>
> Thank you all very much. They are very helpful!
>
> Sincerely,
> Jing
>
> On Mon, Jun 5, 2017 at 10:06 AM, RICHARD H D TOWNSEND <
> tow...@as...> wrote:
>
>> If you want more flexibility, you can add explicit calls to
>> star_export_pulse_data within your run_star_extras.f file. For instance:
>>
>> call star_export_pulse_data(id, ‘GYRE’, ‘model.GYRE’, &
>>   add_center_point = .TRUE., &
>>   keep_surface_point = .FALSE., &
>>   add_atmosphere = .TRUE., ierr)
>>
>> cheers,
>>
>> Rich
>>
>> > On Jun 4, 2017, at 2:17 PM, Jim Fuller <jf...@ca...> wrote:
>> >
>> > Hi Jing,
>> >
>> > I think you need to add these lines to your control inlist:
>> >
>> >       write_pulse_data_with_profile = .true.
>> >       pulse_data_format = 'GYRE'
>> >
>> > Hopefully that is all you need.
>> >
>> > -Jim
>> >
>> >
>> >
>> > On Sun, Jun 4, 2017 at 11:49 AM, Frank Timmes <fx...@ma...> wrote:
>> > from mesastar.org/astero_module.html
>> > and star/astero/defaults/astero_search.defaults
>> >
>> > it appears the controls
>> >
>> > write_gyre_for_each_model = .false.
>> > gyre_prefix = 'gyre_'
>> >    ! note that you can include a directory in the prefix if desired
>> > gyre_postfix = '.data’
>> >
>> > might achieve the desired goal.
>> >
>> > fxt
>> >
>> >
>> >
>> >
>> >
>> > > On Jun 4, 2017, at 8:53 AM, Jing Luan <jin...@gm...> wrote:
>> > >
>> > > Dear mesa users,
>> > >
>> > > Is there a subroutine that I could call in run_star_extras.f to save
>> a model file in the format that gyre could read in, i.e. 'model.mesa'
>> format. Currently, I use the following in inlist
>> > >
>> > >       save_pulsation_info_when_terminate = .true.
>> > >       save_pulsation_info_filename = 'model.mesa'
>> > >
>> > > which only saves the model at termination. But I like to save a
>> series of models for gyre at different evolutionary ages for one star.
>> > >
>> > > Many thanks!
>> > >
>> > > Sincerely,
>> > > Jing
>> > > ------------------------------------------------------------
>> ------------------
>> > > 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
>> >
>> > ------------------------------------------------------------
>> ------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
>> _________________________________________
>> > mesa-users mailing list
>> > mes...@li...
>> > https://lists.sourceforge.net/lists/listinfo/mesa-users
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> mesa-users mailing list
>> mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>
>
>

Re: [mesa-users] diffusion causing model to get stuck

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

Hi Jean,

Another control you might find useful is

         !### diffusion_v_max

         ! Max velocity (cm/sec).
         ! We can get extremely large velocities in the extreme outer envelope
         ! that cause problems numerically without really effecting the results,
         ! so we allow a max for the velocities that should help the numerics
         ! without changing the results.
         ! Note: change `diffusion_v_max` to at least 1d-2 when using radiative levitation.

      diffusion_v_max = 1d-5

Setting this to a smaller number can help models that are having trouble with fast moving material in the outer atmosphere. In your model, I suspect the stuff that’s causing problems at the surface will eventually sediment away from where it’s moving so fast, and there will be nothing left that requires enforcing an artificial velocity cap, so you shouldn’t hurt the overall physics of diffusion much.

Another option is just to force the model to take smaller time steps for a while until things sediment away from the very surface layers. When all else fails, I find it is often useful to set max_years_for_timestep to something rather small to keep diffusion well behaved for a while. Then I turn that control off and restart after the fast sedimentation at the surface has taken place.

Cheers,
Evan


> On Jun 5, 2017, at 12:52 PM, Aaron Dotter <aar...@gm...> wrote:
> 
> Hi Jean,
> 
> I recommend trying the following control;
> 
>          ! treat at least this much at surface as a single cell for purposes of 
> 
>       diffusion_min_dq_at_surface = 1d-9
> 
> 1d-9 is the default value.  Try setting it to a larger number, say 10^-4 or 10^-3.  This tells the diffusion module to use treat the outer fraction of the star by mass as one zone in the diffuison calculation.  That calculation can get messy near the stellar surface, especially in stars in around ~1.5 Msun (as yours is) because they have a very thin -- or no -- surface convection.
> 
> Good luck!
> 
> Aaron
> 
> 
> 
> 
> 
> 
> On Mon, Jun 5, 2017 at 3:42 PM, Jean McKeever <je...@nm... <mailto:je...@nm...>> wrote:
> Hello,
> 
> I was trying to create a grid of models using the astero module and the grid got stuck on a particular point. After some testing of turning things on and off I have discovered that do_element_diffusion appears to be the culprit. For a 1.4 solar mass star with a metallicity of -.4, the model seems to get caught in a series of retries where dt keeps decreasing to be prohibitively small. This happens very early on in the model. If I turn off diffusion, the model proceeds normally. 
> 
> Can anyone provide insight as to why diffusion is causing the model to get stuck? I have attached some modified inlists and starting model to help reproduce this. I checked the newest version of mesa and it is still a problem in 9793.
> 
> Thank you,
> Jean
> 
> ------------------------------------------------------------------------------
> 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] diffusion causing model to get stuck

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

Hi Jean,

I recommend trying the following control;

         ! treat at least this much at surface as a single cell for
purposes of

      diffusion_min_dq_at_surface = 1d-9

1d-9 is the default value.  Try setting it to a larger number, say 10^-4 or
10^-3.  This tells the diffusion module to use treat the outer fraction of
the star by mass as one zone in the diffuison calculation.  That
calculation can get messy near the stellar surface, especially in stars in
around ~1.5 Msun (as yours is) because they have a very thin -- or no --
surface convection.

Good luck!

Aaron






On Mon, Jun 5, 2017 at 3:42 PM, Jean McKeever <je...@nm...> wrote:

> Hello,
>
> I was trying to create a grid of models using the astero module and the
> grid got stuck on a particular point. After some testing of turning things
> on and off I have discovered that do_element_diffusion appears to be the
> culprit. For a 1.4 solar mass star with a metallicity of -.4, the model
> seems to get caught in a series of retries where dt keeps decreasing to be
> prohibitively small. This happens very early on in the model. If I turn off
> diffusion, the model proceeds normally.
>
> Can anyone provide insight as to why diffusion is causing the model to get
> stuck? I have attached some modified inlists and starting model to help
> reproduce this. I checked the newest version of mesa and it is still a
> problem in 9793.
>
> Thank you,
> Jean
>
> ------------------------------------------------------------
> ------------------
> 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] save model for gyre

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

Dear Frank, Jim and Rich

Thank you all very much. They are very helpful!

Sincerely,
Jing

On Mon, Jun 5, 2017 at 10:06 AM, RICHARD H D TOWNSEND <
tow...@as...> wrote:

> If you want more flexibility, you can add explicit calls to
> star_export_pulse_data within your run_star_extras.f file. For instance:
>
> call star_export_pulse_data(id, ‘GYRE’, ‘model.GYRE’, &
>   add_center_point = .TRUE., &
>   keep_surface_point = .FALSE., &
>   add_atmosphere = .TRUE., ierr)
>
> cheers,
>
> Rich
>
> > On Jun 4, 2017, at 2:17 PM, Jim Fuller <jf...@ca...> wrote:
> >
> > Hi Jing,
> >
> > I think you need to add these lines to your control inlist:
> >
> >       write_pulse_data_with_profile = .true.
> >       pulse_data_format = 'GYRE'
> >
> > Hopefully that is all you need.
> >
> > -Jim
> >
> >
> >
> > On Sun, Jun 4, 2017 at 11:49 AM, Frank Timmes <fx...@ma...> wrote:
> > from mesastar.org/astero_module.html
> > and star/astero/defaults/astero_search.defaults
> >
> > it appears the controls
> >
> > write_gyre_for_each_model = .false.
> > gyre_prefix = 'gyre_'
> >    ! note that you can include a directory in the prefix if desired
> > gyre_postfix = '.data’
> >
> > might achieve the desired goal.
> >
> > fxt
> >
> >
> >
> >
> >
> > > On Jun 4, 2017, at 8:53 AM, Jing Luan <jin...@gm...> wrote:
> > >
> > > Dear mesa users,
> > >
> > > Is there a subroutine that I could call in run_star_extras.f to save a
> model file in the format that gyre could read in, i.e. 'model.mesa' format.
> Currently, I use the following in inlist
> > >
> > >       save_pulsation_info_when_terminate = .true.
> > >       save_pulsation_info_filename = 'model.mesa'
> > >
> > > which only saves the model at termination. But I like to save a series
> of models for gyre at different evolutionary ages for one star.
> > >
> > > Many thanks!
> > >
> > > Sincerely,
> > > Jing
> > > ------------------------------------------------------------
> ------------------
> > > 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
> >
> > ------------------------------------------------------------
> ------------------
> > 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
>

[mesa-users] diffusion causing model to get stuck

[Jean M. <je...@nm...>]

Hello,

I was trying to create a grid of models using the astero module and the
grid got stuck on a particular point. After some testing of turning things
on and off I have discovered that do_element_diffusion appears to be the
culprit. For a 1.4 solar mass star with a metallicity of -.4, the model
seems to get caught in a series of retries where dt keeps decreasing to be
prohibitively small. This happens very early on in the model. If I turn off
diffusion, the model proceeds normally.

Can anyone provide insight as to why diffusion is causing the model to get
stuck? I have attached some modified inlists and starting model to help
reproduce this. I checked the newest version of mesa and it is still a
problem in 9793.

Thank you,
Jean

Re: [mesa-users] Z=0.04 and MESA r9793

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

> On Jun 2, 2017, at 10:03 AM, Josiah Schwab <jws...@uc...> wrote:
>
> Hi Philip,
>
>> I want to use MESA r9793 to evolve a 1.3Msol, Y=0.32, Z=0.04 star from the
>> zero age main sequence. I find strange behaviour near the base of the giant
>> branch for this high metallicity star: a jump in L and Teff, as shown in
>> the attached HR diagram (z0.04...pdf, red track, jump between the crosses).
>> The same model evolved with r8845 (black track) does not show this jump.
>>
>> I assume this is related to changes to the opacity and/or equation of
>> state, but I haven't been able to solve it. Do you have any ideas?
>
> As you suspected, this an EOS issue.  There are OPAL tables for Z = 0,
> 0.02, and 0.04.  For higher Z, we switch to HELM.
>
> The new release has controls that expose some of the blending options to
> the user (as opposed to hardcoding them).
>
> Try running with the options in star_job
>
>    set_HELM_OPAL_Zs = .true.
>    Z_all_OPAL = 1.0
>    Z_all_HELM = 1.0
>
> that should keep you on the OPAL tables (i.e. you'll never blend into
> HELM).
>
> What I don't understand (and will have to investigate) is why this
> particular case behaves so badly.  There was not supposed to have been a
> significant change in the default behavior.
>

As an addendum to this: I can’t get a metal rich, ~ 1Msun pre-main sequence model to converge unless I add the stuff above to stay on the OPAL tables. Example inlist attached.

So, it looks like there are some not-insigificant breakages from the higher-Z switch.

cheers,

Rich

Re: [mesa-users] save model for gyre

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

If you want more flexibility, you can add explicit calls to star_export_pulse_data within your run_star_extras.f file. For instance:

call star_export_pulse_data(id, ‘GYRE’, ‘model.GYRE’, &
  add_center_point = .TRUE., &
  keep_surface_point = .FALSE., &
  add_atmosphere = .TRUE., ierr)

cheers,

Rich

> On Jun 4, 2017, at 2:17 PM, Jim Fuller <jf...@ca...> wrote:
> 
> Hi Jing,
> 
> I think you need to add these lines to your control inlist:
> 
>       write_pulse_data_with_profile = .true.
>       pulse_data_format = 'GYRE'
> 
> Hopefully that is all you need.
> 
> -Jim
> 
> 
> 
> On Sun, Jun 4, 2017 at 11:49 AM, Frank Timmes <fx...@ma...> wrote:
> from mesastar.org/astero_module.html
> and star/astero/defaults/astero_search.defaults
> 
> it appears the controls
> 
> write_gyre_for_each_model = .false.
> gyre_prefix = 'gyre_'
>    ! note that you can include a directory in the prefix if desired
> gyre_postfix = '.data’
> 
> might achieve the desired goal.
> 
> fxt
> 
> 
> 
> 
> 
> > On Jun 4, 2017, at 8:53 AM, Jing Luan <jin...@gm...> wrote:
> >
> > Dear mesa users,
> >
> > Is there a subroutine that I could call in run_star_extras.f to save a model file in the format that gyre could read in, i.e. 'model.mesa' format. Currently, I use the following in inlist
> >
> >       save_pulsation_info_when_terminate = .true.
> >       save_pulsation_info_filename = 'model.mesa'
> >
> > which only saves the model at termination. But I like to save a series of models for gyre at different evolutionary ages for one star.
> >
> > Many thanks!
> >
> > Sincerely,
> > Jing
> > ------------------------------------------------------------------------------
> > 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
> 
> ------------------------------------------------------------------------------
> 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] Limiting the mass transfer

[Odette T. <ode...@gm...>]

Thank you very much.
I think it is worth it to point out a swap between
extras_binary_finish_step and extras_binary_check_model.

Cheers,
Odette.

2017-05-19 15:36 GMT+01:00 Pablo Marchant <pa...@gm...>:

> Hi Odette, this is straightforward.
>
> In you src/run_binary_extras you can use this
>
>        integer function extras_binary_check_model(binary_id)
>           type (binary_info), pointer :: b
>           integer, intent(in) :: binary_id
>           integer :: ierr
>           call binary_ptr(binary_id, b, ierr)
>           if (ierr /= 0) then ! failure in  binary_ptr
>              return
>           end if
>
>           !check if mass transfer rate reached maximun, assume merger if
> it happens
>           extras_binary_check_model = keep_going
>           if(abs(b% mtransfer_rate) >= b% max_implicit_abs_mdot*Msun/secyer)
> then
>              extras_binary_finish_step = terminate
>              write(*,*) "TERMINATING: Reached maximum mass transfer rate"
>           end if
>        end function extras_binary_check_model
>
> and in you inlist you choose the value of max_implicit_abs_mdot. I usually
> prefer doing it using max_implicit_abs_mdot instead of directly writing the
> limit, because at the onset of unstable MT the code might not be able to
> converge to a solution and get stuck.
>
> On Fri, May 19, 2017 at 4:48 AM, Odette Toloza <ode...@gm...>
> wrote:
>
>> Hi Mesa users,
>>
>> I was wondering if I can implement a limit to the mass  transfer as a
>> stopping condition, when I evolve a binary?
>>
>> Cheers,
>> Odette.
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> mesa-users mailing list
>> mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>
>>
>
>
> --
> Pablo Marchant Campos
> M.Sc on Astrophysics, Universidad Católica de Chile
> PhD student, Argelander-Institut für Astronomie
>

Re: [mesa-users] Generating version 9793

[Ian F. <ifo...@gm...>]

Hi Rob,

I'll give it a go

Thanks

Ian

On 5 June 2017 at 13:39, Robert Farmer <rjf...@as...> wrote:

> Hi
>
> Try just replacing ifort with gfortran in the commands.
>
> Rob
>
>
> On Jun 4, 2017 20:33, "Ian Foley" <ifo...@gm...> wrote:
>
> Hi,
>
> I am a user who is not using the mesasdk, so I use the
> makefile_header_non_mesasdk file to generate the star executable.
>
> A new addition with this version is the hdf5 library which I gather has
> something to do with processing weak rates. There is nothing in the release
> notes about it.
>
> However, the code in the header file shows how to generate the hdf5
> library with ifort, but not with gfortran. So before I delve deeper I'm
> wondering how I create this library and set it up with gfortran.
>
> Thanks
> Ian
>
> ------------------------------------------------------------
> ------------------
> 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] Generating version 9793

[Ian F. <ifo...@gm...>]

Hi Rich,

Thanks for the quick reply.

Re the SDK. My O/S is windows 10. I think I have to do quite a bit of work
to get the mesasdk working on this platform. If there is a quick and easy
answer, I'd love to know. With the existence of the non mesasdk makefile
header I have been able to get by and get pretty good results for my
purpose.

kind regards
ian

On 5 June 2017 at 13:38, RICHARD H D TOWNSEND <tow...@as...>
wrote:

> Hi Ian —
>
> HDF5 is a general-purpose platform-neutral format for data storage. It is
> (optionally) used in GYRE for input/output, and is also now used by some of
> the weak rates stuff.
>
> You can obtain the HDF5 library (either pre-built binaries, or source)
> from here:
>
> https://support.hdfgroup.org/HDF5/release/obtain518.html
>
> As the maintainer of the SDK, can I ask why you don’t use it? Is there
> something I could change which would make you more inclined to use the SDK?
>
> Best wishes,
>
> Rich
>
> > On Jun 4, 2017, at 10:32 PM, Ian Foley <ifo...@gm...> wrote:
> >
> > Hi,
> >
> > I am a user who is not using the mesasdk, so I use the
> makefile_header_non_mesasdk file to generate the star executable.
> >
> > A new addition with this version is the hdf5 library which I gather has
> something to do with processing weak rates. There is nothing in the release
> notes about it.
> >
> > However, the code in the header file shows how to generate the hdf5
> library with ifort, but not with gfortran. So before I delve deeper I'm
> wondering how I create this library and set it up with gfortran.
> >
> > Thanks
> > Ian
> > ------------------------------------------------------------
> ------------------
> > 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] Generating version 9793

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

Hi

Try just replacing ifort with gfortran in the commands.

Rob


On Jun 4, 2017 20:33, "Ian Foley" <ifo...@gm...> wrote:

Hi,

I am a user who is not using the mesasdk, so I use the
makefile_header_non_mesasdk file to generate the star executable.

A new addition with this version is the hdf5 library which I gather has
something to do with processing weak rates. There is nothing in the release
notes about it.

However, the code in the header file shows how to generate the hdf5 library
with ifort, but not with gfortran. So before I delve deeper I'm wondering
how I create this library and set it up with gfortran.

Thanks
Ian

------------------------------------------------------------
------------------
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] Generating version 9793

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

Hi Ian —

HDF5 is a general-purpose platform-neutral format for data storage. It is (optionally) used in GYRE for input/output, and is also now used by some of the weak rates stuff.

You can obtain the HDF5 library (either pre-built binaries, or source) from here:

https://support.hdfgroup.org/HDF5/release/obtain518.html

As the maintainer of the SDK, can I ask why you don’t use it? Is there something I could change which would make you more inclined to use the SDK?

Best wishes,

Rich

> On Jun 4, 2017, at 10:32 PM, Ian Foley <ifo...@gm...> wrote:
> 
> Hi,
> 
> I am a user who is not using the mesasdk, so I use the makefile_header_non_mesasdk file to generate the star executable.
> 
> A new addition with this version is the hdf5 library which I gather has something to do with processing weak rates. There is nothing in the release notes about it.
> 
> However, the code in the header file shows how to generate the hdf5 library with ifort, but not with gfortran. So before I delve deeper I'm wondering how I create this library and set it up with gfortran.
> 
> Thanks
> Ian
> ------------------------------------------------------------------------------
> 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] Generating version 9793

[Ian F. <ifo...@gm...>]

Hi,

I am a user who is not using the mesasdk, so I use the
makefile_header_non_mesasdk file to generate the star executable.

A new addition with this version is the hdf5 library which I gather has
something to do with processing weak rates. There is nothing in the release
notes about it.

However, the code in the header file shows how to generate the hdf5 library
with ifort, but not with gfortran. So before I delve deeper I'm wondering
how I create this library and set it up with gfortran.

Thanks
Ian

Re: [mesa-users] save model for gyre

[Jim F. <jf...@ca...>]

Hi Jing,

I think you need to add these lines to your control inlist:

      write_pulse_data_with_profile = .true.
      pulse_data_format = 'GYRE'

Hopefully that is all you need.

-Jim



On Sun, Jun 4, 2017 at 11:49 AM, Frank Timmes <fx...@ma...> wrote:

> from mesastar.org/astero_module.html
> and star/astero/defaults/astero_search.defaults
>
> it appears the controls
>
> write_gyre_for_each_model = .false.
> gyre_prefix = 'gyre_'
>    ! note that you can include a directory in the prefix if desired
> gyre_postfix = '.data’
>
> might achieve the desired goal.
>
> fxt
>
>
>
>
>
> > On Jun 4, 2017, at 8:53 AM, Jing Luan <jin...@gm...> wrote:
> >
> > Dear mesa users,
> >
> > Is there a subroutine that I could call in run_star_extras.f to save a
> model file in the format that gyre could read in, i.e. 'model.mesa' format.
> Currently, I use the following in inlist
> >
> >       save_pulsation_info_when_terminate = .true.
> >       save_pulsation_info_filename = 'model.mesa'
> >
> > which only saves the model at termination. But I like to save a series
> of models for gyre at different evolutionary ages for one star.
> >
> > Many thanks!
> >
> > Sincerely,
> > Jing
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
> _________________________________________
> > mesa-users mailing list
> > mes...@li...
> > https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>

Re: [mesa-users] save model for gyre

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

from mesastar.org/astero_module.html 
and star/astero/defaults/astero_search.defaults

it appears the controls

write_gyre_for_each_model = .false.
gyre_prefix = 'gyre_' 
   ! note that you can include a directory in the prefix if desired
gyre_postfix = '.data’

might achieve the desired goal.

fxt





> On Jun 4, 2017, at 8:53 AM, Jing Luan <jin...@gm...> wrote:
> 
> Dear mesa users,
> 
> Is there a subroutine that I could call in run_star_extras.f to save a model file in the format that gyre could read in, i.e. 'model.mesa' format. Currently, I use the following in inlist
> 
>       save_pulsation_info_when_terminate = .true.
>       save_pulsation_info_filename = 'model.mesa'
> 
> which only saves the model at termination. But I like to save a series of models for gyre at different evolutionary ages for one star. 
> 
> Many thanks!
> 
> Sincerely,
> Jing
> ------------------------------------------------------------------------------
> 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] save model for gyre

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

Dear mesa users,

Is there a subroutine that I could call in run_star_extras.f to save a
model file in the format that gyre could read in, i.e. 'model.mesa' format.
Currently, I use the following in inlist

      save_pulsation_info_when_terminate = .true.
      save_pulsation_info_filename = 'model.mesa'

which only saves the model at termination. But I like to save a series of
models for gyre at different evolutionary ages for one star.

Many thanks!

Sincerely,
Jing

Re: [mesa-users] astero scan grid terminal output

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

Hi Jean —

Thanks for bringing this to our attention -- I’ll try to find some time this month to look into it.

Best wishes,

Rich

> On Jun 2, 2017, at 2:27 PM, Jean McKeever <je...@nm...> wrote:
> 
> Hello,
> 
> I may have noticed a very minor bug. When running astero with the scan grid option it prints the wrong information to the terminal. It appears to operate fine and writes the correct information to files but just displays incorrectly. 
> 
> When restarting a grid from some point it reads in and prints the previous samples to the terminal, those values where vary_(value) = .true.  are fine, but values that are supposed to be fixed as the first_(value) are showing as the min_(value). No impact on the actual models but misleading information printed to screen.
> 
> The line that prints the next grid point to evaluate is also reproducing the same error.
> 
> Jean
> ------------------------------------------------------------------------------
> 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] astero scan grid terminal output

[Jean M. <je...@nm...>]

Hello,

I may have noticed a very minor bug. When running astero with the scan grid
option it prints the wrong information to the terminal. It appears to
operate fine and writes the correct information to files but just displays
incorrectly.

When restarting a grid from some point it reads in and prints the previous
samples to the terminal, those values where vary_(value) = .true.  are
fine, but values that are supposed to be fixed as the first_(value) are
showing as the min_(value). No impact on the actual models but misleading
information printed to screen.

The line that prints the next grid point to evaluate is also reproducing
the same error.

Jean

Re: [mesa-users] Z=0.04 and MESA r9793

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

Hi Aaron,

> I've done experiments like this in the past.  This situation seems to be in
> line with those.  The key difference in the EOS is the treatment of
> ionization.  HELM assumes full ionization and so will have a very different
> mean molecular weight than the OPAL tables in the outer layers of the
> model.  This is a metal-rich model evolving toward the RGB.  The attached
> shows two different evolutionary tracks, done with the same inlist and
> initial model supplied by Philip.  1000 timesteps in each.  The only
> difference is that I've only one EOS or the other in each.
> [image: Inline image 1]
> The difference is quite striking and becomes more pronounced as Teff
> decreases.  I'm not saying there is anything wrong with HELM, it does what
> it's designed to do. The only problem occurs when it is used out of
> context.

Indeed; that's the physical explanation.  (I'm still slightly puzzled by
the difference in behavior between r8845 and r9793.)

There is one subtlety of this whole EOS mess, which is that there are a
bunch of places where MESA attempts to mock up the effects of ionization
in HELM by blending between a version that includes the electrons and a
version that doesn't.  There are at least 3 such blends that I'm aware
of, all in different places in the code.  There's one embedded in the
MESA tables, one inside the HELM code, and then a user-controllable one
in the eos module.  The controllable one is

  http://mesa.sourceforge.net/star_job_defaults.html#set_HELM_ion_neutral_blends

but the default values are quite high for a hydrogen-helium dominated
composition.  (This blend is usually only hit in evolved stars.)

> I would suggest based on this that we should have a test_suite case
> that specifically checks the behavior at the Z=0.04.

Yes, that is a good idea.

Josiah

Re: [mesa-users] Z=0.04 and MESA r9793

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

>
> What I don't understand (and will have to investigate) is why this
> particular case behaves so badly.  There was not supposed to have been a
> significant change in the default behavior.
>

I've done experiments like this in the past.  This situation seems to be in
line with those.  The key difference in the EOS is the treatment of
ionization.  HELM assumes full ionization and so will have a very different
mean molecular weight than the OPAL tables in the outer layers of the
model.  This is a metal-rich model evolving toward the RGB.  The attached
shows two different evolutionary tracks, done with the same inlist and
initial model supplied by Philip.  1000 timesteps in each.  The only
difference is that I've only one EOS or the other in each.
[image: Inline image 1]
The difference is quite striking and becomes more pronounced as Teff
decreases.  I'm not saying there is anything wrong with HELM, it does what
it's designed to do. The only problem occurs when it is used out of context.

I would suggest based on this that we should have a test_suite case that
specifically checks the behavior at the Z=0.04.


Aaron

Re: [mesa-users] Z=0.04 and MESA r9793

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

Hi Philip,

> I want to use MESA r9793 to evolve a 1.3Msol, Y=0.32, Z=0.04 star from the
> zero age main sequence. I find strange behaviour near the base of the giant
> branch for this high metallicity star: a jump in L and Teff, as shown in
> the attached HR diagram (z0.04...pdf, red track, jump between the crosses).
> The same model evolved with r8845 (black track) does not show this jump.
>
> I assume this is related to changes to the opacity and/or equation of
> state, but I haven't been able to solve it. Do you have any ideas?

As you suspected, this an EOS issue.  There are OPAL tables for Z = 0,
0.02, and 0.04.  For higher Z, we switch to HELM.

The new release has controls that expose some of the blending options to
the user (as opposed to hardcoding them).

Try running with the options in star_job

    set_HELM_OPAL_Zs = .true.
    Z_all_OPAL = 1.0
    Z_all_HELM = 1.0

that should keep you on the OPAL tables (i.e. you'll never blend into
HELM).

What I don't understand (and will have to investigate) is why this
particular case behaves so badly.  There was not supposed to have been a
significant change in the default behavior.

Josiah

[mesa-users] Z=0.04 and MESA r9793

[Philip D. H. <pdh...@gm...>]

Hello,

I want to use MESA r9793 to evolve a 1.3Msol, Y=0.32, Z=0.04 star from the
zero age main sequence. I find strange behaviour near the base of the giant
branch for this high metallicity star: a jump in L and Teff, as shown in
the attached HR diagram (z0.04...pdf, red track, jump between the crosses).
The same model evolved with r8845 (black track) does not show this jump.

I assume this is related to changes to the opacity and/or equation of
state, but I haven't been able to solve it. Do you have any ideas?

Initial model and inlist for r9793 attached. The initial model is a
homogenous 1.3Msol, Y=0.32, Z=0.04 ZAMS star.

The other plot (z0.02...pdf) compares 1.3Msol, Y=0.28, Z=0.02 models
evolved with r8845 and r9793. The tracks lie on top of each other.

Thanks,

Philip D. Hall
Armagh Observatory