[mesa-users] mesa problems with the newly added OP opacity tables for a05 and a09 -- the old OP gs98 tables are fine

[Bill Paxton]

Hi,

On Oct 15, 2013, at 10:22 AM, Ehsan Moravveji wrote:
> I notice two patterns ...
> 1. Only OP files are bad; the first set was provided by Radek, and the rest by me
> 2. Only the recent OP files are bad, whereas e.g. GS98 is fine!
> 
> Maybe there has been a recent silent change in the OP server?


Thanks to Ehsan for pointing out a nasty problem in the new mesa tables for a05 and a09 abundances with OP.
The mesa versions of the OPAL tables for these are fine.  But not the OP ones.  However, the older OP tables for gs98 seem to be fine.
It is only the new tables from OP that are causing problems.

First a bit more background.  OP tables are in the same form as the OPAL ones.  OPAL provides routines to read their tables and to pre-smooth and interpolate values.  The tables are so sparse that the choice of pre-smothing and interpolation scheme can change the results you get for sensitive things like asteroseimology.  I learned this the hard way by doing detailed comparisons between mesa and other codes -- it got to the level of detail where by changing mesa until I got a good match for opacities I could figure out what choices the other codes had made in setting up their OPAL software!   Same tables, different choices for pre-smoothing and interpolation produce noticably different brunt N^2 profiles.  Disgusting.  In a perhaps silly attempt to deal with this, I decided to use the OPAL pre-smoothing and interpolation to produce higher resolution tables that I could then use in mesa.  Of course this has nothing to do with improved accuracy; it is just a hack to give interpolated values similar to the interpolated values produced by other codes.  All of that would be okay except it seems that the OPAL software has a few bugs.  I've made several attempts to fix various things, but it still spits out NaN's from time to time.  But at least for the previous input data from both OP and OPAL, the NaN's have been sufficiently rare that we could work around them.   No longer.   Now with the new files from OPAL, we're seeing lots and lots of them.  Enough to screw up many of the mesa kap files.

For example, the mesa kap file a09_z1m1_x35.data has the OPAL version, while OP_a09_z1m1_x35.data has the OP one.   
Those files are created using input data like the following for logKappa at logT=3.75 -- very similar input data.

                                                  log R = logRho - 3*logT + 18
		logT   -8.0   -7.5   -7.0   -6.5   -6.0   -5.5   -5.0   -4.5   -4.0   -3.5   -3.0   -2.5   -2.0   -1.5   -1.0   -0.5    0.0    0.5    1.0
OP		3.75 -0.978 -1.101 -1.274 -1.470 -1.676 -1.882 -2.078 -2.249 -2.372 -2.404 -2.312 -2.107 -1.803 -1.418 -0.967 -0.489 -0.019  0.419  0.810
OPAL		3.75 -0.975 -1.107 -1.278 -1.473 -1.678 -1.883 -2.078 -2.246 -2.359 -2.383 -2.295 -2.102 -1.821 -1.482 -1.043 -0.590 -0.128  0.211  0.561

But when this goes through the OPAL software for pre-smoothing and interpolation in the mesa kap preprocessor, we get good results for the OPAL input and NaN's for OP (the NaN's are written as -1's).
Not all of the OP input is messed up, but a lot of it is -- enough to make the results unusable.

So what do we do about this?  Here are some options.

1) An obvious solution is to stop using the OPAL software for pre-smoothing and interpolation -- just use the data from the input tables, not the software that comes along with the data.  But that will result in small but detectable changes in the existing mesa tables since they have points that were determined by the OPAL software in addition to points from the OPAL or OP tables.

2) Another possible solution is to find and fix the problems in the OPAL software that are giving us NaN's.  If you would like to volunteer, please step forward now!  I'm personally not willing to do this one myself.

3) Or we could continue to use the OPAL software where it seems to work well enough (with the OPAL input data and the older OP data), and switch to a different scheme for the newer OP files such as just using their data as is to create the corresponding mesa files without any pre-smoothing or interpolation.

The 1st option is the most appealing from the standpoint of getting away from depending on software that I can't understand and don't want to have to understand.   BTW: the last time there was a change in the gfortran compiler, it triggered a new set of problems in the OPAL code.  I "fixed" it that time by adding the following lines.  Note that the new lines of code are never executed since dbg is always false -- they "fix" the bug just by being in the source code and thereby changing some uninitialized variable somewhere.   If you are willing to track this down, please go for it.
      
      if (dbg) then
         write(*,1) 'eval_opal_type1 logKap', logKap
      end if


Option 3 might be a better way to go in order to avoid changing existing tables.    That can work at least until a new compiler comes along and we hit new bugs when we need to rebuild kap tables. 


So what do you think?  I haven't decided, but I'm reluctantly leaning toward 3 as the least evil.   But in the meantime, be aware that there are problems in those new OP files.  Sorry, Radek.  ;(

Thanks again to Ehsan for reporting this.

-Bill



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131015/7dbb795b/attachment.html>