#2861: Running qc0 with CarpetX
Reporter: Alejandra Gonzalez
Status: open
Milestone:
Version:
Type: bug
Priority: major
Component: EinsteinToolkit thorn
Comment (by Lucas Timotheo Sanches):
Hi Alejandra.
I was unable to make `Punctures` work by simply modifying parameters, which suggests that the thorn has a more fundamental issue. This will need to be further investigated at another opportune moment.
Regardless, as you noted `TwoPuncturesX` is the preferred option for initial data and should be used instead.
Yes, your output seems to indicate that your execution of the parameter file was successful. As you may have noticed, this example parameter file only runs for a single iteration, which is probably not very useful for your needs.
As for output formats, here’s an abbreviated guideline
* Whenever you intend to visualize 3D data, use the `Silo` format. The `Silo` format can be used natively with [LLNL’s VisIt](https://visit-dav.github.io/visit-website/index.html). This is probably the easiest way to visualize `CarpetX` data, as it allows you to simply read the files and create plots by using a GUI. The `OpenPMD` file is also an option for visualization, but you may have to write custom Python scripts for it.
* Whenever you wish to store data, in Checkpoints, for instance, the `ADIOS2` and `OpenPMD` files are adequate.
* `TSV` data, which is plain text, not recommended for storage, in general. It is more of a debug format, where you can look at grid function values in a human readable manner. `TSV` data is also adequate for storing the multipolar extractions of the Weyl scalar and the location of the punctures throughout the simulation.
‌
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2861/running-qc0-with-…
#2861: Running qc0 with CarpetX
Reporter: Alejandra Gonzalez
Status: open
Milestone:
Version:
Type: bug
Priority: major
Component: EinsteinToolkit thorn
Comment (by Alejandra Gonzalez):
Hello Lucas, thank you. For the record I was able to run `qc0` with the thorns:
```
ActiveThorns = "
ADMBaseX
CarpetX
CoordinatesX
ErrorEstimator
Formaline
IOUtil
TwoPuncturesX
"
```
with the following output:
```
INFO (Formaline): Writing tarballs with the Cactus sources into the directory "qc0/cactus-source"
INFO (CarpetX): Setting initial values for max_grid_size values for all levels
INFO (CarpetX): Setting up initial conditions...
INFO (CarpetX): Iteration: 0 time: 0 delta_time: 0.25
INFO (CarpetX): Patch 0:
INFO (CarpetX): Grid extent:
INFO (CarpetX): gsh=[67,67,67]
INFO (CarpetX): blocking_factor=[8,8,8]
INFO (CarpetX): max_grid_size=[32,32,32]
INFO (CarpetX): max_tile_size=[1024000,16,32]
INFO (CarpetX): Domain extent:
INFO (CarpetX): xmin=[-16,-16,-16]
INFO (CarpetX): xmax=[16,16,16]
INFO (CarpetX): base dx=[0.5,0.5,0.5]
INFO (CarpetX): Initializing level 0...
INFO (CarpetX): Regridding...
INFO (CarpetX): level 0: 8 boxes, 262144 cells (100%)
INFO (CarpetX): Initialized 1 levels
INFO (CarpetX): OutputGH: iteration 0, time 0.000000, run time 5 s
INFO (CarpetX): OutputSilo...
Results from timer "OutputSilo":
gettimeofday: 0.102 secs
Results from timer "OutputSilo":
getrusage: 0.085 secs
INFO (CarpetX): OutputGH done.
INFO (CarpetX): Starting evolution...
INFO (CarpetX): Shutting down...
Total GPU global memory (MB) spread across MPI: [64952 ... 64952]
Free GPU global memory (MB) spread across MPI: [64165 ... 64165]
[The Arena] space (MB) allocated spread across MPI: [48714 ... 48714]
[The Arena] space (MB) used spread across MPI: [0 ... 0]
[The Device Arena] space (MB) allocated spread across MPI: [8 ... 8]
[The Device Arena] space (MB) used spread across MPI: [0 ... 0]
[The Pinned Arena] space (MB) allocated spread across MPI: [8 ... 8]
[The Pinned Arena] space (MB) used spread across MPI: [0 ... 0]
AMReX (24.10) finalized
--------------------------------------------------------------------------------
Done.
```
I would like to know if this is the expected verbose and if you have any suggestions about the type of output I should use \(openpmd, silo, etc\) while running with carpetx or if it’s irrelevant.
‌
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2861/running-qc0-with-…
#2633: SummationByPart's Diff_gv aliased function does ont document which part of the grid the computed derivative is valid
Reporter: Roland Haas
Status: new
Milestone:
Version:
Type: bug
Priority: minor
Component:
Comment (by Peter Diener):
I suggest adding the following to the end of section 3.4:
In both cases, the derivatives are not calculated in ghost zones of
inter-processor or symmetry boundaries, i.e. the returned derivatives are
undefined in ghost zones and will require synchronization of either the
derivatives or the evolved fields depending on the scheme used.
It would be wrong to switch to use one sided derivatives in ghost zones as,
for most operators, the region, where one sided derivatives would be
calculated, is larger than the ghost region. Hence some cells where centered
finite differences could be calculated would contain one sided derivatives and
the result would depend on the number of processors used.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2633/summationbyparts-…
#2863: simfactory does not correctly handle non existing files
Reporter: Roland Haas
Status: open
Milestone:
Version:
Type: bug
Priority: major
Component: SimFactory
Changes (by Roland Haas):
status: open (was new)
Comment (by Roland Haas):
Please review
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2863/simfactory-does-n…