[mesa-users] rotation: problem with smooth parameters
Matteo Cantiello
cantiel at kitp.ucsb.edu
Thu Jan 24 18:07:27 EST 2013
Hi Radek and all,
yes, the models in the second MESA instrument papers have been calculated without using any spatial smoothing.
! space smoothing
smooth_D_DSI = 0
smooth_D_SH = 0
smooth_D_SSI = 0
smooth_D_ES = 0
smooth_D_GSF = 0
smooth_D_ST = 0
smooth_nu_ST = 0
However, as Bill mentioned, we adopted time smoothing
! time smoothing -- fraction of previous to mix with new to get next
angsmt = 0.2
angsml = 1d-3
I guess this is the price to pay for 1D and finite resolution.
However not all is lost: ideally calibration of the efficiency of mixing and angular momentum transport (as influenced by a certain number of parameters in the models, including the smoothing)
can be performed using observations. For example surface abundances in rotating (massive) stars can help in this direction (see e.g. the ongoing work of the VLT FLAMES (Tarantula) Survey).
Asteroseismology is the new player, and given the amazing results provided by the KEPLER and CoRoT satellites (e.g. for the red giants), it promises to shed some light on the complex physics of stellar interiors.
So, why I understand the discomfort in using a tool that shows so clearly its limitations, I would like people to appreciate the value of what you have in your hands.
- First it allows you to realize where the problems in our understanding are, instead of just having you to push a button and get a result.
- Second, as more and more observations are collected, you can now contribute substantially to the progress of stellar evolution.
As the parameter space is large, to get the physics and its calibration right we need a lot of data (coming in. Check), a versatile open source tool providing reproducibility (MESA. Check) and finally a large user-base. And that's you.
So I think we are in business.
-M
On Jan 24, 2013, at 2:30 PM, Bill Paxton wrote:
> Hi Radek,
>
> We should check with Matteo on this, but I think it may be possible to
> turn off the spatial smoothing --- i.e., just leave those parameters = 0.
> If it works without spatial smoothing, then I don't feel so bad that turning
> it on has a large effect!
>
> But there is still the question of time smoothing. ;-(
> The controls for this are given the same names as in the Langer code
> ! time smoothing of secular terms
> angsmt = 0.20 ! set this to 0 to turn off time smoothing
> angsml = 1d-3
> You should look at rotation_mix_info.f to see how they are used.
> The basic idea is to use a mix of the old diffusion coeff plus the
> newly calculated one as the actual value. This smoothing
> seems to help with averaging out the rapid changes that happen
> in with rotationally induced smoothing. So you might want
> to check to see if different values for this have significant effects.
> And of course, see if you can get away without time smoothing.
>
> Good luck!
>
> -Bill
>
>
>
>
>
> On Jan 24, 2013, at 2:22 PM, Radek Smolec wrote:
>
>> Hi Bill,
>>
>> Thanks for your explanations. The sensitivity of the tracks to the
>> smooth parameters is indeed distressing. The effects of rotation mimic
>> that of overshooting and shift the tracks towards higher luminosities.
>> But in the case of overshooting the effect is at least rather well
>> parametrised either with standard or with diffusion prescription. With
>> rotation it might be a nightmare as it seems that several parameters
>> seem to affect the results strongly (e.g. luminosity at the crossing
>> of the instability strip).
>>
>> I will continue the parameter survey and will also try to increase the
>> model resolution (so far I used mesh_delta_coeff = 0.5). I will let
>> you know if I find something interesting.
>>
>> If someone played with the smooth and other rotation parameters I will
>> be happy to hear your comments/advice.
>> Cheers,
>> Radek
>>
>>
>> 2013/1/24 Bill Paxton <paxton at kitp.ucsb.edu>:
>>> Hi Radek,
>>>
>>> Sorry for the slow response -- my cold/sinus infection is now starting to recede thanks to anitbiotics,
>>> but I'm still not completely functional; so expect even more mistakes than usual in what I say!
>>>
>>> I'm afraid that the distressingly large effect of changing the smoothing parameters is not just
>>> a programming bug or a user error. It would be wonderful if someone with more experience
>>> would explain to me that I'm wrong about this.
>>>
>>> So, rotational diffusion coefficients + smoothing -- here we go.
>>>
>>> Let's start with a description of what the smoothing does. Here are the control parameters
>>> from the file star/defaults/controls.defaults
>>>
>>> ! spatial smoothing is used in calculations of diffusion coefficients
>>> ! these control the smoothing window widths (number of cells on each side)
>>> smooth_D_DSI = 0
>>> smooth_D_SH = 0
>>> smooth_D_SSI = 0
>>> smooth_D_ES = 0
>>> smooth_D_GSF = 0
>>> smooth_D_ST = 0
>>> smooth_nu_ST = 0
>>>
>>> As usual, grep is the key to finding what they do.
>>>
>>> cd star/private
>>> grep smooth_D_DSI *
>>> ctrls_io.f: smooth_D_DSI, &
>>> ctrls_io.f: s% smooth_D_DSI = smooth_D_DSI
>>> ctrls_io.f: smooth_D_DSI = s% smooth_D_DSI
>>> rotation_mix_info.f: call smooth_for_rotation(s% D_DSI, s% smooth_D_DSI, p_tmp)
>>>
>>> The "ctrls_io" instances are where it is declared as a parameter.
>>> It is the "rotation_mix_info" instance we want. So open that file and search for "smooth_D_DSI".
>>> It is passed to the routine "smooth_for_rotation", so let's check to see what that does.
>>> That routine just passes things along to a routine called "weighed_smoothing" that is in "star_utils".
>>> So open star_utils.f and find "weighed_smoothing". It starts with a comment saying that it is
>>> based on a routine by S.-C. Yoon --- turns out that like most of the rotation routines in MESA,
>>> this one is derived from the evolution code of Norbert Langer's group; Sung-Chul has made
>>> many of the recent improvements in that code, and they've "trickled down" into mesa.
>>> If you look at the details of "weighed_smoothing" you'll see that it combines values from
>>> 2*ns + 1cells (ns on either side of the center cell). The weights decline as the distance from the
>>> center increases, so it is a sort of discrete approximation to a bell-curve. The "ns" argument
>>> that sets the window size in cells is given in our current case by the smooth_D_DSI control.
>>> So if that control is 0, there is no smoothing, if it is 2 then the smoothing uses 2 cells on each side, etc.
>>>
>>> Why smoothing? Well, the simple answer is that it is in MESA because it is in the Langer code,
>>> and I copied it. The slightly less simple answer is that it is there because it seems to be needed.
>>> At least in some cases. The rotational smoothing coefficient values are sensitive to things like
>>> rotational shear. And that shear is calculated by doing numerical differences -- e.g. to get domega/dr,
>>> we divide the difference between 2 adjacent (and almost equal) omegas by the difference
>>> between 2 adjacent (and almost equal) r's. This is a recipe for injecting high frequency noise.
>>> The smoothing is an attempt to remove some of that noise. In a perfect world of infinite resolution,
>>> none of this nonsense would be necessary. But the resolution is finite and some nonsense seems
>>> to be required. But how much? What is the "right" value for the smoothing? For that matter,
>>> what is the right algorithm for smoothing? should it be by cells (non-physical, but reflect resolution)
>>> or by radial distance? I have no good answers to any of these questions.
>>>
>>> And now we get to the really bad news --- namely that the answers to these unanswered
>>> questions make a difference, a big difference! You've given a few examples; there are certainly more.
>>>
>>> What happens next is up to you -- it seems you can either pick a set of smoothing parameters and
>>> hold them fixed while you change other, physical, things; or you can hold the physical parameters
>>> fixed and vary the smoothing parameters to determine the sensitivity of the results. Or you can
>>> go off and discover a better way to do all of this that doesn't need smoothing!
>>>
>>> To maximize paper output, the 1st approach is probably best: pick parameter values and run with 'em.
>>> But the sensitivity study might give interesting insights and help clarify the current situation.
>>> Perhaps you'll discover that the effects of the settings for smoothing become less and less as you
>>> increase the spatial resolution of the models -- that would be nice.
>>>
>>> I hope that my ranting here will provoke someone with real understanding to speak up.
>>>
>>> Cheers,
>>> Bill
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Jan 16, 2013, at 3:51 AM, Radek Smolec wrote:
>>>
>>>> Hi again,
>>>>
>>>> I studied the effects of rotation on the computed tracks. I focus on the evolution of 7M_S star with Z=0.004 from the ZAMS till the depletion of helium in the core. The surface rotation at ZAMS was set to 200 km/s. To check the sensitivity of the results on the rotation parameters I played with the smoothing parameters and got significantly different results, which was a surprise for me. I played both with mesa 4631 with dq_smooth_* parameters and with the current version of MESA (4740) where averaging of the diffusion coefficients is done over adjacent zones (smooth_D* parameters) rather than over a mass range (dq_smooth_* parameters). In both cases I got the same problems and here describe the calculations with MESA 4740. As you can see in the attached figure (evol.rotALL.eps) the tracks are very different even for small change of the smooth* parameters (also there are small problems with smoothness of the tracks at the beginning which you may see in the zoom-in). As I
> understand these smooth_D_* parameters have both 'numerical' and 'physical' meaning, i.e. proper values help the convergence and allow to produce smooth tracks ('numerical') but also change the diffusion law, which is uncertain ('physical'). Am I right? But I expected a rather small effect on the computed tracks, which is not the case. To investigate the effect further I turned off all the diffusion coefficients, except the one for Eddington-Sweet circulation and played with smooth_D_ES - the result is presented in evol.rotES.eps. Again the difference is very large even between smooth_D_ES=0 (no averaging) and smooth_D_ES=1.
>>>>
>>>> I attach the inlist I used in the computations. For particular tracks I changed the D_*_factor parameters (either all to 1 or only D_ES_factor=1 and all other 0) and smooth_D_* parameters as indicated in the Figures. Note that overshooting is turned off in these models (but I also allowed for small overshoot from the h-burning core and got qualitatively the same results). I run MESA 4740 installed with SDK on Ubuntu.
>>>>
>>>> Can someone check whether the settings I use for rotation are OK and comment on these results (in particular on the meaning of smooth_D parameters and how to set them reliably)?
>>>> Thanks in advance,
>>>> Radek
>>>> <evol.rotALL.eps><evol.rotES.eps><inlist_project_rot>------------------------------------------------------------------------------
>>>> Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
>>>> and much more. Keep your Java skills current with LearnJavaNow -
>>>> 200+ hours of step-by-step video tutorials by Java experts.
>>>> SALE $49.99 this month only -- learn more at:
>>>> http://p.sf.net/sfu/learnmore_122612 _______________________________________________
>>>> mesa-users mailing list
>>>> mesa-users at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnnow-d2d
> _______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users
Dr. Matteo Cantiello ------------------------
Kavli Institute for Theoretical Physics
Room 2411 Kohn Hall CA 93106-4030
University of California, Santa Barbara
---------------- http://matteocantiello.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20130124/ae686ec6/attachment.html>
More information about the Mesa-users
mailing list