[Mesa-users] Binaries and wide orbital separation

Rob Farmer r.j.farmer at uva.nl
Thu Nov 5 04:58:55 EST 2020


>But is there a way beyond the "./re x..." to make it automatic within all
the inlists? For instance, if I wanted to pass from inlist_to_si_burn to
inlist_to_cc using photos, what should I do?

While you can change the inlists a star uses by stopping the file, editing
the inliist, and doing a ./re that's not a good idea for reproducibility
(also alot of inlist options wont take effect after a ./re). Just use the
existing mechanism where it saves a mod file at the end of each inlist,
then do as Frank suggested and have each inlist specify where to write the
LOGS folder.

Rob

On Thu, 5 Nov 2020 at 10:30, Amedeo Romagnolo via Mesa-users <
mesa-users at lists.mesastar.org> wrote:

> But is there a way beyond the "./re x..." to make it automatic within all
> the inlists? For instance, if I wanted to pass from inlist_to_si_burn to
> inlist_to_cc using photos, what should I do? Write something in the inlists?
>
> Amedei
>
> On Thu, 5 Nov 2020 at 05:03, Francis Timmes <fxt44 at mac.com> wrote:
>
>> if one sticks with runs from .mod files, one can set the history file
>> name for each inlist:
>> http://mesa.sourceforge.net/controls_defaults.html#star_history_name
>> <https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmesa.sourceforge.net%2Fcontrols_defaults.html%23star_history_name&data=04%7C01%7Cr.j.farmer%40uva.nl%7C281e52f8b7af4c90e1f008d8816d89e6%7Ca0f1cacd618c4403b94576fb3d6874e5%7C1%7C1%7C637401654759347213%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FtVcwoXjI4G2ZgJbSrl72SvpSdh7SvJ7qxz5AzpgFLI%3D&reserved=0>
>>
>> alternatively, if one restarts from photos, then the history file is a
>> single file containing all data points. this is my preferred workflow.
>>
>> fxt
>>
>>
>>
>>
>>
>>
>> > On Nov 4, 2020, at 11:33 AM, Amedeo Romagnolo <
>> amedeoromagnolo at gmail.com> wrote:
>> >
>> > Thanks, it was actually helpful.
>> > Probably my initial setup was too "vanilla" to go beyond the giant
>> phase.
>> >
>> > I used the default "high-mass" and "black-hole" scenarios and it
>> actually went further.
>> >
>> > My (hopefully) last question here is the related to the "black hole"
>> default setting:
>> >
>> > In the final history.data file I get only the output from the
>> "inlist_to_cc" setting, which I believe is the one that leads to the final
>> collapse, while the whole part relative to pre-ZAMS and the whole main
>> sequence is lost because overwritten in history.data . How can I set things
>> up with the multiple inlists in a way that I'm not losing the whole history
>> and I can analyse the whole evolution from star_age = 0 yr?
>> >
>> >
>> > Thanks,
>> >
>> > Amedeo
>> >
>> > On Mon, 2 Nov 2020, 16:03 Francis Timmes, <fxt44 at mac.com> wrote:
>> > i suggest running a single star model, the more massive one,
>> > to make sure that works before attempting a binary.
>> >
>> > fxt
>> >
>> >
>> >
>> >
>> > > On Nov 2, 2020, at 2:18 AM, Amedeo Romagnolo via Mesa-users <
>> mesa-users at lists.mesastar.org> wrote:
>> > >
>> > > Hello Rob,
>> > >
>> > > I did as you recommended me, and apparently the code stops because
>> the star is going into the giant phase.
>> > > I tried to keep my code pretty vanilla, but I am obviously missing
>> something pretty important here that I cannot understand yet.
>> > >
>> > > Do you have any suggestion in this regard?
>> > >
>> > > Cheers,
>> > >
>> > > Amedeo
>> > >
>> > > On Mon, 26 Oct 2020 at 21:35, Rob Farmer <r.j.farmer at uva.nl> wrote:
>> > > Okay so it's not RLOF that's causing the issue, though the envelope
>> is starting to expand.
>> > >
>> > > Next step, look at the core. Try making a kippenhan diagram. Look at
>> what the surface is doing, so try a HR diagram.
>> > >
>> > > Rob
>> > >
>> > > On Mon, 26 Oct 2020 at 15:33, Amedeo Romagnolo <
>> amedeoromagnolo at gmail.com> wrote:
>> > > Hi Rob, you are right, sorry for not showing plots.
>> > > I believe it happens during the red giant phase , but I don't get
>> which kind of problems it might have encountered...
>> > > Here attached the inlists. I tried to keep them as simple as possible.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > Cheers,
>> > >
>> > > Amedeo
>> > >
>> > >
>> > > On Mon, 26 Oct 2020 at 09:48, Rob Farmer <r.j.farmer at uva.nl> wrote:
>> > > Hi,
>> > > It's hard to say what is happening without seeing both your inlists
>> and any plots you have made to show what is going on.
>> > >
>> > > When do you reach the min timestep limit? What is your star doing at
>> this time? Is it at the very start of RLOF? Or is it because your star has
>> encountered problems in the core? Or somewhere else? We can't tell unless
>> you make some plots to explore what is going on.
>> > >
>> > > Rob
>> > >
>> > >
>> > > On Mon, 26 Oct 2020 at 08:24, Amedeo Romagnolo via Mesa-users <
>> mesa-users at lists.mesastar.org> wrote:
>> > > Hi all,
>> > >
>> > > I have a problem when simulating the evolution of a binary system.
>> > > My goal would be to make the more massive star to go into RLOF, which
>> is easily doable when I'm not setting a wide orbital separation (like a
>> period in the order of 10^5 yr). In this case, instead, whatever I do, it
>> seems that the code stops because a too small timestep has been reached,
>> and therefore the star's radius has no time to grow enough to go beyond its
>> Roche Lobe radius.
>> > >
>> > > Do you have any recommendations in this regard?
>> > >
>> > > Additionally, just another small question: is there an output in MESA
>> that shows at the end of the simulation the final total metallicity of the
>> simulated star?
>> > >
>> > > Thanks in advance,
>> > >
>> > > Amedeo
>> > >
>> > >       Virus-free. www.avast.com
>> <https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.avast.com%2F&data=04%7C01%7Cr.j.farmer%40uva.nl%7C281e52f8b7af4c90e1f008d8816d89e6%7Ca0f1cacd618c4403b94576fb3d6874e5%7C1%7C1%7C637401654759357211%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=c4JGKUCVh%2FZYooPtrOvOWMzs4q5F%2B%2Ba5vKr3REDInmQ%3D&reserved=0>
>> > > _______________________________________________
>> > > mesa-users at lists.mesastar.org
>> > > https://lists.mesastar.org/mailman/listinfo/mesa-users
>> <https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mesastar.org%2Fmailman%2Flistinfo%2Fmesa-users&data=04%7C01%7Cr.j.farmer%40uva.nl%7C281e52f8b7af4c90e1f008d8816d89e6%7Ca0f1cacd618c4403b94576fb3d6874e5%7C1%7C1%7C637401654759357211%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nk04oFYIZvmHEi%2F67boLG5RtUUju81cW4YFZqFUgKwE%3D&reserved=0>
>> > >
>> >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20201105/203b268c/attachment.htm>


More information about the Mesa-users mailing list