Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #2073: IO corruption on SDSC oasis file systems
by Einstein Toolkit 25 Dec '17

25 Dec '17

#2073: IO corruption on SDSC oasis file systems -------------------------------+-------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: development version Keywords: Comet Gordon SDSC | -------------------------------+-------------------------------------------- I am experiencing file corruption in ASCII output produced by the Cactus code on Comet's (and Gordon's as far as I remember) scratch file systems. This manifests as lines of output being mashed together in the output file. I have added strace calls to my job script to capture all arguments to the OS's write() function and re-created the write() calls based on this. Those write calls, when replayed on a login node, do produce a correct (no mashed lines) file. All output to the file in question was from rank 0 only even though the code used MPI and ran on two MPI ranks. The same code and number of MPI ranks produces a correct output file when run on the $HOME file system. Thus it seems to me as if there may be an issue with the file system. I can try and reduce the test case to a more minimal example (right now it is a full simulation even though it runs only for <1minute) . You can find the job script (for account, SLURM options etc) here: /oasis/scratch/comet/rhaas/temp_project/simulations/OSTREAM_2_12/output-0000/SIMFACTORY/SubmitScript the script that launches the MPI executable here: /oasis/scratch/comet/rhaas/temp_project/simulations/OSTREAM_2_12/output-0000/SIMFACTORY/RunScript the strace output here: /home/rhaas/strace/strace.1882[67].log and the awk script to recreate the write calls is: gawk -vFS='"' '/write.*\/grid-coordinates.xy.asc/{print "printf \""$2"\""}' ~/strace.18826.log >recreate.sh The corrupted line is eg. line 161 of /oasis/scratch/comet/rhaas/temp_project/simulations/OSTREAM_2_12/output-0000/TEST/sim/CarpetIOASCII/newsep /grid-coordinates.xy.asc which reads 1 4 3 4 1 0.1666666666660.505076272276105285714 etc but should read 1 4 3 4 1 0.166666666666667 -0.0714285714285714 I can avoid the file corruption by flushing the output file after each line. I am wondering if there is anything known about this or if there is a workaround that does not boil to first writing all data to a file system local to the compute node and copying to /oasis/scratch after the job is finished (how much local space would be available since I would also have to do so for eg checkpoint files and 3d hdf5 output). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2073> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #2092: make Cactus build system support non-interactive use eg in Jupyter notebooks
by Einstein Toolkit 23 Dec '17

23 Dec '17

#2092: make Cactus build system support non-interactive use eg in Jupyter notebooks -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- This refers to #1919:comment:4 which specifically asks about "make newthorn" but really seems to indicate that all interaction should be double checked. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2092> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1919: have make newthorn create a functioning thorn
by Einstein Toolkit 23 Dec '17

23 Dec '17

#1919: have make newthorn create a functioning thorn -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Currently the newthorn make target does not create a functioning thorn. It would be good if it produced a skeleton thorn that compiled. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1919> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #2022: thorn guide on et website links to pdf pages
by Einstein Toolkit 23 Dec '17

23 Dec '17

#2022: thorn guide on et website links to pdf pages -------------------------------------+-------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: development version Keywords: | -------------------------------------+-------------------------------------- This is a continuation #2010 which was about the thorn guide being missing. This one is about the link behind "Thorn Guide" on http://einsteintoolkit.org/documentation.html, namely http://einsteintoolkit.org/thornguide/ points to an auto-generated index page of a directory of pdf files. Instead of the correct HTML page for a table of content pointing to html pages of documentation. Likely requires web server access to fix. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2022> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #2030: Multi-block boundaries leave uninitialized boundary points
by Einstein Toolkit 23 Dec '17

23 Dec '17

