[mesa-users] Bug report? GYRE file header has incorrect number of columns
RICHARD H D TOWNSEND
townsend at astro.wisc.edu
Mon Apr 3 13:31:59 EDT 2017
Hi Warrick —
Thanks for your detailed report. In this case, its a big “mea culpa”.
The latest version of MESA (r9575) is behaving quite correctly, in that it is writing out stellar models in an updated version (v1.00) of the GYRE format. In this updated format, the integer at the end of the header line now indicates the version number divided by 100, and not the number of columns. Version 1.00 differs from the previous version (v0.19) in that it allows double points to represent density discontinuities, plus the interpretation of the opacity derivatives in columns 14 and 15 has changed (see the attached document).
The reason why you’re running into difficulty with GYRE is that the version (4.4) which shipped with MESA r9575 is rather old, and cannot properly handle v1.00-format model files. The fix is to upgrade to the latet version of GYRE, which is 5.0rc1. If you just edit the model file to change 100 to 19, that will cause problems in non-adiabatic calculations due to the change in the opacity derivative interpretation.
I’m hoping to get a more up-to-date version of GYRE into MESA for the next release.
> On Apr 3, 2017, at 1:45 AM, Warrick Ball <wball at bison.ph.bham.ac.uk> wrote:
> I'm not sure if I'm misusing something but I tried to use GYRE's non-adiabatic binary to calculate the mode frequencies for a GYRE-format file from MESA and ran into an error. I've attached an inlist for r9575 that I used to produce the attached GYRE input file (`inlist_project`), the GYRE-format stellar model file (`test.gyre`), and the GYRE inlist that I used to compute frequencies (`gyre_nad.in`, basically just a copy of $GYRE_DIR/test/nad/mesa/spb/gyre_nad.in).
> Using the version of GYRE distributed with MESA (i.e. I have GYRE_DIR=$MESA_DIR/gyre/gyre, which I presume is okay?), I tried to compute the mode frequencies with `gyre_nad gyre_nad.in` and got the error:
> Reading from MESA file test.gyre
> Detected new-variant file
> ASSERT 'k == k_chk' failed at line 303 <gyre_mesa_file:read_mesa_data:read_mesa_data_new_>:
> Index mismatch
> at which point the calculation halts. I followed the error message in GYRE and I think the problem is that the last integer in the first row of the GYRE file should be the number of columns (also, it's in the docs ). But in the file produced by MESA, I have
> 1046 2.9837999999999999E+34 3.5101730384066974E+11 6.9329640876084185E+37 100
> Looking at the file, there are clearly not 100 columns, and if I change the last 100 to the correct number of columns (19), the calculation proceeds.
> So, using my standard MESA sleuthing methods (i.e. grep a relevant control and start following function calls), I found the the GYRE data is written by write_gyre_data in $MESA_DIR/star/private/pulse_gyre.f90:397-451. In particular, the subroutine writes the first line of the GYRE file on line 434 in the code:
> write(iounit, 100) nn, global_data, 100
> So I think the bug is that hardcoded 100. I'm not so familiar with standard Fortran operations but I would guess that the 100 should be replaced with `SIZE(point_data, 1)+1`. (The extra column is the row number, which isn't in `point_data`.)
>  $GYRE_DIR/doc/mesa-format.pdf
> Warrick Ball
> Postdoc, School of Physics and Astronomy
> University of Birmingham, Edgbaston, Birmingham B15 2TT
> wball at bison.ph.bham.ac.uk
> +44 (0)121 414 4552<inlist_project.txt><test.gyre><gyre_nad.in>------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 85067 bytes
More information about the Mesa-users