[mesa-users] Adding opacities from non-standard sources

[Aaron Dotter]

Hi Warrick,

I've been down this road a few times myself, here are my thoughts:

1. I find it easier to convert opacity files to MESA/kap format directly
(with my own code) rather than hack the kap/preprocessor to do it for you.
The preprocessor code is helpful in telling you the file format.

2. The issue of matching the expected {X,Z} pairs is tricky because it's
hard-coded into the kap module.  I think your approach to copying existing
files, although not ideal, is the best way to proceed.

I've been thinking about item #2, and mentioned the idea to Bill and Frank
that we should replace the hard-coded {X,Z} with a configuration file that
is read in when the kap module is initialized.  Same for the EOS.  I'm
going to work on a prototype in December.

You can use the kap/test code to check your results against existing tables
as a way to verify that you've implemented the new tables.  I'd be happy to
discuss these issue more with you if you like.

Cheers,
Aaron



On Fri, Dec 2, 2016 at 6:23 AM, Warrick Ball <
wball at astro.physik.uni-goettingen.de> wrote:

> Hi,
>
> I'm trying to add a new set of opacities that I've been given (for
> presently-irrelevant purposes) to MESA.  They're in the same format as the
> Ferguson et al. (2005) preprocessor data in wichita/gn93 or gs98 but with
> different coverage in logR, logT and metallicity.  I tried to create my own
> inlist for the preprocessor but I think I ran into some hardcoded
> parameters.  I then used my own Python script which works but only if I
> fudge tables for some metallicities.  Here's what I tried.
>
> I started with $MESA_DIR/kap/preprocessor.  Having noticed that my tables
> are in the same format as the fa05_gn93 tables, I copied that inlist to my
> own new inlist, pointed to a new directory 'kap_input_data/whb' and copied
> my zero-metallicty table to g.0.0.tron, just to get started.  I then
> modified the inlist to match the tables in terms of how many Rs and Ts
> there were (in the latter case by creating a new logT_points file).
>
> I ran the preprocessor with
>
> ./rn_fixed_metals inlist_whb
>
> and got the error
>
> Doing fixed Z = 0.0000
>  read_ferg failed while reading logKs kap_input_data/whb/g.0.0.tron
>  i          14
>  num_logRs          19
>  num_logTs          85
>  logT   3.00000000
> File: ../src/ferguson.f, Line:  195
> ERROR STOP 1
>
> So it's reading the correct file but has the wrong number of logRs.  What
> surprised me is that I specified 23 logRs, not 19; and my logT_points file
> has 71 rows, not 85.  Barreling into the code, I found the 19 hardcoded.
>
> $ grep -n 19 src/*.f
> src/ferguson.f:66:            ferg_num_logRs = 19
>
> Given all that failed, I decided to try my own hand at preparing MESA
> tables...  I had a look at the formats of the files in
> $MESA_DIR/data/kap_data and wrote a Python script to read my tables and
> rewrite them in MESA's format.  This nearly worked, except that there were
> a few tables missing, which I replaced just by interpolating in my existing
> tables.  (e.g. I have tables at Z=0.0002 and 0.001 but not 0.0003)  That
> done, I seem to be able to use the tables in my runs but I haven't yet
> checked that the values coming out of the code are what I expect.
>
> Anyway, to cut a long story short, what's the best course of action?  My
> current solution is unpleasant because of the manual hacking.  Should I
> plough on through the preprocessor to see how to get my non-standard tables
> linked?  Will I be able to do so without the specific metallicities that
> MESA wnats?  Or is there someone inside MESA (rather than the opacity
> preprocessor) that I can tell it which opacities I have?
>
> More files on request.  In this case I'm not really sure what's useful!
>
> Cheers,
> Warrick
>
>
>
> ------------
> Warrick Ball
> Postdoc, Institut für Astrophysik Göttingen
> wball at astro.physik.uni-goettingen.de
> +49 (0) 551 39 5069
> ------------------------------------------------------------
> ------------------
> 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
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20161202/286d6381/attachment.html>