[Mesa-users] Question about using other_cgrav with the PPISN test_suite
Jeremy Sakstein
sakstein at hawaii.edu
Tue Jul 14 04:21:55 EDT 2020
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20200714/8a3c0204/attachment.htm>
More information about the Mesa-users
mailing list