[Developers] HydroBase infrastructure

I.Hawke i.hawke at soton.ac.uk
Mon Nov 10 11:58:37 CST 2008

Frank Loeffler wrote:
> However, some groups should be scheduled in relation to MoL groups. I
> assume that most codes use MoL and even if some are not, they do not
> have to schedule something in those groups and schedule things
> themselfes - or we can then see how to unify this once such a code wants
> to use HydroBase.
Indeed - the schedule parts are harmless.
>> - I would recommend making the velocity a vector grid function vel(3)
>> instead of vel[xyz] to simplify operations.
> It really would and we thought about that. We decided against it because
> it would require too many changes in existing thorns, e.g. Whisky.
> On the other hand I agree that this would be a good idea. I hope that
> some other Whisky developers than us two agree to change Whisky in that
> way. If not, I would rather see a "moderately good" version of HydroBase
> which is used than a really nice one, but which is not used (by Whisky
> in this case).
> Having written that: I think some #defines might do the trick rather
> easily for Whisky.
If there is any chance of it happening then it should go in from the 
start, or that's just more obstacles to later change. But some input 
either from Wolfgang about the Pizza code, or one of the MHD codes, 
would also be necessary before making the change.
>> - If you really want to be general the the three genuine primitive
>> variables should be unspecified as well - just another vector group.
>> This would allow different implementations to use, e.g., {rho, eps, P}
>> or {rho, eps, s} or... as controlled by some parameter within Hydrobase.
> When the names are different and nicely long, it should be possible to
> use #defines to produce more readable code in the implementations.
The main point with this is to clarify what are the fundamental 
variables in any implementation.
>> - It makes no sense to put references to conserved variables in the
>> schedule.ccl if there are no conserved variables defined. If you're
>> going to assume that conserved variables will be used then define them -
> Assuming that there are conserves variables does not mean to know which
> are there and how they should be defined.
But the choice of conserved variables is considerably more constrained 
than that of the primitive. Also, you may want to allow for 
implementations that do not consider the conserved variables at all.
>> I'll keep looking at it. At the moment I waver between saying that the
>> thorn should add more code - e.g., give more structure to the use of
>> conserved variables and the EOS - or to remove more. If ADMBase is
>> really the model it should probably be the latter.
> HydroBase should be the common ground for hydrocodes within Cactus. In
> this sense, it should be common to ADMBase. That does not mean that the
> structure has to be the same or that it could not contain more than the
> 'simple' ADMBase.
What I meant by this was that the simplest, most general "base" thorn 
would contain no reference to conserved variables at all - this is 
closest to the way that ADMBase doesn't include conformal factors etc.


More information about the Developers mailing list