[Mesa-users] Question about using other_cgrav with the PPISN test_suite
Pablo Marchant
pamarca at gmail.com
Tue Jul 14 02:38:36 EDT 2020
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/35b7fb79/attachment.htm>
More information about the Mesa-users
mailing list