[Users] Meeting minutes

[Frank Loeffler]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20100817/3a3276f2/attachment.bin