[Mesa-users] other_torque subroutine computed twice

[Saldana-Munoz, Miriam Rosario (9830xxx)]

Thanks, that's really helpful.


I have been saving my variables at the end of my_other_torque subroutine, but it makes sense to use extras_finish_step or perhaps extras_start_step in order to compute and store dMrad/dt, and some other variables which I would need to be unchanged between the two instances of my_other_torque.

?

Cheers,

Miriam


________________________________
Von: Pablo Marchant <pamarca at gmail.com>
Gesendet: Donnerstag, 26. November 2020 15:47
An: Saldana-Munoz, Miriam Rosario (9830xxx)
Cc: mesa-users at lists.mesastar.org; Razinkov, Andriy Vasylhovych (1313xxx)
Betreff: Re: [Mesa-users] other_torque subroutine computed twice

Setting premix_omega to .false. means angular momentum transport will be done before the newton solver, so it might not solve your problem. One alternative you could do is just multiply your jdot by 2 (just a hack), or compute at the end of the step (in extras_finish_step) the value of dMrad/dt and use that in the following step. You can do that by storing it in the xtra variables, for instance "s% xtra(1) = expression for dMrad/dt" in extras_finish_step, and then just accessing s% xtra(1) in your torque subroutine.

Cheers

On Thu, Nov 26, 2020 at 3:35 PM Saldana-Munoz, Miriam Rosario (9830xxx) <miriam.saldana-munoz at edu.uni-graz.at<mailto:miriam.saldana-munoz at edu.uni-graz.at>> wrote:

Thank you Pablo,


I had a real problem applying a torque which includes dMrad/dt (i.e. the mass variation of the radiation shell during a time step), by computing the difference between the actual Mrad and the last saved Mrad_old. Therefore, the second time, my_other_torque gave always the result 0 for this difference.


But now if extra_jdot is not computed the second time because the inclusion of the if statement, extra_jodot would be transported only for half of the time and the results could not be valid either. In this case, would it be a good idea to set premix_omega to false?


Cheers,

Miriam

________________________________
Von: Pablo Marchant <pamarca at gmail.com<mailto:pamarca at gmail.com>>
Gesendet: Donnerstag, 26. November 2020 14:45
An: Saldana-Munoz, Miriam Rosario (9830xxx)
Cc: mesa-users at lists.mesastar.org<mailto:mesa-users at lists.mesastar.org>; Razinkov, Andriy Vasylhovych (1313xxx)
Betreff: Re: [Mesa-users] other_torque subroutine computed twice

Hi Miriam,

this behavior is normal. Angular momentum transport is split from the general newton solver for the rest of the structure equations. By default, it is split such that mixing is computed for dt/2 before the newton solver, and dt/2 after the newton solver. This is the reason why you see two calls each step. Being more specific, this behavior is controlled by the option premix_omega, which is true by default.

Cheers

On Thu, Nov 26, 2020 at 2:36 PM Saldana-Munoz, Miriam Rosario (9830xxx) <miriam.saldana-munoz at edu.uni-graz.at<mailto:miriam.saldana-munoz at edu.uni-graz.at>> wrote:

Dear mesa-users,


I have developed my own other-torque subroutine. The running was successful but as the results were not convincing I did some debugging. I have realised that MESA computes my_other_torque twice for every model_number.


The problem is already solved by introducing an if statement, but I would like to know if this kind of behaviour is normal (version MESA ?12778)


Thank you very much in advance.


Miriam

_______________________________________________
mesa-users at lists.mesastar.org<mailto: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


--
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/20201126/0c955f7c/attachment.htm>