[Users] Meeting minutes

[Erik Schnetter]

On Tue, Aug 17, 2010 at 10:27 AM, Frank Loeffler <knarf at cct.lsu.edu> wrote:
> 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?

The question I have is whether EOS_Omni is offering functionality that
goes beyond just providing equations of state. If not, then there is
not much harm in people writing their own EOS thorns and using these.
If EOS_Omni does provide more functionality, such as e.g. automated
switching between EOS or offering a generic table reader or
interpolator, then one can think about make these available
independently.

In the short term, adding new EOS to thorn EOS_Omni seems feasible. In
the Einstein Toolkit, there should be some cohesion between the EOS we
offer; they should complement each other and work together nicely,
whatever that means in practice. Offering a generic registry allows
people to bypass the process of discussing on the mailing list, and
instead they can do "their own thing". I think EOS_Omni is too young
for that: if people need to do something completely different and
bypass EOS_Omni, then there is something wrong with EOS_Omni. I'd wait
and see what happens, and think about this again in six months or a
year.

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/