[mesa-users] mesa release 3372

[Bill Paxton]

Hi,

I've added a few things and (hopefully) fixed a few others.  Of course that means I've probably broken a few things too, but I count on you to let me know!


One small change that might have an impact on you is the new default to deal with bad mass fractions more severely.  Turns out that the newton solver in star doesn't explicitly constrain mass fractions to be in the range 0 to 1 and to add to 1.  We have to enforce that as a separate operation.  In the past, we just cleaned things up and continued (the cleanup is to truncate values to be in the range 0 to 1 and then renormalize so that they sum to 1).   Now we cleanup if things aren't too bad, but we reject the step and force a retry if they are.   The meaning of "too bad" is given by these new controls:
         
         min_xa_hard_limit = -1d-6 
            ! if solver produces mass fraction < this limit, then reject the trial solution
         sum_xa_tolerance = 1d-6
            ! if solver gives solution with abs(sum(X) - 1) > this, then reject and retry.

During evolution you might now see terminal messages saying "bad_X_sum" or "neg_mass_frac".
And you might even get more accurate results!



For those of you who use Python or just want to try a GUI for mesa/star, Kent Budge has provided a nifty one.  
Check out star/test/gui.py and guic.py.   Please give it a try and let Kent know what you think.     kgbudge at lanl.gov



There are cases where you might want to get extremely fine resolution near the surface.  To help you with this,
there is a new "relax" operation, relax_max_surf_dq.   I've been able to get surface dq's down to 10^-21 this way.
The remesh limit on size changes for adjacent cells ensures that there are a bunch of small dq's near the surface.
It is even okay to make the max_surf_dq << min_dq -- the remesh code will make small cells near the surface to satisfy the max_surf_dq even if that means making them smaller than the normal min_dq.



The application that motivated relax_max_surf_dq stuff is WD asterseimology.
That application has also led to the addition of the ability to add an atmosphere model for the FGONG or OSC output.
Here are the new comments from run_star_defaults:

      ! you can create an atmosphere for use with pulsation codes.
      ! inspired by B. Paczynski, 1969, Acta Astr., vol. 19, 1.
      ! takes into account dilution of luminosity when tau < 2/3,
      ! and calls mlt to get gradT allowing for convection.
      ! you should use the Henyey option for mlt when adding an atmosphere.
      add_atmosphere_for_fgong = .false.
      add_atmosphere_for_osc = .false.

The added atmosphere can include convective regions.  To make that work, mlt now is given optical depth as another argument.
When tau < 2/3, it will now modify grad_rad for dilution following Paczynski, 1969, Acta Astr., vol. 19, 1., eqn 14
BTW: a big thank you to Agnes Kim and Mike Montgomery for helping with the effort to get mesa able to make state-of-the-art models for doing white dwarf asteroseismology -- we're not quite there yet, but we are making progress.   I'm also working with Jim MacDonald on improvements to the mesa diffusion module, so stay tuned for that.  ;-)



Recall that the "surface" of a model is defined to be the outer boundary of the outermost cell.  This means that unless you happen to have a surface boundary condition that places that outer boundary at the photosphere, T_surface will not be the same as T_effective.   The controls for when to stop a run need to provide limits for both -- and now they do.  The old controls for logTeff limits have been changed to logTsurf limits, and new controls for Teff upper and lower limits have been added.



Alexander Heger suggested we add the ability to stop a run more gracefully than by doing a CTRL-c --- what a good idea!
Here's the new &star_job control:

         stop_if_this_file_exists = ''
            ! at each step, the code will try to open this file
            ! if the file exists, it will terminate the run
            ! if the file doesn't exist, it will keep going.



There have also been some changes to the physics input modules, but hopefully nothing that you'll notice unless you call them directly.
For example, we've cleaned up the interface for the screen module so that Falk can use it with NuGrid.



Finally, I found and fixed a bug that was preventing the equation evaluation task in star from taking advantage of multi-cores.  Not a big change, but every bit helps.


Speaking of performance issues, when using a net with more than 20 isotopes or so, the time spent doing matrix algebra starts to be significant.  We currently aren't getting any help for this from multi-cores.   In theory the ifort MKL package should support multithreading for matrix algebra, but I haven't been able to get it to provide any improvement.  Perhaps I'm just not setting things up properly.  Let me know if you can figure that one out.   I've also tried to install ATLAS on my mac, but it also failed to give any improvement.  


As usual, expect bugs and let me know as soon as you find them.


Cheers,
Bill