[Mesa-users] [EXTERNAL] Artificially inflating a star

Dean Townsley Dean.M.Townsley at ua.edu
Thu Mar 4 01:46:30 UTC 2021


Hi James,

While I think changing the size of the star that MESA produces is 
difficult, since that is determined by the physical state of the star, I 
think you can accomplish what you want in a different way.

The mass transfer rate between stars is usually determined by comparing 
the radius of the donor star (R_1) and the Roche Lobe radius (R_RL1).  A 
good example is equations 13 and just after in Paxton et al (2015).  I 
think you can accomplish what you want just by effectively changing how 
R_1 and R_RL are used to compute the mass transfer rate.  e.g. use f*R_1 
where f is some inflation factor (like 1.02 for a 2% inflation), and/or 
something similar applied to R_RL1.

To implement this, I think you would want to implement your own 
subroutine to attach to the other_rlo_mdot() subroutine hook in your 
run_binary_extras.f90 and have use_other_rlo_mdot set to true.  You'll 
probably want to pattern your function after the actual rlo_mdot() 
subroutine that is in binary/private/binary_mdot.f90.  It looks like 
that implements what is described in Paxton et al. (2015).

This is somewhat like what is done in the run_binary_extras.f90 that is 
included with the Pala et al (2017) paper, but there it was done for the 
angular momentum loss rate using the other_jdot_mb() hook.  So it might 
be good to use the run_binary_extras.f90 there as an example of how to 
use one of these hooks.  There is also some documentation about using 
the _extras stuff on the mesa website I believe.

Hopefully that at least gets you started in the right direction.

Dean


On 3/3/21 2:00 AM, James Wild via Mesa-users wrote:
> Hi,
>
> I'm trying to simulate a full CV evolutionary track, based on the work 
> by Paxton et.al. (2015) 
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fui.adsabs.harvard.edu%2Fabs%2F2015ApJS..220...15P%2Fabstract&data=04%7C01%7Cdmtownsley%40ua.edu%7C41c84eab4da3415826b508d8de1a8c5c%7C2a00728ef0d040b4a4e8ce433f3fbca7%7C0%7C0%7C637503552909444457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WAwYiJ67P9KXi8420O4H1gC9CoywhxygwB8UwgvrCns%3D&reserved=0>, 
> similar to this Pala (2017) paper 
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fui.adsabs.harvard.edu%2Fabs%2F2017MNRAS.466.2855P%2Fabstract&data=04%7C01%7Cdmtownsley%40ua.edu%7C41c84eab4da3415826b508d8de1a8c5c%7C2a00728ef0d040b4a4e8ce433f3fbca7%7C0%7C0%7C637503552909444457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ABYHYvrlf8PG5ZqV%2F2Kvqo5%2B3QEJpk4XBFE1dAKMGeU%3D&reserved=0>. 
> Their inlists are provided on cococubed, so make for a good jumping 
> off point. However, I'd like to make the empirical corrections that 
> Knigge (2011) 
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Farxiv.org%2Fabs%2F1102.2440&data=04%7C01%7Cdmtownsley%40ua.edu%7C41c84eab4da3415826b508d8de1a8c5c%7C2a00728ef0d040b4a4e8ce433f3fbca7%7C0%7C0%7C637503552909454460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vl1vf2OT3uYJVoNwWgzcVwj65nN5y%2FwydaWaellSZVE%3D&reserved=0> make 
> in their simulations, which includes modifying the radius of the M 
> dwarf donor star by about 10% to account for both the generally 
> underestimated radii of low mass main sequence stars, and the 
> non-spherical geometry of the Roche Lobes
>
> From what I understand, the radius of a star in mesa is an observable 
> quantity, calculated from other variables, rather than something that 
> can be modified directly by the user, but I'm sure there will be some 
> way to force the code to do this. I suspect that the non-spherical 
> Roche geometry is already accounted for in the mass transfer code, but 
> the underestimation of the main sequence radii can vary between 1-5%.
>
> Unfortunately, I'm not familiar enough with the codebase to do this 
> while being sure I'm not breaking anything important, what might the 
> best approach be here?
>
> Thanks for your time,
> James Wild.
>
> _______________________________________________
> 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/20210303/87778e28/attachment.htm>


More information about the Mesa-users mailing list