[mesa-users] rotation: problem with smooth parameters

[Bill Paxton]

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