CFEASolver CMeshSolver maintenance#933
Conversation
|
@talbring symmetry it is not the only thing. Can we decide as a group what that is going to look like and discuss the trade-offs? Especially how it will be used, right now the deformation settings are very messy, and the code has no information regarding how/if the different motions can be combined. |
|
Sure! We also have a lot of other things to discuss. Lets organize a more structured meeting. I will open a poll for the date on slack (@ALL: please join if you haven't so far). Furthermore I will prepare an agenda. |
economon
left a comment
economon
left a comment
There was a problem hiding this comment.
LGTM. Thanks for the changes!
I think this is ready to go, and we can continue the discussion about the deformation usage as a group on slack / a call / elsewhere.
There was a problem hiding this comment.
I am having a third second look at this bit (so I won't merge it just yet).
Although the results did not change from this memory usage tweak, I think some dependencies might be lost here as this is equivalent to assuming the stiffness matrix does not depend on the reference (undeformed) mesh coordinates.
Which is also an approximation made in SU2_DOT.
…su2code/SU2 into grid_deformation_legacy_cleanup
3 participants
Proposed Changes
Implements some features that will be necessary to eventually replace the elasticity-based mesh deformation. Namely symmetry boundary condition and the use of the DEFORM_LIMIT option to limit how much of the domain is deformed.
Reduces the discrete adjoint memory usage by disabling the recording of routines that are not relevant or differentiable.
Cleans up some redundant MPI comms in CFEASolver and moves all of them to the methods of that solver (i.e. no more explicit MPI comms in structural integration / iteration).
Makes the structural objective functions available as screen/history output under the name COMBO.
Improves/fixes the incremental load approach when used for multizone problems.
Related Work
#919 #594
PR Checklist