[Developers] EOS name parameter in HydroBase
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
> 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
Size: 197 bytes
Desc: not available
Url : http://www.cactuscode.org/pipermail/developers/attachments/20091023/50ec9f93/attachment.bin
More information about the Developers