Skip to content
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

Add elastic inversion capability using batch materials #353

Closed
wants to merge 4 commits into from

Conversation

dewenyushu
Copy link
Collaborator

Initial demonstration of stress gradient calculation using batch material in the elastic material inversion problem.

@dewenyushu
Copy link
Collaborator Author

dewenyushu commented Jun 9, 2023

ping @zachmprince and @lynnmunday

@moosebuild
Copy link

moosebuild commented Jun 12, 2023

Job Test on 42897d3 wanted to post the following:

View the site here

This comment will be updated on new commits.

@dewenyushu dewenyushu force-pushed the elastic_inversion branch 4 times, most recently from bcb47f0 to 6028552 Compare June 15, 2023 20:03
Copy link
Contributor

@hugary1995 hugary1995 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, thanks!

doc/content/source/userobjects/BatchStressGrad.md Outdated Show resolved Hide resolved
doc/content/source/userobjects/BatchStressGrad.md Outdated Show resolved Hide resolved

## Description

This `VectorPostprocessor` computes the gradient of objective function with respect to interested parameter for elastic problem. Specifically,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First state the objective function please.

\begin{equation}
\frac{\text{d}\boldsymbol{F}}{\text{d}p} = - \int \underbrace{(\boldsymbol{L}\lambda)^T}_{\text{adjoint strain}} \underbrace{\frac{\partial \boldsymbol{C}}{\partial p} (\boldsymbol{L} u)}_{\text{stress gradient}} \text{d}\Omega,
\end{equation}
where $\boldsymbol{F}$ is the objective function, $\boldsymbol{L}$ is the differential operator for the elasticity problem, $\lambda$ is the adjoint displacement, $\boldsymbol{C}$ is the elastic tensor, $p$ is the interested parameter, and $u$ is displacement from the forward problem.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
where $\boldsymbol{F}$ is the objective function, $\boldsymbol{L}$ is the differential operator for the elasticity problem, $\lambda$ is the adjoint displacement, $\boldsymbol{C}$ is the elastic tensor, $p$ is the interested parameter, and $u$ is displacement from the forward problem.
where $\boldsymbol{F}$ is the objective function, $\boldsymbol{L}$ is the symmetric strain operator for the elasticity problem, $\lambda$ is the adjoint displacement, $\boldsymbol{C}$ is the elasticity tensor, $p$ is the interested parameter, and $u$ is displacement from the forward problem.

It's not clear to me from this description whether p should be a scalar-valued property or can be vector-valued (or a set of scalar-valued properties). I guess I can find out in the actual source codes...

\end{equation}
where $\boldsymbol{F}$ is the objective function, $\boldsymbol{L}$ is the differential operator for the elasticity problem, $\lambda$ is the adjoint displacement, $\boldsymbol{C}$ is the elastic tensor, $p$ is the interested parameter, and $u$ is displacement from the forward problem.

Specifically, this object takes the `adjoint strain` and the `stress gradient` as inputs, computes the double contraction of the two inputs, and integrate over the entire domain. Specifically, the `adjoint strain` is the strain from the adjoint problem, the `stress gradient` should be a batch material (e.g., [BatchStressGrad](/BatchStressGrad.md)).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get a heart attack every time I see "stress gradient", but then later realize that you really mean the derivative of stress w.r.t. the the parameters which is an entirely different story.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haha, sorry about the confusion. Yeah I meant the gradient of stress wrt to the interested parameter here but wanted it to be concise. I'll use gradient of stress w.r.t. parameter to hopefully avoid further confusion.

// tuple representation
BatchMaterialUtils::TupleStd,
// output data type
RankTwoTensor,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So... this implies that p is a scalar-valued property. This is fine for now.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When is p not scalar valued?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will need multiple such objects for each p component for that case

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ya, as Dewen said we need multiple instances of the object to calculate the derivatives w.r.t. each p, for example we need two objects for the two Lame parameters (more when the stress-strain relation has more parameters). I feel like there will be an overhead in doing this. But I'm not sure how much that overhead will cost us.

{
auto params = BatchStressGradParent::validParams();
params.addRequiredParam<MaterialPropertyName>(
"elastic_tensor_derivative", "Name of the elastic tensor derivative material property.");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"elastic_tensor_derivative", "Name of the elastic tensor derivative material property.");
"elasticity_tensor_derivative", "Name of the elasticity tensor derivative material property.");

here and a few other places: there's no such a thing called elastic tensor.