#2030: Multi-block boundaries leave uninitialized boundary points -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- Applying multi-block boundaries can leave uninitialized boundary points. This happens when multi-block boundaries are used in combination with another boundary condition that looks at the interior of the grid, such as e.g. a symmetry condition or radiative / extrapolating boundaries. There is another bug currently in McLachlan that applies its "scalar" boundary conditions to too few grid points (it uses "BoundaryNoSync" instead of "Boundary"), which means there are uninitialized boundary points for {{{initial_boundary_condition = "scalar"}}} as well in multi- block systems. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2030> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #2053: simfactory's hard-coded rsync options override a mdb entry's rsyncopts
by Einstein Toolkit 23 Dec '17

23 Dec '17

#2053: simfactory's hard-coded rsync options override a mdb entry's rsyncopts ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- Right now, in line 165 of simfactory/lib/sim-sync.py {{{ cmd = "%s --rsh=%s --rsync-path=%s %s %s %s" % (rsynccmd, simlib.QuoteSafe(sshcmd), simlib.QuoteSafe(machineEntry.rsynccmd), rsyncopts, machineEntry.rsyncopts, arguments) cmd = "%s %s" % (cmd, " ".join(rsyncoptions)) }}} the hard-coded set of options in rsycnoptions {{{ rsyncoptions = [ '--checksum', '--compress', '--delete', '--hard-links', '--links', '--partial', '--perms', '--progress', '--recursive', '--sparse', '--stats', #'--times', '--verbose'] }}} overwrites the options passed in via the mdb (machineEntry.rsyncopts) since it appears later on the commmand line. This is (currently) an issue for minerva, whose file system does not support hard-links, since there is no way to pass in a {{{--no-hard-links}}} option for just minerva. Typically we don't have hard-links in our code trees, though it is certainly not something that is expected to never happen (eg I do have some hard links). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2053> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #2060: Parallel checkout fails on systems with threading missing from the perl installation
by Einstein Toolkit 13 Dec '17

13 Dec '17

#2060: Parallel checkout fails on systems with threading missing from the perl installation ---------------------------+------------------------------------------------ Reporter: diener | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ One of the participants at the EinsteinToolkit workshop tried to checkout Cactus on a machine she had access to. Apparently threading was missing from the perl installation and checking out with --parallel failed with the error: Can't call method "enqueue" on an undefined value at ./GetComponents line 1025. Checking out serially works. This suggests that some check for the threading is missing or not taken into account properly. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2060> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1753: hwloc: move pkg-config based detection into Search phase
by Einstein Toolkit 13 Dec '17

13 Dec '17

#1753: hwloc: move pkg-config based detection into Search phase -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: hwloc | -----------------------------------+---------------------------------------- the attacheched patch changes detect.sh such that pkg-config is treated on the same footing as the search at commonly known places. It also adds the option for the user to specify HWLOC_LIBS rather than hard-coding it to hwloc. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1753> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #2090: GetComponents should not prompt in a Jupyter notebook
by Einstein Toolkit 07 Dec '17

07 Dec '17

#2090: GetComponents should not prompt in a Jupyter notebook ---------------------------+------------------------------------------------ Reporter: sbrandt | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ GetComponents should only prompt if it is in a terminal and not in a Jupyter notebook. The following patch addresses this issue. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2090> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #2086: Perform only spatial prolongation when using a single timelevel and tag 'prolongation="copy"'
by Einstein Toolkit 22 Nov '17

22 Nov '17

#2086: Perform only spatial prolongation when using a single timelevel and tag 'prolongation="copy"' -------------------------------------------------------+-------------------- Reporter: miguel.zilhao.nogueira@… | Owner: eschnett Type: defect | Status: new Priority: unset | Milestone: Component: Carpet | Version: development version Keywords: | -------------------------------------------------------+-------------------- Sometimes it is useful to set a grid function that does not evolve at all. However, using a single timelevel and tag 'prolongation="copy"' results in a Carpet assertion failure. This is fixed in the following commit d13a6e245a3d7d2b575094fd0def540d510a166c, as discussed in the following thread: http://lists.einsteintoolkit.org/pipermail/users/2017-October/005835.html Could this be merged to master? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2086> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac