[mesa-users] issue with OP AGSS09

[Bill Paxton]

Hi Radek,

If you suspect problems in the mesa opacities, then check the opacities directly in mesa/kap rather than indirectly by looking at the results of using them in mesa/star.   

Hopefully you or Jakub can write a few routines in fortran?   If so, then you might want to start by looking at mesa/kap/test/src/sample_kap.f to get an idea of what to do.  You will want to call the routine kap_get_Type1 in kap_lib with exactly the same T, Rho, and composition arguments for both the OPALgn93 tables and the new OPa09 ones.  Do that for representative cases for the core He burn problem.   Find one or more cases where you think the OPa09 values you get from kap_get_Type1 are bogus.  Then check the OP tables you sent to see what values you find in them for the same T, Rho, and composition --- do the values in the OP tables look okay?  (note: to make this comparison easier, you might want to use some test cases with T, Rho, and composition that exactly match an entry in the OP tables so you don't have to interpolate.) If the values in the OP tables are different than the results returned by kap_get_Type1, then the problem is in the conversion to mesa tables, and you have provided a good test case for me to work on.  If the values in the OP tables are consistent with the dubious values you get from calling kap_get_Type1, then we have a different problem to solve.  But 1st you need to do the work to determine which of these two cases we have to deal with.

Let me know what you find!

Cheers,
Bill

 






On Oct 11, 2013, at 11:30 AM, Radek Smolec wrote:

> Hi,
> 
> I checked the issue with OP a09 reported by Jakub and find the same problems. Using the opacity procedures from the Warsaw-New Jersey code and opacity tables generated for WNJ that I implemented in MESA (as other_kap) I got some hints what might be wrong. Below I report my findings.
> 
> I focused on Z=0.008 and Y=0.23. I attach the inlist for my computations (MESA 5456, sdk, run on a unix cluster). The only things I have changed in this inlist to get different tracks, are mass and opacities.
> 
>  evol_MESAopac_OPALgn93.eps shows the computations with MESA opacities and OPAL gn93. It is for reference only. It seems everything is fine here and tracks look as expected.
> 
> evol_MESAopac_OPa09.eps shows the computations with MESA opacities and OP A09 (kappa_file_prefix = 'OP_a09',  kappa_lowT_prefix = 'lowT_fa05_a09p'). Computations are extremely slow now (and extend to 12 MS only, higher masses are still on the way). There are no loops and the tracks for 10 and 12 solar masses are very erratic at the tip of RGB.
> 
> evol_WNJopac_OPa09.eps - these are computations with MESA opacities replaced by WNJ opacities - both opacity interpolation procedures and opacity tables are from WNJ. It is OP and A09. Now computations extend to 18 solar masses. Except for track for 12Ms (no loop) everything looks fine and similar to the OPAL gn93 case.
> 
> evol_MESAopac_WNJopac_OPa09.eps - in this plot I compare the tracks computed with MESA and WNJ opacities, both for OP and A09. It seems that for main sequence and RGB the agreement is very good. The differences are small and may be attributed to different opacity procedures. But once helium starts burning the huge differences arise.
> 
> Conclusion:
> I think something must be wrong with MESA calculations with OP A09 opacities. I see three possible explanations:
> 
> 1. I did something wrong generating the OP tables. Today Jakub repeated the calculations and we get the same results. OR slightly different results. It turns that it makes a difference to this OP www application if it gets a numbers like 2.44 or 2.440 (0 on a third place). The produced tables are then somewhat different but the differences are very small and likely not play a role here. If we consistently provide the abundances with 2 digits after the comma (no 0 on a third place) we get the same results. 
> 
> 2. OP server did something wrong. I don't know how to check this.
> 
> 2a. Bill, please recall the e-mails I have sent you about differences between OPCD calculations and OP-www calculations. There were differences for extreme cases - low R for which OPCD does not generate output (and some other stuff was put in there by hand in the Warsaw tables) but OP-www does generate output. But there were also differences for (not so high) T  - I attach the comparison file (comparison.ps) once again - see the last two plots. Maybe these differences are responsible for such behaviour and opacities we have in WNJ simply work better? In any case both the stuff put in there in Warsaw/OPCD and in OPwww is not or poorly described.
> 
> 3. Maybe something went wrong during processing the OP tables to MESA format. Can you check this point Bill?
> 
> 4. The suggestion by Bill, I have just read - the effect is real. But then why with WNJ opac and its tables everything goes fine? Maybe the effect is very sensitive to fine details of the opacity procedures/tables.
> 
> Cheers,
> Radek
> 
> 
> 
> 2013/10/11 Jakub Ostrowski <ostrowski at astro.uni.wroc.pl>
> Hi,
> 
> I'd like to point out an unusual behavior that happens with calculations which use the recently implemented OP AGSS09 opacity tables. I calculated models within mass range of 3 - 20 MS and for metallicity between 0.01 and 0.02 and there are problems with every model.
> 
> First of all, with OPAL AGSS09, OPAL GS98 and OP GS98 there is a helium blue loop for every calculated track while for OP AGSS09 there is none for any of them. This behavior itself doesn't necessary mean that something is wrong, but the other thing does: after the core helium abundance drops below about 1% it suddenly rises to about 3% and the energy produce from helium burning increases. Then it repeats itself again for a dozen of times or so. I attached a plot that shows this behavior for 15Ms and Z = 0.01, but this problem exists for every single model I calculated with OP AGSS09.
> 
> I discussed the problem with Radek who provided the tables. He confirmed that the problem is real and I'm sure he will soon provide his ideas.
> 
> My environment: MESA v5456 compiled with SDK on OS X 10.8.5. You can find the attaches inlist. The only things I changed there are opacity tables, mass and metallicity.
> 
> Cheers,
> Jakub
> 
> 
> 
> 
> 
> 
> 
> <inlist_project_OP><evol_WNJopac_OPa09.eps><evol_MESAopac_WNJopac_OPa09.eps><evol_MESAopac_OPALgn93.eps><evol_MESAopac_OPa09.eps><comparison.ps>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131011/173170b5/attachment.html>