conflicting barriers in CarpetLib
Issue #2717
new
To debug some Cactus issues on the Delta cluster I am running simulations using:
CarpetLib::barriers = "yes"
CarpetLib::barrier_between_stages = "yes"
Carpet::barriers = "yes"
Carpet::schedule_barriers = "yes"
Carpet::sync_barriers = "yes"
which results in failure:
WARNING level 0 from host cn045.delta.internal.ncsa.edu process 47
while executing schedule bin CCTK_RECOVER_VARIABLES, routine IOUtil::IOUtil_RecoverGH
in thorn CarpetLib, file /scratch/rhaas/Cactus/arrangements/Carpet/CarpetLib/src/dist.cc:210:
-> Wrong id for Barrier "CarpetLib::gdata::gdata": expected 783988953d, found 404924393d
exec: /scratch/rhaas/Cactus/arrangements/Carpet/Carpet/src/helpers.cc:275: int Carpet::Abort(const _cGH
*, int): Assertion `0' failed.
I expect this will be avoidable if I reduce the number of barriers used, so is not a major issue.
The two barriers involved (based on their tags) are the one in the gdata::gdata constructor and commstate::step “CarpetLib::comm_state::step”.
This might be an actual bug in Carpet. Or it might be that these barriers haven’t been tested in a long time, and don’t conform to Carpet’s communication algorithms any more.
I would be careful activating these barriers, they might just be incorrect these days.