#1499: Error in synchronisation after restriction ---------------------+------------------------------------------------------ Reporter: hinder | Owner: eschnett Type: defect | Status: reopened Priority: major | Milestone: ET_2014_05 Component: Carpet | Version: development version Resolution: | Keywords: ---------------------+------------------------------------------------------
Comment (by hinder):
Replying to [comment:6 rhaas]:
Well the tests *did* fail after Erik's changes but then the prolongation
tests are not doing what normal thorn is supposed to do, ie they are not scheduling MoL_PostStep after the restrict. So data was regennerated (carpet-6-init-355-gb3bc3f5 "update test data").
I have now gone through several levels of being confused about what the tests did, what you said and why, and what Erik did or didn't do :) In summary:
* In September, Erik removed the sync after restriction, because thorns are supposed to sync in postrestrict/mol_poststep anyway * This caused CarpetProlongateTest to fail, because it deliberately doesn't do this sync * Therefore, the test data was regenerated, and these tests started to pass again * When Erik added back in the sync after restriction, which we now realise is needed because the sync in postrestrict doesn't happen in the right order, the test started failing again. * This test is not part of the Einstein Toolkit; the thorns CarpetProlongateTest and CarpetIntegrateTest are only in the "proposed" branch. We test them as part of the Jenkins EinsteinToolkitProposed job, but not as part of the main EinsteinToolkit job.
I think it should be possible to revert the test data change commit and have the tests pass again.