[Mesa-users] EOS/opacity (?) issues in proto-WDs
Pablo Marchant
pamarca at gmail.com
Wed Apr 10 14:30:01 EDT 2019
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/20190410/4d1de193/attachment.html>
More information about the Mesa-users
mailing list