[Mesa-users] Question about using other_cgrav with the PPISN test_suite
Rob Farmer
r.j.farmer at uva.nl
Tue Jul 7 12:28:19 EDT 2020
>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=[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/5a1f34f0/attachment.htm>
More information about the Mesa-users
mailing list