[Mesa-users] EOS/opacity (?) issues in proto-WDs
Patrick Neunteufel
neunteufel at astro.uni-bonn.de
Fri Apr 12 09:11:14 EDT 2019
Hi Pablo,
Thanks for the help so far. I did a few more tests of my own and introducing a shallower composition gradient by including semiconvection does not seem to solve the issue. Apparently, the problem manifests as a convergence issue in the hydro solver once RLOF affects former burning regions. My earlier assumption that degeneracy may have something to do with it seems to be in error.
I also forgot to include the initial orbital separation of the plot I sent you yesterday, in case you want to reproduce the error: initial_separation_in_Rsuns = 0.556062
The rest of the inlists are as posted on Wednesday.
Best
Patrick
> On 11. Apr 2019, at 18:43, Patrick Neunteufel <neunteufel at astro.uni-bonn.de> wrote:
>
> Yes, I assumed that the composition discontinuity could be part of the problem. As for magnetic braking: Thanks for pointing this out. I momentarily forgot that magnetic braking is enabled by default.
>
> Anyhow: running the same experiment with a lower mass donor star, magnetic braking disabled and closer initial orbital separation (see final plot preceding the crash below) results in the same problem.
>
> Best
>
> Patrick
>
> <He-star.mod>
>
>
> <grid1003670.png>
>
>> On 11. Apr 2019, at 16:59, Pablo Marchant <pamarca at gmail.com <mailto:pamarca at gmail.com>> wrote:
>>
>> That's already pretty informative. You can see that the issues arises when the outer layers of the star are stripped down to the former convective core, where there will be a composition discontinuity. Will quickly debug it to see if there's something fundamental leading to issues here, but a couple of comments.
>>
>> - During this phase there is no justification to really using hydrodynamics
>> - The only reason your system is reaching Roche lobe overflow is because its using magnetic braking. I don't know if you want that, but you should be aware that the magnetic braking prescription used is constructed from solar type stars, so applying it in here is questionable. If you want to turn it off just set do_jdot_mb = .false. in your inlist_project.
>>
>> Cheers
>>
>> On Thu, Apr 11, 2019 at 9:36 AM Patrick Neunteufel <neunteufel at astro.uni-bonn.de <mailto:neunteufel at astro.uni-bonn.de>> wrote:
>> Dear Pablo,
>>
>>> 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?
>>
>> Sure. First: This model is hydrogen depleted. I am trying to model the evolution of a helium rich star undergoing RLOF at masses lower than 0.3 Msun. In fact, the problem occurs just before further nuclear burning becomes unsustainable (logLHe ≤ -1.5). I initialized the model I sent you with hydro off, and as far as I can tell, the problem occurs at the same point with hydro on or off, even when rerun from the start of the caclulation. I attached a plot taken just before the model crashed with hydro disabled. Subsequent to this, there were convergence issues in the mass transfer calculation, followed by a decrease of the timestep to about ln(dt) = -2, then a series of retries and redos, then the model crashed.
>>
>> Best
>>
>> Patrick
>>
>> <grid1003410.png>
>>
>>> On 11. Apr 2019, at 16:06, Pablo Marchant <pamarca at gmail.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <http://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 <mailto:mesa-users at lists.mesastar.org>
>>>> https://lists.mesastar.org/mailman/listinfo/mesa-users <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
>>>
>>
>>
>>
>> --
>> 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/20190412/69f18a83/attachment.html>
More information about the Mesa-users
mailing list