QuadShell9 support (which also fixes QuadShell8 refinement...) and shell unit tests #3886
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I don't actually directly need this myself, but it's in ExodusII so someone might need it, and it's the easiest way to fix a bug where we don't support QUADSHELL8 refinement.
|
Aha. MOOSE is already using QuadShell8 elements indirectly (via loading a QuadShell4 .e and requesting Unless it was deliberate? Pinging @GiudGiud , who added |
|
no this was not deliberate. I didnt know QuadShells were in use in NS. This must be cubit's doing |
|
Yeah, apparently Cubit outputs shell elements by default for 2D. I'll set up a PR to switch it. |
roystgnr
added a commit
to roystgnr/moose
that referenced
this pull request
Jun 25, 2024
Refs idaholab#27974 Guillaume reports that we ended up with shell elements instead of quad elements here by accident, because it was a Cubit default for 2D output. The elements solve the same way, *except* that with old libMesh a "full-order" `all_second_order()` update to a 4-node shell would produce an 8-node shell, not a 9-node, and we'd like to change that without breaking MOOSE tests. This should let us get libMesh/libmesh#3886 passing and make that change. I generated the new `expansion_quad.e` by using ncdump, changing `SHELL4` to `QUAD4`, deleting 2 from sideset indices (since Exodus quad shell edge-sides are numbered 3-6 instead of 1-4), and using ncgen. We did expect the csv results to change here, since we're now using a biquadratic basis rather than a serendipity basis when the `second_order` conversion adds the internal nodes.
jmeier
pushed a commit
to jmeier/moose
that referenced
this pull request
Jun 26, 2024
Refs idaholab#27974 Guillaume reports that we ended up with shell elements instead of quad elements here by accident, because it was a Cubit default for 2D output. The elements solve the same way, *except* that with old libMesh a "full-order" `all_second_order()` update to a 4-node shell would produce an 8-node shell, not a 9-node, and we'd like to change that without breaking MOOSE tests. This should let us get libMesh/libmesh#3886 passing and make that change. I generated the new `expansion_quad.e` by using ncdump, changing `SHELL4` to `QUAD4`, deleting 2 from sideset indices (since Exodus quad shell edge-sides are numbered 3-6 instead of 1-4), and using ncgen. We did expect the csv results to change here, since we're now using a biquadratic basis rather than a serendipity basis when the `second_order` conversion adds the internal nodes.
jwpeterson
approved these changes
Jun 27, 2024
jwpeterson
approved these changes
Jun 27, 2024
abanki1
pushed a commit
to abanki1/moose
that referenced
this pull request
Jul 11, 2024
Refs idaholab#27974 Guillaume reports that we ended up with shell elements instead of quad elements here by accident, because it was a Cubit default for 2D output. The elements solve the same way, *except* that with old libMesh a "full-order" `all_second_order()` update to a 4-node shell would produce an 8-node shell, not a 9-node, and we'd like to change that without breaking MOOSE tests. This should let us get libMesh/libmesh#3886 passing and make that change. I generated the new `expansion_quad.e` by using ncdump, changing `SHELL4` to `QUAD4`, deleting 2 from sideset indices (since Exodus quad shell edge-sides are numbered 3-6 instead of 1-4), and using ncgen. We did expect the csv results to change here, since we're now using a biquadratic basis rather than a serendipity basis when the `second_order` conversion adds the internal nodes.
N4hom
pushed a commit
to N4hom/moose
that referenced
this pull request
Jul 30, 2024
Refs idaholab#27974 Guillaume reports that we ended up with shell elements instead of quad elements here by accident, because it was a Cubit default for 2D output. The elements solve the same way, *except* that with old libMesh a "full-order" `all_second_order()` update to a 4-node shell would produce an 8-node shell, not a 9-node, and we'd like to change that without breaking MOOSE tests. This should let us get libMesh/libmesh#3886 passing and make that change. I generated the new `expansion_quad.e` by using ncdump, changing `SHELL4` to `QUAD4`, deleting 2 from sideset indices (since Exodus quad shell edge-sides are numbered 3-6 instead of 1-4), and using ncgen. We did expect the csv results to change here, since we're now using a biquadratic basis rather than a serendipity basis when the `second_order` conversion adds the internal nodes.
Leni-Yeo
pushed a commit
to Leni-Yeo/moose
that referenced
this pull request
Aug 28, 2024
Refs idaholab#27974 Guillaume reports that we ended up with shell elements instead of quad elements here by accident, because it was a Cubit default for 2D output. The elements solve the same way, *except* that with old libMesh a "full-order" `all_second_order()` update to a 4-node shell would produce an 8-node shell, not a 9-node, and we'd like to change that without breaking MOOSE tests. This should let us get libMesh/libmesh#3886 passing and make that change. I generated the new `expansion_quad.e` by using ncdump, changing `SHELL4` to `QUAD4`, deleting 2 from sideset indices (since Exodus quad shell edge-sides are numbered 3-6 instead of 1-4), and using ncgen. We did expect the csv results to change here, since we're now using a biquadratic basis rather than a serendipity basis when the `second_order` conversion adds the internal nodes.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hopefully this will fix idaholab/moose#27974 as well; it at least passes our standard Elem unit tests now. Previously QuadShell8 would fail on the refinement tests, because in the bracketing-nodes calculation where a Quad8 would use a Quad9 to "steal" its middle node, a QuadShell8 would just fail.