#815: Outlfow thorn in incoming -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- Hello all,
as discussed in the last phone call, the GT Outflow thorn has been put into incoming (http://svn.einsteintoolkit.org/incoming/Outflow).
From the docs: {{{ Outflow calculates the flow of rest mass density across a SphericalSurface, eg. and apparent horizon or a sphere at ``infinity''. }}}
It has documentation, test-cases and publications using it (http://arxiv.org/abs/1201.4389).
Ok to include in EinsteinAnalysis?
#815: Outlfow thorn in incoming ------------------------------------+--------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: ------------------------------------+--------------------------------------- Changes (by rhaas):
* component: Other => EinsteinToolkit thorn
#815: Outlfow thorn in incoming ------------------------------------+--------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by eschnett):
I suggest to split the thorn into two, one for the analysis, the other for the output. If the ASCII output format introduced by this thorn is useful, it should be generally available (and if it is not useful it shouldn't be there). It is not a good idea to mix numerical analysis and computational infrastructure.
Why does the thorn inherit from ADMBase, but not from Hydrobase? It uses variables from both.
Why are there explicit declarations for 20 grid variables? It would be cleaner if those were stored as array, or (at least) in the same group.
Given this comment "I hard-code the current to use to be the flux of dens in Whisky", why are there 20 grid variables? Couldn't the flux be stored in a single variable? (And shouldn't this be HydroBase instead?)
#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.
#815: Outlfow thorn in incoming ------------------------------------+--------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by rhaas):
I added inheritance from HydroBase and collected all extra surface projections in a single group. Could Outflow be moved into EinsteinAnalysis, please? I'll then add it to the trunk thorn list so that its test suite runs. Converting to use SphericalSlice has to wait until SphericalSlice is part of ET.
#815: Outlfow thorn in incoming ------------------------------------+--------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: review Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: ------------------------------------+--------------------------------------- Changes (by knarf):
* status: new => review
#815: Outlfow thorn in incoming ------------------------------------+--------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: reviewed_ok Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: ------------------------------------+--------------------------------------- Changes (by eschnett):
* status: review => reviewed_ok
#815: Outlfow thorn in incoming ------------------------------------+--------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: reviewed_ok Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: ------------------------------------+---------------------------------------
Comment (by rhaas):
Outflow moved into a git repository at github: https://github.com/rhaas80/Outflow I attach a patch to the toolkit thornlist.
#815: Outlfow thorn in incoming ------------------------------------+--------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: reopened Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: ------------------------------------+--------------------------------------- Changes (by rhaas):
* status: reviewed_ok => reopened
#815: Outlfow thorn in incoming ------------------------------------+--------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: reopened Priority: optional | Milestone: ET_2013_05 Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: ------------------------------------+--------------------------------------- Changes (by knarf):
* milestone: => ET_2013_05
#815: Outlfow thorn in incoming ------------------------------------+--------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: closed Priority: optional | Milestone: ET_2013_05 Component: EinsteinToolkit thorn | Version: Resolution: fixed | Keywords: ------------------------------------+--------------------------------------- Changes (by knarf):
* status: reopened => closed * resolution: => fixed
trac@lists.einsteintoolkit.org
-
Einstein Toolkit