Gwyneth

Congratulations, you found another bug in Carpet. There is some internal inconsistency that was detected, forcing the run to abort. Yes, please open a full bug report. In particular a stack backtrace would be helpful.

0D HDF5 output is rarely used. You can use 0D ASCII output instead as a work-around.

(I don't think this has anything to do with bboxset1 vs. bboxset2. You are using bboxset2, which is the modern variant, which is good.)

-erik

On Sun, Mar 12, 2017 at 4:08 AM, Gwyneth Allwright <allgwy001@myuct.ac.za> wrote:

Hi All,

One of my simulations recently aborted with the following error:

cactus_ET: /opt/exp_soft/EinsteinToolkit/Cactus/arrangements/Carpet/CarpetLib/src/bboxset2.hh:261: bboxset2::bboxset<T, D> bboxset2::bboxset<T, D>::binary_operator(const F&, const bboxset2::bboxset<T, D>&) const [with F = bboxset2::bboxset<T, D>::operator&(const bboxset2::bboxset<T, D>&) const [with T = int; int D = 3]::<lambda(const bboxset1&, const bboxset1&)>; T = int; int D = 3]: Assertion `all(stride == other.stride)' failed.

This was when running on an HPC cluster. On my laptop, it works fine and I don't get this error.

However, commenting out the following section in my parameter file resulted in a successful HPC run:

Activethorns = "CarpetIOHDF5"
IOHDF5::one_file_per_group = "yes"
IOHDF5::out0D_every = 128
IOHDF5::out0D_vars = "
WEYLSCAL4::Psi4r
WEYLSCAL4::Psi4i
PunctureTracker::pt_loc
"

This is the only HDF5 output I'm requesting. Am I doing something silly here?

If it would help, I'd be happy to open a ticket and attach the whole parameter file, backtrace etc.

Gwyneth

_______________________________________________
Users mailing list
Users@einsteintoolkit.org
http://lists.einsteintoolkit.org/mailman/listinfo/users

Erik Schnetter <schnetter@cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/