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