void
BatchStressGrad::batchCompute()
{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps a comment here or in the header stating that this is a placeholder until we can swap this out for "actually" batched computation.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, will do!

params.addRequiredParam<MaterialPropertyName>(
"adjoint_strain_name", "Name of the strain property in the adjoint problem");

params.addClassDescription("Compute the gradient for elastic material inversion");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
params.addClassDescription("Compute the gradient for elastic material inversion");
params.addClassDescription("Compute the parameter gradient for linear elastic material inversion");

dewenyushu and others added 2 commits June 19, 2023 08:52
Co-authored-by: Gary (Tianchen) Hu <thu@anl.gov>
Co-authored-by: Gary (Tianchen) Hu <thu@anl.gov>
@moosebuild
Copy link

Job Precheck on 87062dd 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/blackbear/docs/PRs/353/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 256094a972d35961f4c4df64c7139b59fc2f51a7

@dewenyushu
Copy link
Collaborator Author

@hugary1995 Thanks for your review! I guess this indicates a viable path towards using NEML stress derivatives in inverse optimization problems? ;)

If so I'll focus on resolving the civet tests failures and ping you again once I think it is ready

@hugary1995
Copy link
Contributor

@hugary1995 Thanks for your review! I guess this indicates a viable path towards using NEML stress derivatives in inverse optimization problems? ;)

Yes, I see that you are getting correct answers in the regression test :)
I'll be working on NEML2 next month.

If so I'll focus on resolving the civet tests failures and ping you again once I think it is ready

Yes, please.

@@ -19,6 +19,8 @@ Content:
root_dir: ${MOOSE_DIR}/modules/stochastic_tools/doc/content
ray_tracing:
root_dir: ${MOOSE_DIR}/modules/ray_tracing/doc/content
optimization:
root_dir: ${MOOSE_DIR}/modules/optimization/doc/content

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add this to the modules:/content: list below:

          - help/development/analyze_jacobian.md

@@ -83,6 +85,7 @@ Extensions:
misc: !include ${MOOSE_DIR}/modules/misc/doc/sqa_misc.yml
xfem: !include ${MOOSE_DIR}/modules/xfem/doc/sqa_xfem.yml
ray_tracing: !include ${MOOSE_DIR}/modules/ray_tracing/doc/sqa_ray_tracing.yml
optimization: !include ${MOOSE_DIR}/modules/optimization/doc/sqa_optimization.yml

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add this to enable the algorithm extension:

  MooseDocs.extensions.algorithm:
      active: True

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool! Thanks Zach!

@moosebuild
Copy link

moosebuild commented Jun 21, 2023

Job Coverage on 42897d3 wanted to post the following:

Coverage

af945f #353 42897d
Total Total +/- New
Rate 94.25% 94.29% +0.04% 96.77%
Hits 1736 1766 +30 30
Misses 106 107 +1 1

Diff coverage report

Full coverage report

This comment will be updated on new commits.

@dewenyushu
Copy link
Collaborator Author

This should be ready @hugary1995

Copy link
Contributor

@hugary1995 hugary1995 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. I only have one question.

Comment on lines +15 to +19
The gradient of objective function with respect to one scalar parameter ($p_i$) is
\begin{equation}
\frac{\text{d}{F}}{\text{d}p_i} = - \int \underbrace{(\boldsymbol{L}\lambda)^T}_{\text{adjoint strain}} \underbrace{\frac{\partial \boldsymbol{C}}{\partial p_i} (\boldsymbol{L} u)}_{\text{gradient of stress}} \text{d}\Omega,
\end{equation}
where ${F}$ is the objective function, $\boldsymbol{L}$ is the symmetric strain operator for the elasticity problem, $\lambda$ is the adjoint displacement, $\boldsymbol{C}$ is the elasticity tensor, and $p_i$ is the interested scalar parameter.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens to the regularization term? Do we assume it to be zero, or perhaps dR/dp is handled elsewhere?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regularization, I believe, will happen on the main app side. Either in the solver or in the evaluation of the objective function. But we haven't implemented anything concretely yet. As such, I don't think it will be the model app's responsibility for computing the gradient.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. So I would envision some basic regularizations implemented in moose/modules/optimization, and each app could inherit and implement their own regularizations.

Either way, I think the regularization term will be handled by a different object, and so this documentation doesn't need any modification in that regard.

InputParameters
BatchStressGrad::validParams()
{
auto params = BatchStressGradParent::validParams();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will you add a addClassDescription? Or is this going to be a test/src object?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. Just did!

// tuple representation
BatchMaterialUtils::TupleStd,
// output data type
RankTwoTensor,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When is p not scalar valued?

@lynnmunday
Copy link
Collaborator

@bwspenc or @dschwen Would one of you look at this PR. This is how we would like to interface with NEML2 for material parameter derivatives for inverse optimization.

@@ -0,0 +1,33 @@
//* This file is part of the MOOSE framework
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These files will all need the BlackBear header

@lynnmunday
Copy link
Collaborator

@dewenyushu we need to try moving this to isopod and include blackbear with isopod.

@dewenyushu
Copy link
Collaborator Author

Move contributions to idaholab/isopod#78

@dewenyushu dewenyushu closed this Jun 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants