include SphericalHarmonicReconASCII from incoming in PITTNULLCode

Create issue
Issue #816 closed
Roland Haas created an issue

Christian Reisswig provided a copy of SphericalHarmonicReconASCII and alternative thorn that reads in CCE boundary data (similar SphericalHarmonicRecon) but supporting a wider variety of input file formats (HDF5 among them, irrespective of the name).

Used by SpEC and Llama.

There are no docs or test cases as of now. Test data would be welcome (SpEC, Llama or Cactus provided, I don't think it makes a difference).

Keyword:

Comments (18)

  1. Erik Schnetter
    • removed comment

    This thorn lacks documentation, examples, and test cases.

    Instead of scheduling SphericalHarmonicReconASCII_Startup both at initial and post_recover_variables, I recommend scheduling only at basegrid.

  2. Frank Löffler
    • removed comment

    Is it known what the cause for the failure on different numbers of processors is (tolerance too low for reduction-based tests)?

  3. Roland Haas reporter
    • removed comment

    I have to admit I have no idea. I just noticed it tonight. Since the thorn won't make it into the release (lack of documentation) this is not terribly high on my list of things to do before the release :-). The test uses the default tolerances so RELTOL=ABSTOL=1e-12. Output seems to differ at about this level. However the maximum should be independent of the number of processes I think.

    diff SpEC-h5-test/NewsB[0]_maximum.asc /NewsB[0]_maximum.asc
    
    3c3
    < 963.0000000000000     0.0034305367678
    ---
    > 963.0000000000000     0.0034305368375
    
  4. Roland Haas reporter
    • removed comment

    Replying to [comment:3 eschnett]:

    This thorn lacks documentation, examples, and test cases.

    Instead of scheduling SphericalHarmonicReconASCII_Startup both at initial and post_recover_variables, I recommend scheduling only at basegrid. Scheduling only at basedgrid will currently fail since the startup routine copies cctk_iteration into its own data structures. Since BaseGrid runs before CCTK_RECOVER_VARIABLES it would see the wrong iteration number. A solution might be to not make copies of cctkGH members in thorn-owned data structures.

  5. Erik Schnetter
    • removed comment

    The iteration number (and other cGH entries) should be set before recover_variables. They should be available in basegrid. Can you open a ticket for this?

  6. Roland Haas reporter
    • removed comment

    I have to admit that I did not check what actually happens and only looked at the schedule output (CarpetIOHDF5 certainly fiddles with the iteration number though). I will investigate and open the required number of new tickets. So the idea is to set the cGH entries as early as recover_parameters?

  7. Erik Schnetter
    • removed comment

    Either there, or some time shortly thereafter. However, all grid functions (and, by extension, all cGH entries) must be available in basegrid. The cGH should be set up at the same time as the grid structure.

  8. Roland Haas reporter
    • removed comment

    I just have (for the first time) actually worked with the code. I believe that it will be best to spend an afternoon and clean up the code.

    TODO items:

    • make sure all externally visible functions with C linkage start with "SphericalHarmonicReconGeneric_"
    • consolidate the (global) variables in the SHR namespace into a single source file, vars.cc
    • remove commented out sections of code
    • use CCTK_INFO for informational output instead of cout
    • use CCTK_Error to abort rather than assert
    • clean up double vs CCTK_REAL issues
    • terminate cleanly when running out of data in mode files
  9. Ian Hinder
    • changed status to open
    • marked as
    • changed milestone to ET_2014_11
    • removed comment

    Bela has an enhancement to this thorn and would like to commit it. The current status is that this thorn lives at https://svn.einsteintoolkit.org/incoming/PITTNullCode/SphericalHarmonicReconGen/ but apparently has not been included in the toolkit due to a desire to clean up the code. For convenience, I think this should be imported into the main PittNullCode repository. I have created a git svn clone of the SVN repository, and imported this (as a subtree merge) into a new branch "sphericalharmonicrecongen" of the BitBucket PittNullCode repository. I have not applied the username mappings or attempted any other complicated cleanup of the branch. It would be good if someone could tidy up the code on this branch, get it reviewed, and hopefully into the next release, as it has been sitting in incoming for a very long time.

  10. Roland Haas reporter
    • changed status to open
    • removed comment

    Christian Reisswig took care of all remaining issues in svn revision 213 and 214. Unless vetoed in today's call I will apply this by the end of the week of Jul 13 2015.

  11. Log in to comment