[mesa-users] Inlists for a binary simulation

Tue Jun 4 20:56:51 EDT 2013

Hi Pablo,

sorry if I have not been very clear, I just want to check the rotation
velocity variation of the components due to the spin-orbit synchronization
induced by tides. Unfortunately, as I said, if I change in any way the
parameter tidal_Q the simulation stops right at the beginning with this
error:

*bad angular_momentum_j   -2.3489686651008658D+5 *
*stopping because of convergence problems -- too many retries*

Thanks for pointing me to the case synch_spin_to_orbit, probably there the
standard setup will allow me to understand how have tides working in Mesa.

Concerning the inlists, I did not attached them because after your
suggestion I understood that the rotation did not start up since I had to
set differently the parameters than in the cases I run before, now that is
fine and my stars are rotating correctly!

Thank you again for the help Pablo, cheers,

Roberto

On 4 June 2013 20:58, Pablo Marchant <pamarca at gmail.com> wrote:

> Roberto, as I said before, the tides that are included in the rlo_routines
> which are controlled by the tidal_Q parameter do not take rotation into
> account and deal only with the orbital angular momentum of the system, and
> I really don't know how this is supposed to work.
>
> What do you mean by something with a resemblance to "a stable rotating
> star under the effect of tides"? The only effect of tides is to alter the
> rotational velocity of the star in order to synch it to the orbit, you
> don't have any extra modelling on the perturbation to the structure of the
> star via tides, as this is not thought to be important when compared to the
> inherent effects of rotation.
>
> Also might me interesting for you the test case synch_spin_to_orbit, which
> considers a binary with a point mass affected by tides that synch the
> rotation of the donor to the orbital period.
>
> On why your rotation initialization of rotation doesn't work, you still
> didn't upload your inlists, so it's hard to tell.
>
> Cheers!
>
> On Tue, Jun 4, 2013 at 2:44 AM, trobolo dinni <
> trobolo.trobolo.dinni5 at gmail.com> wrote:
>
>> Hi Pablo,
>>
>> sorry if I didn't attach my inlists, I forgot to do that :(
>>
>> I am using the Omega/Omga_crit flag to enable rotation, as I did before
>> with single star models, but it is not working. Anyway with your setup it
>> is working, so it is definitely just an issue of how I configured my
>> rotation flags, I will dig into it!
>> However, if tides are simulated in Mesa, the two object of the binary
>> system should undergo some spin-up also without iniital rotation due to the
>> tides effect, but this is not happening. Can I ask if you know more about
>> this?
>>
>>
>> Thanks for the suggestion Pablo, however I am just using the Mesa models
>> as initial conditions for another code and I don't need to produce a very
>> realistic star, because it is going to lose resolution when I export it. I
>> just need something that resembles a stable rotating star under the effect
>> of tides.
>>
>> Thanks,
>>              Roberto
>>
>>
>>
>> On 3 June 2013 20:24, Pablo Marchant <pamarca at gmail.com> wrote:
>>
>>> Roberto, I'm not sure what's not working for you. How are you setting
>>> the star rotation? I just do this:
>>>
>>> new_rotation_flag = .true.
>>> change_rotation_flag = .true.
>>> set_initial_surface_rotation_v = .true.
>>> new_surface_rotation_v = 200
>>>
>>> in the star_job part of the inlist. If you share your inlists it would
>>> be easier to see what is going on. For me this works on binaries, but of
>>> course, as several rotation-related things are missing it does not make
>>> much sense to deal with rotating stars in my opinion...
>>>
>>> The tidal_Q parameter is something I haven't dealt with and don't
>>> understand that much. It somehow deals with orbital angular momentum loss
>>> due to tides, but I have no idea how that makes sense as it does not take
>>> into account rotational velocities or anything. This is on the function
>>> get_jdot if you want to check, but I guess Bill should know more precisely
>>> what's going on there.
>>>
>>> Cheers!
>>>
>>> On Mon, Jun 3, 2013 at 9:50 AM, trobolo dinni <
>>> trobolo.trobolo.dinni5 at gmail.com> wrote:
>>>
>>>> Hi Pablo,
>>>>
>>>> I have another simple clarification to ask you.
>>>> I would like to follow the rotation velocity of the two components of
>>>> the binary system, however I am plotting the rotation frequency Omega in
>>>> function of the radius but the result is a constant Omega=0.
>>>>
>>>> I think that or no rotation is enabled or I am not following the
>>>> correct parameter in the case of a binary star simulation.
>>>> How could I enable rotation (I saw a tidal_Q parameter, but if I put it
>>>> > 0 the simulation crashes!) or what is the right parameter to plot to
>>>> follow it?
>>>>
>>>> Thanks,
>>>>              Roberto
>>>>
>>>>
>>>>
>>>> On 1 June 2013 02:56, Pablo Marchant <pamarca at gmail.com> wrote:
>>>>
>>>>> I had made this response to this question directly to Roberto, and to
>>>>> another email from him relating to restarting a binary model from photos
>>>>> from individual stellar models. I include it here to mesa-users in case
>>>>> anyone else finds it useful.
>>>>>
>>>>> Cheers!
>>>>>
>>>>> #####################################
>>>>>
>>>>> Roberto,  right now what you want to do is not possible. You can
>>>>> restart a binary run with Photos from a binary run,  but not with those of
>>>>> single stellar evolution. This is because extra orbital data is stored as
>>>>> extra parameters in the donor, and on top of that,  the code would not
>>>>> respond properly to receiving two models with different ages. I would
>>>>> expect the same thing to happen if you used two models saved via inlist.
>>>>>
>>>>> You had also asked for an explanation on the use of inlist
>>>>> parameters,  but for now there is no comprehensive default inlist with
>>>>> explanation of the parameters.  If you have doubts about the use of any,
>>>>> you can ask individually or check the sources for binary evolution,  which
>>>>> are not too large.
>>>>>
>>>>> And of course,  if you would like to contribute some fixes for any of
>>>>> these things they would be welcome.
>>>>>
>>>>> Cheers
>>>>>
>>>>> ###################################
>>>>>
>>>>> On Thu, May 30, 2013 at 3:38 AM, trobolo dinni <
>>>>> trobolo.trobolo.dinni5 at gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I would like to ask if there is any place where I can find an
>>>>>> explanations of the controls for the *&binary_rlo_job* and *
>>>>>> &rlo_exp_job* control sections (like those present in
>>>>>> /mesa/star/defaults for *&star_job*, etc), since I can understand
>>>>>> just in part what is the functions of the parameters available.
>>>>>>
>>>>>> Thanks,
>>>>>>                    Roberto
>>>>>>
>>>>>>
>>>>>> On 27 May 2013 21:33, Pablo Marchant <pamarca at gmail.com> wrote:
>>>>>>
>>>>>>> yes, otherwise it will crash due to an I/O error
>>>>>>>
>>>>>>>
>>>>>>> On Mon, May 27, 2013 at 11:05 AM, trobolo dinni <
>>>>>>> trobolo.trobolo.dinni5 at gmail.com> wrote:
>>>>>>>
>>>>>>>> Thank you very much Pablo, hence Mesa expects to find a file with
>>>>>>>> that name in the directory I guess?
>>>>>>>>
>>>>>>>> Roberto
>>>>>>>>
>>>>>>>>
>>>>>>>> On 27 May 2013 18:08, Pablo Marchant <pamarca at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Roberto, the file inlist_rlo is loaded directly by the subroutine
>>>>>>>>> rlo_controls, which you can find in star/binary_systems/rlo_routines.inc
>>>>>>>>>
>>>>>>>>> Cheers!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, May 27, 2013 at 9:48 AM, trobolo dinni <
>>>>>>>>> trobolo.trobolo.dinni5 at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Dear Mesa users,
>>>>>>>>>>
>>>>>>>>>> I would like to run some binary roche lobe overflow simulations
>>>>>>>>>> with Mesa, so I started trying to understand how to setup the various
>>>>>>>>>> inlists taking as example the binary_rlo setup in the test suite.
>>>>>>>>>> Now, I can see that the files:
>>>>>>>>>>
>>>>>>>>>> *inlist*
>>>>>>>>>> *
>>>>>>>>>> *
>>>>>>>>>> *inlist_binary_rlo*
>>>>>>>>>> *
>>>>>>>>>> *
>>>>>>>>>> *inlist1 *
>>>>>>>>>> *
>>>>>>>>>> *
>>>>>>>>>> *inlist2*
>>>>>>>>>>
>>>>>>>>>> are linked together, but the file
>>>>>>>>>>
>>>>>>>>>> *inlist_rlo*
>>>>>>>>>> *
>>>>>>>>>> *
>>>>>>>>>> is not included in anyone of the previous.
>>>>>>>>>>
>>>>>>>>>> I would like then to ask how Mesa knows that it has to read it.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>                Roberto
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Try New Relic Now & We'll Send You this Cool Shirt
>>>>>>>>>> New Relic is the only SaaS-based application performance
>>>>>>>>>> monitoring service
>>>>>>>>>> that delivers powerful full stack analytics. Optimize and monitor
>>>>>>>>>> your
>>>>>>>>>> browser, app, & servers with just a few lines of code. Try New
>>>>>>>>>> Relic
>>>>>>>>>> and get this awesome Nerd Life shirt!
>>>>>>>>>> http://p.sf.net/sfu/newrelic_d2d_may
>>>>>>>>>> _______________________________________________
>>>>>>>>>> mesa-users mailing list
>>>>>>>>>> mesa-users at lists.sourceforge.net
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Pablo Marchant Campos
>>>>>>>>> M.Sc on Astrophysics, Universidad Católica de Chile
>>>>>>>>> PhD student, Argelander-Institut für Astronomie
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Pablo Marchant Campos
>>>>>>> M.Sc on Astrophysics, Universidad Católica de Chile
>>>>>>> PhD student, Argelander-Institut für Astronomie
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Pablo Marchant Campos
>>>>> M.Sc on Astrophysics, Universidad Católica de Chile
>>>>> PhD student, Argelander-Institut für Astronomie
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Pablo Marchant Campos
>>> M.Sc on Astrophysics, Universidad Católica de Chile
>>> PhD student, Argelander-Institut für Astronomie
>>>
>>
>>
>
>
> --
> Pablo Marchant Campos
> M.Sc on Astrophysics, Universidad Católica de Chile
> PhD student, Argelander-Institut für Astronomie
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20130605/bf8a3bad/attachment.html>