[Mesa-users] EOS/opacity (?) issues in proto-WDs
Pablo Marchant
pamarca at gmail.com
Thu Apr 11 10:07:36 EDT 2019
PS: a plot is worth a thousand words.
On Thu, Apr 11, 2019, 09:06 Pablo Marchant <pamarca at gmail.com> wrote:
> Hi Patrick,
>
> Before checking this can you provide a bit of a summary on when are you
> finding issues? Is this during a hydrogen flash? Does it happen while
> undergoing mass transfer? Does it happen on the same point of evolution
> with hydro on/off? I'm also still not sure that you require hydrodynamics
> for what you're trying to do, what makes you think that is the case?
>
> Also, if you try things with hydrodynamics off be sure to try a model from
> the very start in that way, not just shutting off hydro on the run that's
> already at a problematic stage.
>
> Cheers
>
>
> On Thu, Apr 11, 2019, 05:02 Patrick Neunteufel <
> neunteufel at astro.uni-bonn.de> wrote:
>
>> Dear Pablo,
>>
>> Thanks for the reply. I was not aware of that aspect of the report_ierr
>> option, which explains why the code seems to stop a little earlier than
>> without it. Thanks. However, that does not seem to solve the problem. As
>> you suspected, disabling the report_ierr leads to a decrease in the
>> timestep, then an eventual crash.
>> Having hydrodynamics enabled will be necessary at the end (I am aware of
>> the issues, but thanks for reminding me), but since this problem seems to
>> occur regardless of whether hydrodynamics is enabled or not, I would be
>> grateful for any solution, even one neglecting it for the moment.
>> Please find attached the relevant He-star.mod, which should enable you to
>> reproduce the problem. Note that this model has lnPgas_flag = true, but, as
>> far as I can tell, this does not change any of the problematic behavior.
>> Also, as far I can tell, the crash seems to occur once the center of the
>> proto-WD becomes degenerate, if that helps.
>>
>> Best
>>
>> Patrick
>>
>>
>>
>> On 10. Apr 2019, at 20:30, Pablo Marchant <pamarca at gmail.com> wrote:
>>
>> Hi Patrick,
>>
>> you're not providing enough information to reproduce the problem, as your
>> inlists make use of a saved model. It's also more practical if you provide
>> files as an attachment instead.
>>
>> Some comments though, from your output, the "get_surf_PT: L_surf <= 0"
>> message indicates the newton solver produced a negative surface luminosity,
>> at which point the code stops looking for a solution. The default behavior
>> in that case is for MESA to reduce the timestep and try again. However,
>> your inlist also has
>>
>> report_ierr = .true.
>>
>> which makes the code stop when it runs into this issue in particular.
>> This option is mostly for debugging purposes. It could be the case that if
>> you remove this, your simulation will work. It could be the case that you
>> end up with small timesteps so it does not progress. But you should first
>> try setting that option to false and see if its enough.
>>
>> Another detail is that you're using hydrodynamics in a binary system that
>> incorporates mass transfer. You should carefully evaluate whether you trust
>> the code under these conditions, in particular whether or not appropriate
>> boundary conditions are being used for the velocity. Have you run this code
>> without hydrodynamics and found that the system was evolving on a timescale
>> that could require a hydrodynamic calculation? From previous proto-wd
>> calculations I didn't see it was necessary, but your requirements may vary
>> depending on what you're doing exactly.
>>
>> Cheers
>>
>> On Wed, Apr 10, 2019 at 12:36 PM Patrick Neunteufel via Mesa-users <
>> mesa-users at lists.mesastar.org> wrote:
>>
>>> Hi everyone,
>>>
>>> Using MESA-r11554, I have the following problem: I am trying to follow
>>> the evolution of a mass losing He-rich star (initial mass 1.0 Msun) in a
>>> binary down to a mass of 0.1 Msun (below the mass limit for helium
>>> burning). However, once the model reaches between 0.32 and 0.29 Msun, the
>>> code runs into convergence issues and crashes with the following error and
>>> backtrace:
>>>
>>> get_surf_PT: L_surf <= 0 3101 -1.9452885788738120D+32
>>>
>>> L u kap logT logRho 1
>>> -1.9452885788738120D+32 NaN
>>> 7.0362623532835888D-01 4.0495086738376775D+00 -5.0086142130207394D+00
>>> L u kap logT logRho 2
>>> -1.8889367050152320D+32 NaN
>>> 4.6888668272319689D-01 4.0091836407479775D+00 -5.0192456415635389D+00
>>> L u kap logT logRho 3
>>> -1.8059551207355153D+32 NaN
>>> 2.8151702244064775D-01 3.9584024748335755D+00 -4.9293263060039179D+00
>>> L u kap logT logRho 4
>>> -1.6775802756995363D+32 NaN
>>> 1.3119664418262897D-01 3.9015665950252587D+00 -4.7667726811442810D+00
>>> L u kap logT logRho 5
>>> -1.4994868526987713D+32 NaN
>>> 9.3921074678169597D-02 3.8510174515718290D+00 -4.5847388422864057D+00
>>> L u kap logT logRho 6
>>> -1.2936231230392295D+32 NaN
>>> 1.1204973157540775D-01 3.8400372871190571D+00 -4.4850509611066780D+00
>>> L u kap logT logRho 7
>>> -1.1193008043810795D+32 NaN
>>> 8.5857002056263204D-02 3.8636664419891473D+00 -4.4909859600597848D+00
>>> L u kap logT logRho 8
>>> -1.0212568108683585D+32 NaN
>>> 8.5964276322603408D-02 3.8621801446661350D+00 -4.4756981402355818D+00
>>> L u kap logT logRho 9
>>> -9.4955104950687273D+31 NaN
>>> 1.4036385419077119D-01 3.8213026619507611D+00 -4.4176272353450017D+00
>>> L u kap logT logRho 10
>>> -8.8811180208086254D+31 NaN
>>> 6.3974290520336111D-02 3.7259415267112881D+00 -4.4247962698408703D+00
>>>
>>> logT =
>>> 4.0495086738376775D+00
>>> logRho =
>>> -5.0086142130207394D+00
>>> x =
>>> 2.5797528950722257D-61
>>> z =
>>> 1.7019582018497958D-02
>>> abar =
>>> 4.0521678090748869D+00
>>> zbar =
>>> 2.0260839045374435D+00
>>>
>>> s% use_compression_outer_BC F
>>> s% use_T_Paczynski_outer_BC F
>>> s% use_T_black_body_outer_BC F
>>> s% use_fixed_L_for_BB_outer_BC F
>>> s% tau_for_L_BB
>>> -1.0000000000000000D+00
>>>
>>> File: ../private/hydro_vars.f90, Line: 1342
>>> ERROR STOP 1
>>>
>>> Error termination. Backtrace:
>>> #0 0x14745007d
>>> #1 0x147450d15
>>> #2 0x147451c67
>>> #3 0x10f3f18a5
>>> #4 0x10ee5f0c3
>>> #5 0x10ee60a74
>>> #6 0x10ef3f480
>>> #7 0x10ef40e51
>>> #8 0x10ef572bd
>>> #9 0x10f0d401d
>>> #10 0x10f0e0ef3
>>> #11 0x10f0e2a7a
>>> #12 0x10f0e4c3b
>>> #13 0x10f0e5d5d
>>> #14 0x10f0f8db1
>>> #15 0x10f1457dd
>>> #16 0x10ed3499d
>>> #17 0x10ed0bb3d
>>> #18 0x10ed0bb50
>>> #19 0x10ed0bb89
>>>
>>>
>>> My best guess is that this has to do either with the eos, opacity tables
>>> or convection controls, but trying different combinations didn’t seem to
>>> have an effect (still resulting in the same outcome, albeit at slightly
>>> different masses). I also compared my models with the lgR and lgT parameter
>>> spaces for the eos and opacities provided in the most recent instrument
>>> paper they do not seem to run into any problematic areas. I can’t help but
>>> think that the solution ought to be reasonably simple and I’m just not
>>> seeing it, but it has eluded me so far. I’d be grateful for any ideas.
>>>
>>> See below for the minimum inlists needed to reproduce the problem (note
>>> that varcontrol = 1d-3 in order to get to the problematic phase in a
>>> reasonable time, the result will be the same with lower values). I can
>>> provide the initial helium star model too if required.
>>>
>>> Best regards
>>>
>>> Patrick
>>>
>>> Minimum inlists to reproduce the problem:
>>>
>>> ! inlist1
>>>
>>> &star_job
>>>
>>> load_saved_model = .true.
>>>
>>> saved_model_name = 'He-star.mod'
>>> save_model_when_terminate = .true.
>>> save_model_filename = 'final.mod'
>>> change_initial_net = .true.
>>> new_net_name = 'pp_extras.net'
>>> eos_file_prefix = 'mesa'
>>> kappa_file_prefix = 'gs98'
>>> change_v_flag = .true.
>>> new_v_flag = .true.
>>> set_initial_dt = .true.
>>> years_for_initial_dt = 1d-10
>>> pgstar_flag = .true.
>>>
>>> / ! end of star_job namelist
>>>
>>>
>>>
>>> &controls
>>>
>>> max_number_backups = 100
>>> varcontrol_target = 1d-3
>>> use_eosDT2 = .true.
>>> use_eosELM = .true.
>>> MLT_option = 'Henyey'
>>> report_ierr = .true.
>>> photo_interval = 100
>>> profile_interval = 50
>>> history_interval = 1
>>> terminal_interval = 10
>>> write_header_frequency = 10
>>> max_age = 10.1d9
>>> min_timestep_limit = -1
>>>
>>> / ! end of controls namelist
>>>
>>> ! inlist2
>>>
>>> &star_job
>>>
>>> show_log_description_at_start = .false.
>>>
>>> / ! end of star_job namelist
>>>
>>>
>>>
>>> &controls
>>>
>>> max_number_backups = 10
>>> max_number_retries = 80
>>>
>>> extra_terminal_output_file = 'log2'
>>> photo_directory = 'photos2'
>>> log_directory = 'LOGS2'
>>>
>>> varcontrol_target = 1d-3
>>>
>>>
>>> / ! end of controls namelist
>>>
>>> ! binary inlist
>>>
>>> &binary_job
>>>
>>> inlist_names(1) = 'inlist1'
>>> inlist_names(2) = 'inlist2'
>>>
>>> evolve_both_stars = .false.
>>>
>>> / ! end of binary_job namelist
>>>
>>> &binary_controls
>>>
>>>
>>> m2 = 1.7 ! companion mass in Msun
>>> initial_period_in_days = -1
>>> initial_separation_in_Rsuns = 0.848074
>>>
>>> limit_retention_by_mdot_edd = .true.
>>> mass_transfer_beta = 1.0
>>> report_rlo_solver_progress = .true.
>>>
>>> mdot_scheme = 'Ritter'
>>> implicit_scheme_tolerance = 1e-3
>>>
>>> max_tries_to_achieve = 10
>>>
>>>
>>> / ! end of binary_controls namelist
>>> _______________________________________________
>>> 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/20190411/947b5bb5/attachment.html>
More information about the Mesa-users
mailing list