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