[Mesa-users] EOS/opacity (?) issues in proto-WDs
Pablo Marchant
pamarca at gmail.com
Thu Apr 11 10:06:22 EDT 2019
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/6d141ff1/attachment.html>
More information about the Mesa-users
mailing list