-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove Tetra as an option for Extruded meshes #888
Conversation
@bartgol I don't think we can expect that using wedges will produce the same results as using tets. The discretizations are different (piecewise linear for tets, piecewise bilinear for wedges), so they would converge to the same solution only as the mesh size goes to zero. If you do not see large differences between the tets and wedges solution, I would just re-bless the tests. |
The differences are all like the following:
They are all of the order of 2-3%, except for the analysis tests, which I assume are more sensitive to convergence, since there are two nonlinear solvers (NOX+ROL). If you think this kind of diffs could be attributed simply to the difference of discretizations, I can bless them. |
Yes, they look reasonable. I would bless them. |
Relative Tolerance: 1.00000000000000004e-04 | ||
Regression For Response 1: | ||
Absolute Tolerance: 1.00000000000000004e-04 | ||
Test Value: 3.907406428441e+03 | ||
Test Value: 6.422658118363e+03 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mperego This is very different though. It's almost a 2x. Is it worrisome?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a lot, at the same time I think that the flux div evaluator, used for the SMB response has been tested more for wedges than for tets. Maybe you can check if increasing the cubature rule makes any difference.
tests/landIce/FO_GIS/input_fo_gis_analysis_stiffening_memT.yaml
Outdated
Show resolved
Hide resolved
Relative Tolerance: 1.00000000000000004e-04 | ||
Regression For Response 1: | ||
Absolute Tolerance: 1.00000000000000004e-04 | ||
Test Value: 3.907406428441e+03 | ||
Test Value: 6.422658118363e+03 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a lot, at the same time I think that the flux div evaluator, used for the SMB response has been tested more for wedges than for tets. Maybe you can check if increasing the cubature rule makes any difference.
"Tetrahedron" ? 3 : 1; // number of 3D cells in one extruded 2D cell | ||
const int num_cells_per_column = num_cells_per_column_per_layer * disc_params->get<int>("NumLayers"); | ||
int basal_ws_size = extruded_ws_size / num_cells_per_column; | ||
int basal_ws_size = extruded_ws_size / disc_params->get<int>("NumLayers"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might create issues with the MPAS mesh struct. Need to check this branch with MPAS before you merge.
I created a PR in Compass to switch the tests using Tets to use Wedges. |
I think I need to wait until blake is back up. blake has more tests than weaver so I can't get the new regression values without blake. If this is a blocker, I could try setting up performance tests on attaway and get the new values there? We should probably do that anyways if we want to run large simulations there. |
Can't we take care of blake performance tests once we get it back? We're pretty convinced to switch to Wedge anyways, so I think we can adjust the performance regression tests later. |
okay maybe what I'll go ahead and do is update the weaver performance tests to use wedge once nightly albany is building again. Then this should be safe to push. Once blake is back up, I'll do the same for the rest of the tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can merge this. Both Compass and Ali_perf_tests moved to Wedges.
Running one last round of tests on mappy, to ensure the conflicts resolution during master merge didn't change things. |
FYI there's been a couple of pretty large regressions in performance on blake. One around 10/21 and another while blake was down (12/12 was the last point). I changed the test names to no longer have "tet" or "wdg" so it won't be captured in future plots (plots are constructed based on test name). But I saved the old plot. I'll try to investigate a bit. |
…a-extruded-meshes
759acb1
to
cd026d6
Compare
All tests pass on mappy. Merging. |
These tests are only enabled when ENABLE_MESH_DEPENDS_ON_PARAMETERS is ON.
This PR removes Tetra as an option for Extruded meshes. Hence, if the basal element shape is Triangle, the volume element will always be a Wedge.
This is somewhat needed in the DOF manager PR, where it has already been assumed. Having 2+ elements in each layer makes retrieval of dofs a bit more complicated.
I ran all the tests (except pyAlbany), and got some failures in FO_GIS tests, with responses/sensitivities being a bit off. I tried to increase quadrature degree and make NOX tolerance stricted, but it only improves a bit. I suspect that our current tolerances were not tight enough to make the results "converged", so there's no hope to get a match. I'm going to verify this next week, by taking a test in master, and bumping up quadrature degree while making NOX tolerances stricter. This way, I should get an "exact" response/sensitivity from master, which should match the ones I get in this branch.
@mperego I am assuming that, provided that the quadrature/tolerances are strict enough, all the responses at the top/bottom with Tets (master) should match the values with Wedges (branch). I feel like the FE approx on the top/bottom should be the same for Tets/Wedges, but I am not expert enough in what Intrepid2 does with Wedges. Is my assumption correct? If not, then it's possible we cannot get an exact match with current master, no matter how strict the convergence is.