idaholab
Rotate UMAT
Use Euler angles (similar to rotating the elasticity tensor) to define a preferential orientation for anisotropic UMAT's. Results match with *ORIENTATION keyword in Abaqus for Hughes-Winget kinematics.
Closes #24095
tagging @recuero @dschwen
Job Documentation on 605a851 wanted to post the following:
View the site here
This comment will be updated on new commits.
Job Coverage on 605a851 wanted to post the following:
Framework coverage
Coverage did not change
Modules coverage
Solid mechanics
| 31532d | #24097 605a85 | ||||
|---|---|---|---|---|---|
| Total | Total | +/- | New | ||
| Rate | 84.92% | 84.94% | +0.01% | 100.00% | |
| Hits | 28037 | 28063 | +26 | 34 | |
| Misses | 4977 | 4977 | - | 0 | |
Full coverage reports
Reports
-
framework -
chemical_reactions -
combined -
contact -
electromagnetics -
external_petsc_solver -
fluid_properties -
fsi -
functional_expansion_tools -
geochemistry -
heat_transfer -
level_set -
misc -
navier_stokes -
optimization -
peridynamics -
phase_field -
porous_flow -
ray_tracing -
rdg -
reactor -
richards -
scalar_transport -
solid_mechanics -
solid_properties -
stochastic_tools -
thermal_hydraulics -
xfem
This comment will be updated on new commits.
thanks for the review @dschwen . I made some changes and left some comments above.
For this PR to go forward we need to have a verification against Abaqus inputs. Also the TODO cannot stand as is. It looks to me that we might just not want to support the Rashid formulation. It doesn't exist in Abaqus (right?) and just clutters up the code substantially.
For this PR to go forward we need to have a verification against Abaqus inputs.
What would this look like? Do we commit Abaqus inp files and any output from running Abaqus?
It looks to me that we might just not want to support the Rashid formulation.
Had the same thought. Not sure if having extra kinematic formulations is worth it here. Otherwise the solution might be to break up the computeQpStress method into smaller pieces based on the kinematics.
Job Precheck on d0c55c4 wanted to post the following:
Your code requires style changes.
A patch was auto generated and copied here
You can directly apply the patch by running, in the top level of your repository:
curl -s https://mooseframework.inl.gov/docs/PRs/24097/clang_format/style.patch | git apply -v
Alternatively, with your repository up to date and in the top level of your repository:
git clang-format 7fb2a3bba3c6e9a017b8b1a07688129a5e7afd4c
@dschwen I added the missing rotation for DROT. Some tests needed to be re-golded, but those only printed DROT to screen. None of the UMAT's in the tests actually use this value to compute anything.
I concur the code is a bit messy with all the conditionals and tensor copies. I'm open to ideas for cleaning it up.
As for verification against Abaqus, how should that be handled? I have done this manually using some of the print tests.
This pull request has been automatically marked as stale because it has not had recent activity in the last 100 days. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
ok @recuero @dschwen I rebased this off devel and pushed. Please take another look.
I'd like to suggest two more tests with the same setup you already used:
- Input a trivial anisotropy Euler angle orientation, i.e. '0 0 0', with and without HW.
- Check those two sets of results (maybe exodiff) against the same setup without that input line, which would trigger the 'existing' rotation handling.
If we only keep HW per @dschwen's comment (https://github.com/idaholab/moose/pull/24097#issuecomment-1523551381), then only one test would be required.
It seems that your tests are failing one recipe. I'd try modifying the tests file by adding the following:
# skip test if test is being run out-of-tree. Issue Ref: #25279
installation_type = in_tree
https://github.com/idaholab/moose/issues/25279
I'd like to suggest two more tests with the same setup you already used:
- Input a trivial anisotropy Euler angle orientation, i.e. '0 0 0', with and without HW.
- Check those two sets of results (maybe exodiff) against the same setup without that input line, which would trigger the 'existing' rotation handling.
If we only keep HW per @dschwen's comment (#24097 (comment)), then only one test would be required.
This gets into to a subtlety in Abaqus - the use of any specified orientation, even a 0 degree rotation, invokes a different rotation handling. When an orientation is specified (*ORIENTATION keyword), Abaqus continuously rotates the element back to the specified orientation to evaluate the stress, and then back to the current configuration. If no orientation is specified, the "intermediate" configuration (that's what I'm calling it) just goes along for the ride and is only off from the current configuration by no more than the current rotation increment.
This PR mimics that behavior to be consistent with Abaqus (for better or worse). We gave a lot of thought to the proper "intermediate" configuration rotation order, even for Rashid kinematics in case that is ever needed (since it is often more accurate than HW).
Having said all that, are additional tests needed over what you mentioned above?
Having said all that, are additional tests needed over what you mentioned above?
I believe that mathematically both approaches should be equivalent and MOOSE users should expect the same answer exercising both ways to some numerical tolerance. I'd be interested to have that test as a form of verification.
It seems that your tests are failing one recipe. I'd try modifying the
testsfile by adding the following:# skip test if test is being run out-of-tree. Issue Ref: #25279 installation_type = in_tree#25279
What causes the failure? I added the installation_type = in_tree option to my failed tests, but then different tests failed after I pushed.
This latest failure appears to be one related to the setup:
umat/orient_umat.hw_rotated_umat_output: ################################################################################
umat/orient_umat.hw_rotated_umat_output:
umat/orient_umat.hw_rotated_umat_output: Unable to match the following pattern against the program's output:
umat/orient_umat.hw_rotated_umat_output:
umat/orient_umat.hw_rotated_umat_output: STRESS_ 1 0.5677315\n STRESS_ 2 -1.3387362\n STRESS_ 3 -0.0439064\n STRESS_ 4 0.3203801\n STRESS_ 5 -0.0219378\n STRESS_ 6 -0.1868725\n STRAIN_ 1 0.0007858\n DSTRAIN_ 1 0.0001968\n STRAIN_ 2 -0.0011977\n DSTRAIN_ 2 -0.0002982\n STRAIN_ 3 0.0001505\n DSTRAIN_ 3 0.0000369\n STRAIN_ 4 0.0006666\n DSTRAIN_ 4 0.0001664\n STRAIN_ 5 -0.0000461\n DSTRAIN_ 5 -0.0000109\n STRAIN_ 6 -0.0003887\n DSTRAIN_ 6 -0.0000972\n COORDS_ 1 0.3915195\n COORDS_ 2 0.3857086\n COORDS_ 3 0.3873709
umat/orient_umat.hw_rotated_umat_output:
umat/orient_umat.hw_rotated_umat_output: ################################################################################
umat/orient_umat.hw_rotated_umat_output: Tester failed, reason: EXPECTED OUTPUT MISSING
This latest failure appears to be one related to the setup:
umat/orient_umat.hw_rotated_umat_output: ################################################################################ umat/orient_umat.hw_rotated_umat_output: umat/orient_umat.hw_rotated_umat_output: Unable to match the following pattern against the program's output: umat/orient_umat.hw_rotated_umat_output: umat/orient_umat.hw_rotated_umat_output: STRESS_ 1 0.5677315\n STRESS_ 2 -1.3387362\n STRESS_ 3 -0.0439064\n STRESS_ 4 0.3203801\n STRESS_ 5 -0.0219378\n STRESS_ 6 -0.1868725\n STRAIN_ 1 0.0007858\n DSTRAIN_ 1 0.0001968\n STRAIN_ 2 -0.0011977\n DSTRAIN_ 2 -0.0002982\n STRAIN_ 3 0.0001505\n DSTRAIN_ 3 0.0000369\n STRAIN_ 4 0.0006666\n DSTRAIN_ 4 0.0001664\n STRAIN_ 5 -0.0000461\n DSTRAIN_ 5 -0.0000109\n STRAIN_ 6 -0.0003887\n DSTRAIN_ 6 -0.0000972\n COORDS_ 1 0.3915195\n COORDS_ 2 0.3857086\n COORDS_ 3 0.3873709 umat/orient_umat.hw_rotated_umat_output: umat/orient_umat.hw_rotated_umat_output: ################################################################################ umat/orient_umat.hw_rotated_umat_output: Tester failed, reason: EXPECTED OUTPUT MISSING
Above that I see:
Unable to open file "/data/civet0/build/installed_copy/combined/tensor_mechanics/tests/umat/orient_umat/../../../plugins/elastic_print-opt.plugin". Check to make sure that it exists and that you have read permission.
But several other tests use that same plugin, so I don't understand what's going on there.
This pull request has been automatically marked as stale because it has not had recent activity in the last 100 days. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.
@dschwen @GiudGiud I'm working on this again and would like to get it finished up. Would you mind taking another look? Most comments are resolved but on some I'm stuck because all I can do is throw up my hands and say "that's the way Abaqus does it". I'd really like to get these changes in and if there really are efficiency improvements to be had, do those in a separate PR. I'm not sure many users will be using this feature anyway.
He's not at INL anymore from what I understand, though his input would still be greatly appreciated 😃