[Developers] EOS name parameter in HydroBase

Frank Loeffler knarf at cct.lsu.edu
Fri Oct 23 10:59:37 CDT 2009


On Fri, Oct 23, 2009 at 04:36:34PM +0100, I.Hawke wrote:
> I oscillate between thinking that the EOS should be kept totally 
> separate (so that different EOS interfaces could be developed, all 
> implementing an "EOSBase" like thorn, say one concentrating on 
> efficiency and another on generality, etc., without having to fork 
> HydroBase), and thinking that minimal core info should be kept in 
> HydroBase. At present I'm leaning to the former.

I agree that the EOSBase thorn should not be the same as HydroBase. I
didn't intend to say that.

> > It would be nice to only have one parameter specifying the EOS. If
> > possible, every EOS could then be provided by one thorn, which can use
> > it's own parameters for parameters of the EOS itself.
> Disagree to an extent. I agree there should be a single parameter - 
> let's call it the "Name" of the EOS - that specifies it. However, 
> consider a tabulated EOS and a table reader thorn. You won't want to 
> reinvent the wheel for every table. So one thorn could provide and 
> "Name"'d EOS table in an appropriate sense.

I agree. I don't see a problem with one thorn providing multiple EOSs,
maybe even in a dynamic sense (like generating the name actually from
the table or use an thorn-internal parameter for it).

> For phase transitions or mixtures or just for fun you may want to have 
> the ability to use more than one table (so in general, more than one 
> EOS) in a single simulation.

Ok, then the table-reader thorn could provide that parameter - or a list
of parameters if that functionality will be needed. At this point the
table-reader thorn would provide multiple EOSs, so we should make sure
this works, at least conceptionally.

> > - We could come up with a 'complete' list of variables we (for the
> >   moment) say are 'supported'. Each function would then take all
> >   of them as arguments and might simply ignore some of them. This was
> >   all function declarations would be identical. However, this would
> >   make updating this list a pain.
> >   
> I don't think this can work, as I can think of scenarios where you might 
> want the list of variables to change dynamically inside a simulation.

I was not thinking about the list of variables wich are used in some
simulation but a list of all variables which we might want to 'support'
in whatever simulation in the near future. For example a request for a
value for the pressure would always give rho and eps as arguments, even
is eps would not be used. This way the function declarations would be
clearly defined.

> As all calls should be parsed and checked at the start of the simulation 
> a Warn(0) seems fine to me, and I don't see what a "sensible" default 
> value would be in most cases.

I agree now with the 'default' values. However, when you change an EOS
during evolution, you would have to make sure to recheck all calls then.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://www.cactuscode.org/pipermail/developers/attachments/20091023/50ec9f93/attachment.bin 

More information about the Developers mailing list