[Mesa-users] Question about using other_cgrav with the PPISN test_suite
Pablo Marchant
pamarca at gmail.com
Tue Jul 14 04:37:47 EDT 2020
You can do it using the create_zams test case. You'll need to modify
inlist_zams_specification so it covers a relevant range of masses. You can
then copy your zams file to data/star_data/zams_models, and you'll need to
specify it in your inlist as well using the zams_filename option in
controls.
I believe it is possible to do this through run_star_extras and create just
the model you need, but it's not something straightforward for which I can
provide simple instructions.
Cheers
On Tue, Jul 14, 2020 at 10:22 AM Jeremy Sakstein <sakstein at hawaii.edu>
wrote:
> Thanks Pablo,
>
> What’s the best way of doing this?
>
> Can I create the zams from within run_star_extras by calling create pre-ms
> with a stopping condition or do I need to create them separately?
>
> Cheers,
>
> Jeremy
>
> On Tue, Jul 14, 2020 at 02:38 Pablo Marchant <pamarca at gmail.com> wrote:
>
>> Hi Jeremy, indeed that would cause problems. Simple solution would be for
>> you to create your own set of ZAMS models for each value of G you want to
>> modify. If you were to change G during the relaxation you won't relax to
>> our target.
>>
>> Cheers
>>
>> On Tue, Jul 14, 2020 at 5:11 AM Jeremy Sakstein <sakstein at hawaii.edu>
>> wrote:
>>
>>> Hi Rob,
>>>
>>> Just to follow up on this.
>>>
>>> After extensive testing it appears that changing standard_cgrav in
>>> either const_def.f90 or extras_controls are equivalent to each other and
>>> they do indeed allow the star to get past where it was crashing when using
>>> other_cgrav so I have been using this approach. I'm not sure why using
>>> other_cgrav is causing the termination at earlier times though.
>>>
>>> I've been able to get the star to core collapse and PISN with larger
>>> values of G but I am still having trouble with the PPISN. I believe I have
>>> figured out the problem. During the relaxation procedure in
>>> extras_start_step a ZAMS model is loaded using call star_load_zams(id,
>>> ierr). Since these are created with standard_cgrav the called model is far
>>> from hydrostatic equilibrium with the new value of G and it is unable to
>>> find an acceptable model. I tried setting G back to its standard value
>>> through this phase but I get the crashes when I turn it back to a higher
>>> value. It appears the errors appear in star_relax_composition.
>>>
>>> Do you have any suggestions for how to get around this?
>>>
>>> Three ideas I had so far were to create ZAMS models with the higher
>>> value of G and read those in, somehow create a pre-MS model instead of
>>> loading a ZAMS, or to try to ease G from 1.0 up to the value I am using
>>> somehow.
>>>
>>> Cheers,
>>>
>>> Jeremy
>>>
>>>
>>>
>>> On Tue, Jul 7, 2020 at 1:00 PM Jeremy Sakstein <sakstein at hawaii.edu>
>>> wrote:
>>>
>>>> Hi Rob,
>>>>
>>>> Thank you so much for looking into this for me.
>>>>
>>>> I understand what you mean for skip_other_cgrav.
>>>>
>>>> This is indeed puzzling, I was able to get it to run when setting
>>>> standard_cgrav = 1.05*standard_cgrav in extras_controls but wasn't sure
>>>> whether this would truly change the value everywhere.
>>>>
>>>> We are running two tests at the moment. One changing standard_cgrav in
>>>> extras_controls and one changing it in const_def.f90 and recompiling that
>>>> module just to see if the two cases give identical results.
>>>>
>>>> To answer your question above: we did test a 1% increase in G. This
>>>> case runs to helium depletion but never gets to core collapse due to this
>>>> time step error. A 0.1% change did make it to CC but the final BH mass
>>>> (defined as mass bound with v<v_esc and v_esc updated to include the new G)
>>>> is 1.38E-05M, which we took to indicate a similar problem but not
>>>> catastrophic enough to cause a crash.
>>>>
>>>> Cheers,
>>>>
>>>> Jeremy
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jul 7, 2020 at 12:28 PM Rob Farmer <r.j.farmer at uva.nl> wrote:
>>>> >
>>>> > >If you flip the flag to .false. for skip_other_cgrav ( and run ./mk
>>>> && ./export in star and ./mk in your work directory) does that help?
>>>> >
>>>> > So that turns out to be a bad idea.
>>>> >
>>>> > The reason we set it false, is that during the newton iterations we
>>>> want to keep it constant. if you simply search the code for where
>>>> skip_other_cgrav is used (rather than just being passed as an argument to a
>>>> function) you'll find in set_basic_vars in hydro_vars.f90
>>>> >
>>>> > if (.not. skip_other_cgrav) then
>>>> > if (s% use_other_cgrav) then
>>>> > call s% other_cgrav(s% id, ierr)
>>>> > if (ierr /= 0) then
>>>> > if (s% report_ierr .or. dbg) &
>>>> > write(*,*) 'other_cgrav returned ierr', ierr
>>>> > return
>>>> > end if
>>>> > else if (s% zero_gravity) then
>>>> > s% cgrav(nzlo:nzhi) = 0d0
>>>> > else
>>>> > s% cgrav(nzlo:nzhi) = standard_cgrav
>>>> > end if
>>>> > end if
>>>> >
>>>> > Note the logic, when skip_other_cgrav=.true. we don't enter the
>>>> if-block at all so we don't change cgrav from whatever value it had (but it
>>>> will keep its existing value). So cgrav will still be set with your changed
>>>> value, we just don't update it during a newton iteration (only between
>>>> steps). This of course means it shouldn't matter for your problem, as you
>>>> only have a scaler change in standard_cgrav, why then varying how you set
>>>> matters for your case then is puzzling.
>>>> >
>>>> > Rob
>>>> >
>>>> > On Tue, 7 Jul 2020 at 17:19, Rob Farmer <r.j.farmer at uva.nl> wrote:
>>>> >>
>>>> >> Hi,
>>>> >>
>>>> >> Okay so your plots are showing that you're not even exited core
>>>> helium burning yet (or maybe just at the end of it as you have not started
>>>> neutrino cooling in the core yet), which means you're a long way from hydro
>>>> turning on (which doesn't need to be on until just before c/o burning
>>>> starts).
>>>> >>
>>>> >> By setting the min timestep limit to 1d-99 you miss where the actual
>>>> problem is which starts much earlier in the slurm output. Around line
>>>> 31,800 in your slurm file is when you model first reaches model number
>>>> 2513, which then never increases because every step becomes a retry. I
>>>> expect that your model crashes in the end simply because it has such a tiny
>>>> dt, that any property that is divided by the timestep will become huge.
>>>> >>
>>>> >> So why does your model stop working at model ~2510? Well the
>>>> convection zone certainly looks horrible around 1500-2000 which might be
>>>> telling us something.
>>>> >>
>>>> >> >I am not very familiar with these routines but are these the
>>>> routines called when hydro is turned on
>>>> >>
>>>> >> Yes/no they are always called even when the hydrodynamics is turned
>>>> off, they are not specific to the choice of using the v/u flag. The hydro_*
>>>> files are where mesa pulls all the physics together and puts the
>>>> variables/derivatives into the matrix to be solver.
>>>> >>
>>>> >> Do other choices of cgrav work? Ie if you did 1.01*standard_cgrav
>>>> (or 0.99*) which would help us know if it is simply too big a change in
>>>> cgrav or whether all other choices of cgrav are affected.
>>>> >> If you flip the flag to .false. for skip_other_cgrav ( and run ./mk
>>>> && ./export in star and ./mk in your work directory) does that help?
>>>> >>
>>>> >> Rob
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Tue, 7 Jul 2020 at 00:29, Jeremy Sakstein <sakstein at hawaii.edu>
>>>> wrote:
>>>> >>>
>>>> >>> Hi Rob,
>>>> >>>
>>>> >>> I'm attaching the Kippenhan plot(s) you requested. The plot is for
>>>> a 60M star at Z= . The plot starts at the ZAHB and ends where the code runs
>>>> into the error vsurf> 100km/s.
>>>> >>>
>>>> >>> Green is convection, red is semi-convection, and purple is
>>>> overshooting.
>>>> >>>
>>>> >>> Cheers,
>>>> >>>
>>>> >>> Jeremy
>>>> >>>
>>>> >>> On Fri, Jul 3, 2020 at 7:32 AM Jeremy Sakstein <sakstein at hawaii.edu>
>>>> wrote:
>>>> >>>>
>>>> >>>> Hi Rob,
>>>> >>>>
>>>> >>>> I am working on that plot but I wanted to ask a quick followup
>>>> question. In star/private/hydro_vars.f90 it appears there is a logical
>>>> called skip_other_cgrav, which turns off other_cgrav for hydro.
>>>> >>>>
>>>> >>>> Some of these routines are called in hydro_mtx.f90 where it
>>>> appears skip_other_cgrav is set to true.
>>>> >>>>
>>>> >>>> I am not very familiar with these routines but are these the
>>>> routines called when hydro is turned on. If so, would this explain why
>>>> changing cgrav using other_cgrav causes a termination but changing
>>>> standard_cgrav lets everything proceed?
>>>> >>>>
>>>> >>>> Cheers,
>>>> >>>>
>>>> >>>> Jeremy
>>>> >>>>
>>>> >>>> On Thu, Jul 2, 2020 at 5:02 PM Jeremy Sakstein <
>>>> sakstein at hawaii.edu> wrote:
>>>> >>>>>
>>>> >>>>> Thanks Rob,
>>>> >>>>>
>>>> >>>>> I will set up another run and make a kippenhan plot now.
>>>> >>>>>
>>>> >>>>> I am attaching the terminal output from a typical run (MESA
>>>> version is 12778). In this version I use other_cgrav to set
>>>> cgrav(:)=1.05*standard_cgrav and also output s%cgrav(s% nz)/standard_cgrav
>>>> to the terminal every 50 steps (I do this in several places).
>>>> >>>>>
>>>> >>>>> It looks like the termination is due to v_surf_kms_limit. In
>>>> fact, the same run will terminate due to v_surf_div_v_kh_upper_limit
>>>> before this but I set this to 1d200. This is what made me suspect the star
>>>> is moving away from HSE.
>>>> >>>>>
>>>> >>>>> I will get that plot ASAP. In the meantime, do you have any
>>>> thoughts on why changing standard_cgrav directly didn't give this error but
>>>> using other_cgrav does?
>>>> >>>>>
>>>> >>>>> Cheers,
>>>> >>>>>
>>>> >>>>> Jeremy
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> On Thu, Jul 2, 2020 at 4:43 PM Rob Farmer <r.j.farmer at uva.nl>
>>>> wrote:
>>>> >>>>> >
>>>> >>>>> > Hi,
>>>> >>>>> >
>>>> >>>>> > We need more information on what is happening to the star at
>>>> the point it's crashes.
>>>> >>>>> >
>>>> >>>>> > Try making a kippenhan plot
>>>> >>>>> > What is limiting mesa's timestep?
>>>> >>>>> > What are the exact error messages mesa is returning?
>>>> >>>>> >
>>>> >>>>> > Rob
>>>> >>>>> >
>>>> >>>>> >
>>>> >>>>> > On Thu, 2 Jul 2020, 22:32 Adam Jermyn via Mesa-users, <
>>>> mesa-users at lists.mesastar.org> wrote:
>>>> >>>>> >>
>>>> >>>>> >> Hi Jeremy,
>>>> >>>>> >>
>>>> >>>>> >> Ok in that case I’m not sure what’s going on...
>>>> >>>>> >>
>>>> >>>>> >> -Adam
>>>> >>>>> >> On Jul 2, 2020, 4:03 PM -0400, Jeremy Sakstein <
>>>> sakstein at hawaii.edu>, wrote:
>>>> >>>>> >>
>>>> >>>>> >> Thanks Adam,
>>>> >>>>> >>
>>>> >>>>> >> As far as I am aware, I am not loading a pre made model but
>>>> using create_pre_main_sequence_model=.true. so I don't think this should be
>>>> an issue no?
>>>> >>>>> >>
>>>> >>>>> >> The first 300 odd steps appear to be model relaxation.
>>>> >>>>> >>
>>>> >>>>> >> Cheers,
>>>> >>>>> >>
>>>> >>>>> >> Jeremy
>>>> >>>>> >>
>>>> >>>>> >> On Thu, Jul 2, 2020 at 3:58 PM Adam Jermyn <
>>>> adamjermyn at gmail.com> wrote:
>>>> >>>>> >>>
>>>> >>>>> >>> Hi Jeremy,
>>>> >>>>> >>>
>>>> >>>>> >>> I’m not familiar with the PPISN test case specifically, but
>>>> changing cgrav and then loading a pre-existing model can be tricky. The
>>>> pre-existing model likely had the standard_cgrav value. When you change
>>>> that value even by a small amount you’re kicking the model way out of
>>>> hydrostatic equilibrium, which will require significant adjustment to
>>>> restore.
>>>> >>>>> >>>
>>>> >>>>> >>> For instance, if you take a solar model and change cgrav down
>>>> by 1% with hydro on I’d expect the surface to expand at ~1%*(escape
>>>> velocity), which can be large…
>>>> >>>>> >>>
>>>> >>>>> >>> Someone more familiar with PPISN might be able to say more
>>>> though...
>>>> >>>>> >>>
>>>> >>>>> >>> -Adam
>>>> >>>>> >>> On Jul 2, 2020, 3:48 PM -0400, Jeremy Sakstein <
>>>> sakstein at hawaii.edu>, wrote:
>>>> >>>>> >>>
>>>> >>>>> >>> Hi everyone,
>>>> >>>>> >>>
>>>> >>>>> >>> I have a question about the PPISN test suite.
>>>> >>>>> >>>
>>>> >>>>> >>> I am trying to use other_cgrav with G rescaled by a constant
>>>> (1 + a small number) and I have run into some issues. When I change G by a
>>>> few % or more I am finding that the code terminates due to reaching the
>>>> time step limit (I set this to 1d-99).
>>>> >>>>> >>>
>>>> >>>>> >>> My initial explorations of changing various controls led me
>>>> to believe that the star was going away from hydrostatic equilibrium, my
>>>> evidence for this being that I kept running into various stropping
>>>> conditions telling me that the surface velocity was too high. These errors
>>>> show up before hydro is turned on for the first time.
>>>> >>>>> >>>
>>>> >>>>> >>> My two leading hypotheses are:
>>>> >>>>> >>>
>>>> >>>>> >>> Hydro is turning on too late i.e. after the star begins to
>>>> expand or
>>>> >>>>> >>> other_cgrav is not implemented in every equation being solved
>>>> in this test_suite leading to cumulative errors.
>>>> >>>>> >>>
>>>> >>>>> >>> I tested (1) by turning hydro on from the start of the run.
>>>> In this case I didn't get any termination codes but the runs take a very
>>>> long time. I was able to get past the temperatures and densities where the
>>>> code previously terminated however.
>>>> >>>>> >>>
>>>> >>>>> >>> I tested (2) by turning off other_cgrav and instead setting:
>>>> >>>>> >>>
>>>> >>>>> >>> standard_cgrav = 1.05*standard_cgrav
>>>> >>>>> >>>
>>>> >>>>> >>> in extras_controls in run_star_extras. I have used this
>>>> procedure before for e.g. the RSP module.
>>>> >>>>> >>>
>>>> >>>>> >>> Is anyone able to give me any insight into what is happening
>>>> here, and whether I am on the right track with (1) or (2).
>>>> >>>>> >>>
>>>> >>>>> >>> My own tests suggest that my procedure (2) is working as
>>>> expected i.e. the value of G is indeed altered for every equation being
>>>> solved by setting it in extras_controls but it would be great if someone
>>>> were able to confirm this for me.
>>>> >>>>> >>>
>>>> >>>>> >>> I'd be very grateful for any help you can give.
>>>> >>>>> >>>
>>>> >>>>> >>> Cheers,
>>>> >>>>> >>>
>>>> >>>>> >>> Jeremy
>>>> >>>>> >>> _______________________________________________
>>>> >>>>> >>> mesa-users at lists.mesastar.org
>>>> >>>>> >>> https://lists.mesastar.org/mailman/listinfo/mesa-users
>>>>
>>>>> _______________________________________________
>>> mesa-users at lists.mesastar.org
>>> https://lists.mesastar.org/mailman/listinfo/mesa-users
>>>
>>>
>>
>> --
>> Pablo Marchant Campos
>> M.Sc on Astrophysics, Universidad Católica de Chile
>> PhD on Astrophysics, Argelander-Institut für Astronomie, Universität Bonn
>>
>
--
Pablo Marchant Campos
M.Sc on Astrophysics, Universidad Católica de Chile
PhD on Astrophysics, Argelander-Institut für Astronomie, Universität Bonn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20200714/2f2d7d13/attachment.htm>
More information about the Mesa-users
mailing list