#815: Outlfow thorn in incoming ------------------------------------+--------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by rhaas):
All HydroBase variables are used only through the interpolator interface. So inheritance was not required (which is why we never notice). It would be nice though to add inheritance to avoid late time aborts given that the thorn cannot possible run without HydroBase. Is there a version of REQUIRE that could be used instead? Something that ensures that an implementation is active without exposing that implementations variables?
Rather than split the thorn, I'd rather make it eventually use SphericalSlice which has its own (hopefully standardised and by then documented) output format for data on a sphere. That would seem to make more sense than to maintain these rather kludgy output routines.
I am not entirely averse to just splitting the single gigantic source file into smaller pieces though.
Each of the 20 grid variables is used to store the projection onto the sphere of a given "extra" grid function. The flux itself is always stored in fluxdens_projected. One should probably change "Whisky" to "GRHydro". I admit having so many variables and parameters is not particularly elegant.
There are 20 grid variables since each of them is already an array and Cactus does not support 2d arrays of grid arrays so I did not know of a "nice" way to combine them. I dislike having it a 4d array where the indices are theta-phi-detector-variable since it mixes different things in the index. I am not sure how to output only a single slice out of the 4d array if I want output of only one of the extra variables that is projected onto the sphere. I'd *love* 2d arrays of variables (and parameters) in Cactus (or can I write "20*num_detectors" in the declaration instead, which would still be awkward for output?). Reading this now, this does seem rather similar to what sphericalslice does... Maybe we should simply remove the extra variables option and refer users to SphericalSlice instead.