Hi,
On Mon, Aug 16, 2010 at 01:00:23PM -0400, Roland Haas wrote:
** Frank has added some code to GRHydro to make progress towards using EOS_Onmi only
I committed all the changes necessary to use GRHydro without the usual EOS* thorns, but only using EOS_Omni. I didn't change the ccl files though because #defines don't have an effect there, but the 'new' versions have been commited as NAME.ccl.omni.
I use this to adapt the testsuite parameter files of GRHydro and TOVSolver to use EOS_Omni and all of them passed (on my workstation).
If we are going to stick to EOSs which are implemented in EOS_Omni we should be able to make the switch now. I do expect a few changes in other thorns as well, but given that the current switch wasn't all that hard, I don't expect big problems.
Before we switch anything, Christian should commit the 'new' API version and change all calls correspondingly.
Something which hasn't gotten much attention yet is that the switch to EOS_Omni makes it harder for someone to write an independent EOS thorn, extending EOS_Omni. With the current setup the best way to implement a new, and potentially private EOS would be to fork EOS_Omni and directly implement it. Of course, any changes to the 'official' EOS_Omni version would have to be merged every time by hand to keep sync.
One way of making this easier would be have a simple function-registry in EOS_Base, registering replacements of all the API calls with either their pointer (or, since Fortran seems to be limited in that respect) maybe using Cactus-aliased functions (just an idea - might not work or not be efficient).
EOS_Omni could then check if, for eos_keys which it doesn't know, functions have been registered and simply act as pass-through. Using this approach should not affect the EOSs in EOS_Omni in any way, performance-wise.
Are there other, better ideas?
Frank