[Mesa-users] Question about using other_cgrav with the PPISN test_suite

[Rob Farmer]

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=[image: 10^{-5}] [image: \alpha_{MLT}=2]. 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
>>> <https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mesastar.org%2Fmailman%2Flistinfo%2Fmesa-users&data=02%7C01%7Cr.j.farmer%40uva.nl%7Cf129d5c03153447e482008d821fc02f3%7Ca0f1cacd618c4403b94576fb3d6874e5%7C1%7C0%7C637296713561034052&sdata=0hr9QJ5nDLL%2BUd%2B2OUsGwr%2BqzMKXoV9BqdBMw3naSKs%3D&reserved=0>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20200707/3d95d89f/attachment.htm>