Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #2076: fix stripping of sourcedir path
by Einstein Toolkit 19 Nov '17

19 Nov '17

#2076: fix stripping of sourcedir path ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: backport | ------------------------+--------------------------------------------------- Commit d6e4f58 - sim-sync: handle symbolic links more gracefully (1 year, 6 months ago) <Roland Haas> introduced a bug that manifest in error messages of the form "mkdir: cannot create directory `/ET_Hack': Permission denied". Pull request is https://bitbucket.org/simfactory/simfactory2/pull- requests/21/simlib-correct-stripping-of-first-part/diff This should be backported to the release as it is very annoying to not even be able to use sim sync to transfer code. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2076> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #181: AEILocalInterp should not off-centre the interpolation stencil by default
by Einstein Toolkit 19 Nov '17

19 Nov '17

#181: AEILocalInterp should not off-centre the interpolation stencil by default ----------------------------+----------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: AEILocalInterp | ----------------------------+----------------------------------------------- AEILocalInterp by default will off-centre the interpolation stencil if there are insufficient points to perform the interpolation. In a parallel setting, this could happen due to there being insufficient ghost points for the interpolator chosen. The off-centering leads to an interpolation error which is of the correct order but larger than for a centered stencil. More importantly, it leads to different results on different numbers of processes. This violates a basic design principle of Cactus, and the expectation of users, that changing the number of processors should not change the results of a simulation. I propose that instead of silently off-centering the stencil, AEILocalInterp should abort with an error indicating that there are insufficient ghost-zones. The interpolator options corresponding to this are: boundary_off_centering_tolerance={0.0 0.0 0.0 0.0 0.0 0.0} boundary_extrapolation_tolerance={0.0 0.0 0.0 0.0 0.0 0.0} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/181> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #2085: ET header bar covers text for mid-sized window width
by Einstein Toolkit 19 Nov '17

19 Nov '17

#2085: ET header bar covers text for mid-sized window width -------------------------------------+-------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: development version Keywords: | -------------------------------------+-------------------------------------- The ET bar (at least for my browser and my OS and my screen) covers part of the website for mid-sized (and small though not all will show it) windows. Please see attached screenshots. Mostly it just seems to affect the headings but that seems to be accidental. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2085> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #2068: Support KNL's AVX512 instruction set
by Einstein Toolkit 06 Nov '17

06 Nov '17

#2068: Support KNL's AVX512 instruction set ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- The main point of this pull request is to support KNL's AVX512 instruction set. This pull request also contains a few other changes on which the AVX512 depends. See [https://bitbucket.org/cactuscode/cactusutils/pull-requests/13 /support-knls-avx512-instruction-set/diff]. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2068> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 14

[Einstein Toolkit] #2074: Correct error in vertex-centred prolongation operators
by Einstein Toolkit 06 Nov '17

06 Nov '17

#2074: Correct error in vertex-centred prolongation operators ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: | ----------------------+----------------------------------------------------- See <https://bitbucket.org/eschnett/carpet/pull-requests/19/correct-error- in-vertex-centred/diff>. This corrects #2068. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2074> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #2023: CarpetInterp hangs with openmpi
by Einstein Toolkit 28 Oct '17

28 Oct '17

#2023: CarpetInterp hangs with openmpi -----------------------------+---------------------------------------------- Reporter: anonymous | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: OpenMPI, Carpet | -----------------------------+---------------------------------------------- On three occasions with two different simulations (TOV, BNS) the code hung. In two cases, I could attach a debugger to the running process, and in both cases the backtrace looked like this: {{{ #0 0x00007f4ecfd5729a in __GI___pthread_mutex_lock (mutex=0xc40d730) at ../nptl/pthread_mutex_lock.c:79 #1 0x00007f4ec7224807 in ?? () from /usr/lib/openmpi/lib/openmpi/mca_btl_openib.so #2 0x00007f4ecdae734a in opal_progress () from /usr/lib/libmpi.so.1 #3 0x00007f4ecda2d3b4 in ompi_request_default_wait_all () from /usr/lib/libmpi.so.1 #4 0x00007f4ec61cb7b7 in ompi_coll_tuned_sendrecv_actual () from /usr/lib/openmpi/lib/openmpi/mca_coll_tuned.so #5 0x00007f4ec61d0df6 in ompi_coll_tuned_alltoallv_intra_pairwise () from /usr/lib/openmpi/lib/openmpi/mca_coll_tuned.so #6 0x00007f4ecda3a00f in PMPI_Alltoallv () from /usr/lib/libmpi.so.1 #7 0x00000000015458fe in CarpetInterp::Carpet_DriverInterpolate (cctkGH_=<optimized out>, N_dims=<optimized out>, local_interp_handle=3, param_table_handle=6421, coord_system_handle=0, N_interp_points=224, interp_coords_type_code=130, coords_list=<optimized out>, N_input_arrays=6, input_array_variable_indices=0x7fff38fbf640, N_output_arrays=24, output_array_type_codes=0x7fff38fbf660, output_arrays=0x7fff38fbfb00) at /home/wolfgang.kastaun/ET/Payne/Cactus/arrangements/Carpet/CarpetInterp/src/interp.cc:645 #8 0x000000000071ee4f in SymBase_SymmetryInterpolateFaces (cctkGH_=0xccb1be0, N_dims=<optimized out>, local_interp_handle=3, param_table_handle=6421, coord_system_handle=0, N_interp_points=224, interp_coords_type=130, interp_coords=0x7fff38fbe1a0, N_input_arrays=6, input_array_indices=0x7fff38fbf640, N_output_arrays=24, output_array_types=0x7fff38fbf660, output_arrays=0x7fff38fbfb00, faces=0) at /home/wolfgang.kastaun/ET/Payne/Cactus/arrangements/CactusBase/SymBase/src/Interpolation.c:381 }}} I'm not sure if this is a problem with Carpet or with my OpenMPI installation. It only happens rarely, after one day or so. I'm using ET version Payne, gcc 4.9.2, openmpi 1.6.5 on an infiniband interconnect. The code was compiled with OpenMP support and run using 4 threads per process. Looking at various variables in Carpet_DriverInterpolate with the debugger, I noticed that the vector tmp was reported with size -488221088, but this could also be mis-reported by gdb since the code was compiled with -O3. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2023> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #778: Compiling PittNullCode is slow
by Einstein Toolkit 24 Oct '17

