1. Einstein Toolkit Avatar Einstein Toolkit
  2. Einstein Toolkit
  3. tickets
  4. Issues

Outlfow thorn in incoming

Issue #815 closed
Roland Haas created an issue

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?

Keyword:

Comments (11)

  2. Erik Schnetter
    • removed comment

    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?)

  3. Roland Haas reporter
    • removed comment

    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.

  4. Roland Haas reporter
    • removed comment

    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.

  12. Log in to comment
Assignee
–
Type
enhancement
Priority
minor
Status
closed
Component
EinsteinToolkit thorn
Milestone
ET_2013_05
Version
–
Votes
0
Watchers
0
Jira Software: the preferred issue tracker for Bitbucket. Join the team!