Update tests/ examples to use new serac::Mesh#1365
Conversation
chapman39
added
the
refactoring
…ac-mesh-propagate
…ac-mesh-propagate
…et, create new serac_mesh target
…ac-mesh-propagate
…/serac into task/chapman39/serac-mesh-propagate
…ac-mesh-propagate
…ac-mesh-propagate
| # TODO Shorten runtime down to less than one minute | ||
| # blt_add_test(NAME contact_${example_name} | ||
| # COMMAND contact_${example_name} | ||
| # NUM_MPI_TASKS 4) |
There was a problem hiding this comment.
ATM, these tests take too long to be in a regular CI job. Maybe we can have an option to tests examples nightly. Or we should somehow reduce the runtime of these examples similar to --fast in cylinder.cpp.
Start 86: contact_beam_bending
86/93 Test #86: contact_beam_bending .................... Passed 20.40 sec
Start 87: contact_ironing
87/93 Test #87: contact_ironing ......................... Passed 277.27 sec
Start 88: contact_sphere
88/93 Test #88: contact_sphere .......................... Passed 294.65 sec
Start 89: contact_twist
89/93 Test #89: contact_twist ........................... Passed 143.91 sec
There was a problem hiding this comment.
We can coarsen the meshes and/or just run them with 1 timestep for CI, but it'd be good to run them all the way once in a while. In my experience, convergence issues don't appear until towards the end of the simulation and with more refined meshes. I guess I'd vote for a nightly test for examples?
There was a problem hiding this comment.
Do these test have a 'gold' value that we are comparing to? If not, nightly or weekly, longer running tests don't add much anyways in my view. Perhaps we need to start developing a regression testing system, where we establish some expected result to compare to. Then, weekly running tests could catch changes in behavior. Though, realistically, they should be run through CI. Maybe we need to audit our CI for bottlenecks? For example, do we currently launch our 93 test in parallel, or do they wait for eachother to complete?
chapman39
added
ready for review
…ac-mesh-propagate
…ac-mesh-propagate
tupek2
left a comment
tupek2
left a comment
There was a problem hiding this comment.
Fantastic! Looks amazing to me. Maybe not as much duplication removal as hoped, but there getting rid of the Domain is big, as users no longer have to keep them in scope.
| if (use_fast_options) { | ||
| dt = 1; | ||
| nonlinear_options.max_iterations = 5; | ||
| linear_options.max_iterations = 5; |
There was a problem hiding this comment.
I have a silly question. For these examples, do we just run them and make sure they exit cleanly, or is there any regression testing on the actual result that comes back? If we are really just running them without checking their result at all, they are really just examples that need to keep compiling and not aborting.
There was a problem hiding this comment.
I added them as a test to simply verify they run without error, since beforehand they failed at runtime. I agree there is a chance these examples could start producing invalid answers without us knowing - as it is now.
If we were to test the result, we could use gtest, but that might be messy considering these are meant to be a reference for users. We could add some kind of assert or SLIC_ERROR_IF alternatively, but given these examples take a long time to run, it may not make sense to run the entire thing on-push. So maybe in a future PR I can work on moving these to nightly CI and add some SLIC_ERROR_IF's?
| # TODO Shorten runtime down to less than one minute | ||
| # blt_add_test(NAME contact_${example_name} | ||
| # COMMAND contact_${example_name} | ||
| # NUM_MPI_TASKS 4) |
There was a problem hiding this comment.
Do these test have a 'gold' value that we are comparing to? If not, nightly or weekly, longer running tests don't add much anyways in my view. Perhaps we need to start developing a regression testing system, where we establish some expected result to compare to. Then, weekly running tests could catch changes in behavior. Though, realistically, they should be run through CI. Maybe we need to audit our CI for bottlenecks? For example, do we currently launch our 93 test in parallel, or do they wait for eachother to complete?
4 participants
std::out_of_range#1364serac_meshtarget toserac_mesh_utils, to clarify it does not include theserac::Meshclass.serac::Meshacross all tests and examples