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

[Jeremy Sakstein]

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/20200702/ce76a58a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slurm-10113648.out
Type: application/octet-stream
Size: 2881150 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20200702/ce76a58a/attachment-0001.obj>