[Mesa-users] Surface rotation velocity, num_steps_to_relax_rotation

Wed Apr 12 07:31:48 UTC 2023

Hello Anuj,

--------------------
--The problem--
Your model is evolving too fast during the relaxation procedure.

If you are going to set num_steps_to_relax_rotation to a high value like
1000 or 10000, I would recommend setting a maximum timestep for the
relaxation procedure or else your default timestep controls will take over.
With the inlist you provided, the default is set in
$MESA_DIR/star/defaults/star_job.defaults to 'relax_omega_max_yrs_dt =
1d9'. With 'num_steps_to_relax_rotation = 1000' this yields a star that
evolves to star_age = 9e11 years during the rotation relaxation procedure
because the timesteps slowly increase until dt = max_dt = 1d9 yr. This is
resulting in a model with a larger initial radius and total angular
momentum for a given initial surface rotation velocity set by:
'new_surface_rotation_v
= '#' ! km/s'. This increase in initial total angular momentum is reflected
in a model with a larger surface rotation velocity at ZAMS or ~ 4d7 yrs.

Some minor math:
I = 2/5 * M * R^2 (moment inertia of a sphere) , L =  I*w =  I * (V/R)
 (Angular momentum of a  rigid rotator) ---> L = 2/5 * M * R * V
if L and M are conserved, V = 5/2 * L /M /R---> *V ~ constant/R*
By not limiting the time steps during the relaxation, the 1000+ step models
have a larger initial L, reflected as a larger '*constant*' from the bolded
equation. All this to explain why the overall shape of the evolution path,
V_rot vs star_age, looked similar between all models even though the values
of V_rot were too large at ZAMS or ~4d7 yrs in your plots.

--------------
--The fix --
In &starjob:
Try: 'relax_omega_max_yrs_dt = 1d-5' ! years (or less), if you set it
lower, the agreement should be better. (1d-5 is a good default)

This should solve your issue, and the total angular momentum and radius of
your relaxed models should be almost identical regardless of if you choose '
num_steps_to_relax_rotation' = 100 or 1000.
I've attached a working model directory and a plot generated with your
inlist (with a couple minor tweaks) and 'relax_omega_max_yrs_dt = 1d-5'.

Hope this solves your issue.

-EbF

On Tue, Apr 11, 2023 at 8:36 PM Anuj Gautam <Anuj.Gautam at usq.edu.au> wrote:

> Hi,
>
> Thanks a lot for your response. Very insightful!
>
> I tried increasing num_steps_to_relax_rotation from 100 to higher values.
> However, I am finding that for slow rotators this convergence does not
> happen even for tens of thousands of steps. I have attached two plots
> showing the difference between using num_steps_to_relax_rotation=100 and
> 1000.
> Note: Each line in the plot is for a star initiated with a certain initial
> velocity.
>
> Please guide me. I appreciate all the help.
> Thank you.
>
> Regards,
> Anuj
>
> ------------------------------
> *From:* Ebraheem Farag <ekfarag at asu.edu>
> *Sent:* 11 April 2023 06:07
> *To:* Anuj Gautam <Anuj.Gautam at usq.edu.au>
> *Cc:* mesa-users at lists.mesastar.org <mesa-users at lists.mesastar.org>
> *Subject:* Re: [Mesa-users] Surface rotation velocity,
> num_steps_to_relax_rotation
>
> Hello Anuj,
>
> Relaxation is a numerical procedure. In your case, the equations of
> stellar structure are solved with an initial surface rotation velocity of 0
> km/s after which the velocity variable is slowly increased over '
> num_steps_to_relax_rotation' to 20km/s or 'V_init'. This process allows
> the MESA solver to find a converged initial hydrostatic solution to the
> structure equations for your given initial conditions.
>
> If you set num_steps_to_relax_rotation too low, you risk missing or
> overshooting a stable solution, which can lead to an initial model with a
> different structure and or in your case perhaps a different initial surface
> rotation velocity that is too large or too small.
>
> -EbF
>
> On Mon, Apr 10, 2023 at 5:02 PM Anuj Gautam via Mesa-users <
> mesa-users at lists.mesastar.org> wrote:
>
> Dear MESA devs and users,
>
> I am trying to evolve tracks for uniformly rotating intermediate mass
> (1.3-2 MSun) stars using MESA version r22.11.1.
> I initiate rotation at age = 0, with surface velocities
> (new_surface_rotation_v, call it V_init) in the range 0 to 20 km/s. I am
> observing a "jump" in how the surface velocity evolves with age after a
> particular V_init. This V_init "jump point" varies with the stellar mass
> and metallicity.
>
> Please see the attached plot of surf_avg_v_rot vs. age for a test star of
> 1.4 MSun and initial_z = 0.008. Please also see the corresponding inlist
> attached. (Kindly ignore the haphazard formatting, I am writing the inlists
> with a python automator so all added parameters are dumped at the end of
> each section.)
>
> To initiate rotation, I add the following to the inlist:
>
> change_rotation_flag = .true.
> new_rotation_flag = .true.
> change_initial_rotation_flag = .true.
> set_initial_surface_rotation_v = .true.
> set_surface_rotation_v = .true.
> new_surface_rotation_v = V_init
> relax_initial_surface_rotation_v = .true.
> num_steps_to_relax_rotation = 100
> set_uniform_am_nu_non_rot = .true.
>
>
> If I instead do num_steps_to_relax_rotation<10, I do not see this "jump"
> in surf_avg_v_rot. What could be happening here? Or am I doing something
> wrong?
> What exactly is the purpose of num_steps_to_relax_rotation? It is talked
> about very briefly in the docs...
>
> Any and all help is appreciated.
>
> Kind regards,
> Anuj
>
> __________________________________________________________________
> This email (including any attached files) is confidential and is
> for the intended recipient(s) only. If you received this email by
> mistake, please, as a courtesy, tell the sender, then delete this
> email.
> The views and opinions are the originator's and do not necessarily
> reflect those of the University of Southern Queensland. Although
> all reasonable precautions were taken to ensure that this email
> contained no viruses at the time it was sent we accept no
> liability for any losses arising from its receipt.
> The University of Southern Queensland is a registered provider
> of education with the Australian Government.
> (CRICOS Institution Code QLD 00244B / NSW 02225M, TEQSA PRV12081)
> _______________________________________________
> mesa-users at lists.mesastar.org
>
> https://urldefense.com/v3/__https://lists.mesastar.org/mailman/listinfo/mesa-users__;!!IKRxdwAv5BmarQ!bK-9sonq1npatEik-Cb9tSxf2fLl2wIP1TuFatTR61WLTrJhK4Rmj6tYGFegJmr3UiCIKSKN4zFa36ehnZUdlAZ6$
>
> __________________________________________________________________
> This email (including any attached files) is confidential and is
> for the intended recipient(s) only. If you received this email by
> mistake, please, as a courtesy, tell the sender, then delete this
> email.
> The views and opinions are the originator's and do not necessarily
> reflect those of the University of Southern Queensland. Although
> all reasonable precautions were taken to ensure that this email
> contained no viruses at the time it was sent we accept no
> liability for any losses arising from its receipt.
> The University of Southern Queensland is a registered provider
> of education with the Australian Government.
> (CRICOS Institution Code QLD 00244B / NSW 02225M, TEQSA PRV12081)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20230412/dd47254a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Work_pms_rot_relax.tar.gz
Type: application/x-gzip
Size: 17079 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20230412/dd47254a/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: model_comparison_plot.pdf
Type: application/pdf
Size: 169283 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20230412/dd47254a/attachment.pdf>