- changed status to open
- removed comment
Output metadata from TwoPunctures
Issue #551
closed
It is desirable to be able to determine the properties of !TwoPunctures initial data from the simulation output. Currently, some quantities (initial momenta etc.) can be determined by parsing the parameter file and param.ccl, and others by parsing the standard output of the run (ADM mass). Neither of these are optimal.
The attached patch causes !TwoPunctures to output a metadata file in the form described in [http://arxiv.org/abs/0709.0093 Data formats for numerical relativity waves]. The keys used include current draft proposals used in the NR-AR project.
To encourage the use of this, I have made the output happen unconditionally.
The output filename is !TwoPunctures.bbh and it is written into IO::out_dir. The metadata file looks like this:
# ==================================
# Numerical Relativity Metadata file
# ==================================
#
# This file contains information about the simulation provided by the
# TwoPunctures thorn. The format is described in the NR Data Format Document
# http://arxiv.org/abs/0709.0093 [draft SVN r707].
[metadata]
initial-ADM-energy = 1.190594340667362472
initial-ADM-angular-momentumx = 0.1100000000000000006
initial-ADM-angular-momentumy = 0.2200000000000000011
initial-ADM-angular-momentumz = 1.195856641772157003
initial-separation = 7
initial-data-type = Bowen-York
initial-data-bibtex-keys = Bowen:1980yu Brandt:1997tf Ansorg:2004ds
initial-bh-position1x = 3.5
initial-bh-position1y = 0
initial-bh-position1z = 0
initial-bh-position2x = -3.5
initial-bh-position2y = 0
initial-bh-position2z = 0
initial-bh-momentum1x = -0.003358311330506950042
initial-bh-momentum1y = 0.1236938059674509982
initial-bh-momentum1z = 0
initial-bh-momentum2x = 0.003358311330506950042
initial-bh-momentum2y = -0.1236938059674509982
initial-bh-momentum2z = 0
initial-bh-spin1x = 0.1000000000000000056
initial-bh-spin1y = 0.2000000000000000111
initial-bh-spin1z = 0.2999999999999999889
initial-bh-spin2x = 0.01000000000000000021
initial-bh-spin2y = 0.02000000000000000042
initial-bh-spin2z = 0.02999999999999999889
initial-bh-puncture-adm-mass1 = 0.7117197159189734279
initial-bh-puncture-adm-mass2 = 0.5107035566228820267
Keyword: TwoPunctures
Comments (7)
-
reporter
-
- removed comment
Why is TwoPunctures_Metadata scheduled in local mode? This should probably be global mode instead.
I would add more comments to the generated .bbh file, e.g. date, user name, simulation name, etc.
The schedule changes are the only critical part of this patch. If the test cases pass, please apply.
-
reporter
- removed comment
!TwoPunctures_Metadata is scheduled in local mode because it needs access to the grid variables E and Ji. Will it have access to these in global mode? If not, which mode should I use? You are right that local mode is not correct - if you have two components on one process, or more than one refinement level, the metadata file will be written more than once.
Additional keys for the metadata file, e.g. those defined in the data format document, could indeed be added, but this should not be done in !TwoPunctures. Eventually there could be a metadata thorn which other thorns register fields with, and it could handle the generic things like simulation name, date, username etc, and write a single metadata file containing all the fields. Or to keep things simple, maybe individual thorns can write metadata files which the user can then merge together (e.g. with cat).
But the immediate need that we have is for the TwoPunctures metadata, so I want to get this implemented as quickly as possible.
-
- removed comment
Grid scalars and grid arrays are accessible in global mode (since there is only one instance of these scalars and arrays). Only grid functions require local mode (since there are many "instances" of them, i.e. components, patches, and levels).
I wanted to suggest to add these as comments, not as keys. Comments seems more flexible; one could add them (or remove them again) at a later point. They would be for human consumption, so that oneself knew when and were the file was written. All Carpet I/O thorns output such identifiers to their output files. The reason for this is that, sometimes, these output files are passed on to others, e.g. to a visualisation expert, and it then becomes forgotten which simulation created these files, and it then becomes impossible to describe the resulting visualisations, even if they made it to a journal cover.
These are the corresponding lines in CarpetIOASCII:
if (CCTK_IsFunctionAliased ("UniqueBuildID")) { const char* const build_id
(const char*) UniqueBuildID (cctkGH);
file << "# Build ID: " << build_id << eol; } if (CCTK_IsFunctionAliased ("UniqueSimulationID")) { const char* const job_id
(const char*) UniqueSimulationID (cctkGH);
file << "# Simulation ID: " << job_id << eol; } if (CCTK_IsFunctionAliased ("UniqueRunID")) { const char* const job_id
(const char*) UniqueRunID (cctkGH);
file << "# Run ID: " << job_id << eol; }
The patch is fine without these comments.
-
reporter
- removed comment
Metadata like this makes it difficult to diff output, as you end up with many differences between two simulations which are actually "the same" as far as you are concerned. Kranc used to include the username and date in every generated output file, and it made comparing generated code very painful.
-
reporter
- changed status to resolved
- removed comment
I decided not to add the extra information for the reason in the previous comment. A metadata file such as this doesn't make a lot of sense on its own, and this information should be present somewhere else in the simulation.
I have changed the scheduling from local mode to global mode, and committed the patch in changeset:124/EinsteinInitialData/TwoPunctures.
-
- edited description
- changed status to closed
- Log in to comment
- Assignee
- –
- Type
- Priority
- Status
- closed
- Component
- EinsteinToolkit thorn
- Milestone
- –
- Version
- –
- Votes
- 0
- Watchers
- 0
