On Tue, Aug 17, 2010 at 10:27 AM, Frank Loeffler knarf@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

On Tue, Aug 17, 2010 at 12:39 PM, Frank Loeffler knarf@cct.lsu.edu wrote:

On Tue, Aug 17, 2010 at 12:14:56PM -0500, Erik Schnetter wrote:

...

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 agree that we can wait with a decision here, but I don't agree with this argument.

What I have in mind is someone who wants to use a private EOS together with EOS_Omni, without having to maintain a private copy of EOS_Omni himself. I don't think that would be an unreasonable request.

Yes, I understand. I argue that our main effort at the moment should be to make EOS_Omni usable for us, and then see in how far others may need to do their own thing, and then decide how to make this possible. At the moment, everybody can just replace all of EOS_Omni with their own thorn, and this works fine. I would wait with adding an API to EOS_Omni that lets people use part of it (the key mechanism) until we're really using it ourselves, and until we feel that there is an actual need for people in the community to do their own thing.

A registry makes our code more complex, and makes it less likely that others contribute to EOS_Omni since they perceive the registry as the "official" way to add a new EOS. Adding a registry now looks like overdesigning to me.

-erik