search

MESAHub / mesa

Modules for Experiments in Stellar Astrophysics
http://docs.mesastar.org
GNU Lesser General Public License v2.1
136 stars 37 forks source link

Revisit supported set of kap tables #110

Open jschwab opened 3 years ago

jschwab commented 3 years ago

As part of ensuring that different kap handles can use different opacity tables (so for example, so two stars in a binary can each used different tables), MESA/kap had to know about the possible set of tables that it can use. At present, that means that we manually list the available tables in kap_def. The tables included there were based on what were listed as options in the docs. This is a subset of tables that are actually shipped with MESA. For example, none of the alpha-varying kap tables are explicitly listed. However, one can still use these tables by treating them as user-provided tables. There's still a limitation though, as we only provide one slot for user-provided tables, so one can't currently have two stars with different user-provided custom tables.

The current framework may seem like overkill given that the tables that we ship are all so similar, but the idea was to make it easier to incorporate new tables from OP and/or OPAL.

In the future, likely as part of incorporating new kinds of tables (e.g., #85), we should revisit the kap storage design and the set of tables that we ship with MESA. Seems cleanest if we ship a small set of tables with simple and robust procedures for users to use custom tables. (If we do want to ship larger sets of similar tables, it might be worth redesigning to separate the file prefix and the table format.)

aarondotter commented 3 years ago

I don't understand the logic behind the explicit listing of different tables in kap_def. This goes against the original design of the kap module and I welcome someone to explain why this is so.

I agree that we do not need to ship so many different options: for example the alpha-enhanced GS98 mixtures are from my PhD thesis and I would be surprised if more than 1% of mesa-users has ever used them. I think the impetus to remove them has always been slowed by the notion that is (a) a small fraction of the download and (b) there is no "mesa-data" repository for storing such things.

As long as we keep the kap/preprocessor (in some form) alive, I don't see either of these as reasons why we should not cull the current set.

jschwab commented 3 years ago

I don't understand the logic behind the explicit listing of different tables in kap_def. This goes against the original design of the kap module and I welcome someone to explain why this is so.

The original design of the kap module did not allow for different kap handles to use different opacity tables. This is because the table storage is at the module level and not the handle level. For example, if you tried to use two different kap tables (one per star) in a binary, bad things happened (#38).

As a simple fix (see r13317), Bill left the storage at the module level, but created a slot for each opacity table. Different tables per handle are allowed because the handle stores which slot to look at. That approach also has the advantage that in the typical case of loading the same kap tables in multiple handles, you share the data between them and so only load/store it once. (That's nice to have, but probably not a critical feature of a design as kap tables are small enough that is not a significant practical consideration.)

rjfarmer commented 3 years ago

As long as we keep the kap/preprocessor (in some form) alive, I don't see either of these as reasons why we should not cull the current set.

Does the preprocessor have some easy to use scripts that could be used to remake the data? i.e instead of shipping the data we ship a script that would remake it for the user?

aarondotter commented 3 years ago

Does the preprocessor have some easy to use scripts that could be used to remake the data? i.e instead of shipping the data we ship a script that would remake it for the user?

Yes, it does.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MESAHub/mesa/issues/110#issuecomment-735863884, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYW4L5DEPOXJPM2PMJORBTSSO4HTANCNFSM4UFLJMRQ .