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