24 Oct '17

#778: Compiling PittNullCode is slow -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Compiling PittNullCode is very slow on some systems (e.g. with gcc). I believe this is because files such as NullConstr_R00.F90 contain many whole-array operations that the compiler has to analyse. I suggest to rewrite these routines, using e.g. forall or do loops. If we want to keep the elegant, index-free notation, then I suggest to add an elemental subroutine for the actual calculations and calling it with whole arrays. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/778> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1283: Missing data in HDF5 files
by Einstein Toolkit 24 Oct '17

24 Oct '17

#1283: Missing data in HDF5 files --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- If a simulation runs out of disk space while writing an HDF5 file, the simulation will terminate. The hdf5 file being written might then be corrupt, and all data from it may be irretrievable. In that case, restarting from the last-written checkpoint file may leave a "gap" in the data corresponding to the period between the start of the failed restart and the last checkpoint file written. Steps to reproduce: • Start a simulation which checkpoints periodically and consists of several restarts • Keep all checkpoint files • Restart 0000 completes successfully and checkpoints at iteration i1 • Restart 0001 checkpoints once after some evolution at iteration i2 • Restart 0001 terminates abnormally while writing an HDF5 output file at iteration i3 • The output file is corrupted and nonrecoverable, so there is no data from iteration i1 to iteration i3 • Restart 0002 starts at iteration i2 as this is the last checkpoint available • The simulation continues until the end, but the data from the corrupted HDF5 file between iteration i1 and i2 is lost Possible solutions: 1. Write HDF5 files safely, e.g. by first copying the file to a new temporary file, performing the write, then atomically moving the temporary file over the original file. The original file would then remain in the event of a crash while writing the new file. This could be very expensive for 3D output files. 2. Start a new set of HDF5 files after each checkpoint. This seems to be the most efficient and simplest solution, but requires readers of HDF5 files to be modified to take it into account. 3. Check the consistency of all HDF5 files in the previous restart(s) on recovery, and recover from the latest checkpoint file for which all previous HDF5 files are valid. We could use code to check the HDF5 file, or some other flagging mechanism to indicate that HDF5 writes were completed successfully; e.g. we could rename the HDF5 file to .tmp during writes, and rename it back after a successful write. This is complex and requires Cactus or simfactory to look into previous restarts. It also only applies to HDF5 files, and requires breaking several abstraction barriers. 4. Wait for HDF5 journalling support. As far as I know only metadata journalling is planned, which is probably not enough, and in any case, they are not actively working on the next version of HDF5 at the moment due to lack of funding. 5. Checkpoint only on termination of the simulation In reality, we do not keep all checkpoint files. I usually keep just the last checkpoint file. I believe that a Cactus simulation will only delete checkpoint files which it has itself written, which means that there will generally be one checkpoint file kept per restart; the last one written. This means that you can always recover from the above situation by rerunning the restart during which the problem occurred. However, keeping one checkpoint file per restart is a problem in itself, and we should fix this as well, which would then mean the potential for losing data in the case of an interrupted write operation. Thoughts? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1283> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 14

[Einstein Toolkit] #1193: CarpetReduce uses lsh for index calculations
by Einstein Toolkit 24 Oct '17

24 Oct '17

#1193: CarpetReduce uses lsh for index calculations --------------------+------------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: ET_2013_05 Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- CarpetReduce (e.g. reduce.cc:644) uses lsh to calculate GF indices. This is wrong in case lsh!=ash. Either use ash or the Cactus macros (which would probably be even better). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1193> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1181: Parameter file parsing error message is hidden
by Einstein Toolkit 24 Oct '17

24 Oct '17

#1181: Parameter file parsing error message is hidden ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- Parse errors in parameter files are hidden among other output, and are thus difficult to spot. This example shows this: {{{ cactus::cctk_itlast = 3 ; ActiveThorns = "HDF5" }}} The problem is that the error message is output among the activation messages. If the parameter file is long and the syntax error is in the beginning, then several hundred lines may be output after the error message, which makes it very difficult to spot it. The parsing errors should be output in the same way as other parameter errors, which are prefixed by WARNING etc. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1181> 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