Test whether we need to call build_constraint_matrix() recursively
The hypothesis is that libmesh now expands all "recursive" constraints before calling this function, and therefore it should not need to be called recursively. This PR tests whether that is the case.
@roystgnr looks like the failures are related to IGA (assuming because of the "Dyna" stuff) and periodic boundary conditions. So I guess it's not the case that build_constraint_matrix() always receives expanded constraints and we do still need the recursion? If so, I will just change this PR to be a documentation update and leave the recursion in...
!!!FAILURES!!!
Test Results:
Run: 1916 Failures: 0 Errors: 5
1) test: MeshInputTest::testDynaFileMappingsFEMEx5 (E)
uncaught exception of type libMesh::LogicError
- All constraints should have been expanded before calling DofMap::build_constraint_matrix(), but dof_set still contains 9 entries.
2) test: MeshInputTest::testDynaFileMappingsBlockWithHole (E)
uncaught exception of type libMesh::LogicError
- All constraints should have been expanded before calling DofMap::build_constraint_matrix(), but dof_set still contains 27 entries.
3) test: MeshInputTest::testDynaFileMappingsPlateWithHole (E)
uncaught exception of type libMesh::LogicError
- All constraints should have been expanded before calling DofMap::build_constraint_matrix(), but dof_set still contains 9 entries.
4) test: MeshInputTest::testDynaFileMappingsCyl3d (E)
uncaught exception of type libMesh::LogicError
- All constraints should have been expanded before calling DofMap::build_constraint_matrix(), but dof_set still contains 27 entries.
5) test: PeriodicBCTest::testPeriodicLagrange2 (E)
uncaught exception of type libMesh::LogicError
- All constraints should have been expanded before calling DofMap::build_constraint_matrix(), but dof_set still contains 2 entries.
I can't quite understand the IGA failures there. We are semi-manually adding constraints from DynaIO after the existing constraints have all been processed. But the IGA constraints we add shouldn't actually need any further processing! Values on FE DoFs get constrained to values on spline node DoFs, but there's only one level of constraint there, nothing recursive.
With the Periodic BC test I have the converse confusion: I can see how we can have recursive constraints there (periodic vs Dirichlet constraints at corner nodes), but both those types of constraints get automatically added before constraints are processed, so I don't see why they're not expanded afterward.
This PR has been marked "do not merge" since we are no longer accepting PRs into the master branch. All new PRs should be made on the devel branch instead. Once this PR's target branch has been updated to devel, the "do not merge" label will be removed.