Change handling of boundary conditions#336
Change handling of boundary conditions#336A-CGray wants to merge 28 commits intosmdogroup:masterfrom
Conversation
|
With the exception of |
|
Small thing, but can we update the docstrings in |
The error in |
|
Not sure what the issue with the unsteady adjoint is now, calling |
Should be addressed now |
Motivation
In the static problem class, we overwrite the constrained DOF with the correct Dirichlet values inside the
setVariablesmethod. This shouldn't be necessary as the boundary conditions are already accounted for in the residual and Jacobian such that the solution of the static problem automatically satisfies the BCs. Overwriting these BC values means our MPhys wrapper is not allowing OpenMDAO to set the states it thinks it is (which has the potential to cause bugs depending on how you're using TACS through MPhys). It also means we cannot perform displacement control for nonlinear solutions, since the Dirichlet BCs cannot be applied incrementally. Digging a bit deeper, I found that the reason we do this overwriting is primarily to make OpenMDAO's finite difference partial derivative checks pass for some partial derivatives terms that are not quite computed correctly by TACS as stands.addSVSens
The
addSVSensmethod of theTACSAssemblerzeroes out the derivatives of functions w.r.t DOFs that are subject to BCs, this is incorrect because the values of those DOFs still affect function values. This should mean that the MPhys tests of the function partial derivatives w.r.t states fail. However, overwriting the constrained DOF with the correct Dirichlet values inside the static problem'ssetVariablesmethod means the finite-difference partials with respect to the constrained DOF appear to be zero, matching the result ofaddSVSensand thus passing thecheck_partialstestsFor a more thorough description of the math and why I think this way of handling the BCs is more correct, see TACS Static Problem Boundary Condition Handling.pdf
Changes
New
applyBCsflag on assembly methodsI added an
applyBCsargument, which controls whether boundary conditions are applied to the resulting vector/matrix, to the followingTACSAssemblermethods, along with their corresponding Python bindings:assembleResassembleJacobianassembleMatTypeassembleMatComboevalMatSVSensInnerProductaddJacobianVecProductaddMatrixFreeVecProductThe argument defaults to true so that all the functions are backwards compatible.
Remove BC application from
addSVSensRather than adding an
applyBCsargument toaddSVSens, I just removed theapplyBCscall insideaddSVSensentirely.Unsteady adjoint fixes
Fixed the adjoint computation in the time integrators to correctly apply BCs after
addSVSens(sinceaddSVSensno longer applies them internally):applyBCscalls inTACSBDFIntegrator::initAdjointapplyBCscalls inTACSDIRKIntegrator::iterateAdjointDirichlet BC scaling factor (
lambda)A
lambdascaling parameter has been added tosetBCsandapplyBCsonTACSVec/TACSBVec(andTACSAssembler::setBCs). This scales the prescribed Dirichlet BC values, analogous to the load scaling factor we already have for external forces. This enables load control and displacement control to be performed using a single scaling factor.Static problem fixes
setBCsinsetVariablesso that we're not overwriting the states OpenMDAO thinks it is settingapplyBCscall on the adjoint solution vector after the linear solveTest updates
rtol:1e-7→1e-10, finite-differencertol:1e-2→1e-4)applyBCscall to adjoint RHS before solving, matching the corrected workflowdvNumbug in PCM element test (was hardcoded to1instead of usingdv_num)Open questions