Conversation
d19b179 to
7ae3ea8
Compare
7ae3ea8 to
3d6591b
Compare
| * | ||
| */ | ||
| template <typename ShapeSpace, typename OutputSpace, typename... parameter_space, int... parameter_indices> | ||
| class FunctionalResidual<ShapeSpace, OutputSpace, Parameters<parameter_space...>, |
There was a problem hiding this comment.
Is FunctionalResidual descriptive enough?
There was a problem hiding this comment.
I hope the comments help, and I wouldn't really know what other words to use. The idea: its the 'residual' implemented using the serac::Functional utilities. Eventually we'll have a DfemResidual, or some such.
| } | ||
| for (auto& t : params) { | ||
| pointers.push_back(&t); | ||
| for (size_t n = 1; n < params.size(); ++n) { |
There was a problem hiding this comment.
Why is the 0 index being skipped here?
There was a problem hiding this comment.
Added a comment to explain a bit more what it happening here.
There was a problem hiding this comment.
Actually, I changed it to remove this confusion.
3d6591b to
4948a0b
Compare
…le time the spatial dimension of the problem, so that was added.
bca7142 to
c8090fb
Compare
btalamini
left a comment
There was a problem hiding this comment.
I really like how streamlined the solid residual class is now!
| { | ||
| SLIC_ERROR_IF(vjpFields.size() != fields.size(), | ||
| "Invalid number of field sensitivities relative to the number of fields"); | ||
| SLIC_ERROR_IF(vReactions.size() != 1, "Solid mechanics nonlinear system only supports 1 output residual"); |
There was a problem hiding this comment.
Says "Solid mechanics" again. If the size is 0, this error message is technically correct, but probably misleading. Consider checking size == 0 and size > 1 separately.
There was a problem hiding this comment.
I think this is fixed now
ebchin
left a comment
There was a problem hiding this comment.
Thanks @tupek2, these changes are a definite improvement over the current state of the code.
Two things to consider going forward: 1) how this will work with potential replacements for Functional and 2) how it will work with constraints/contact.
| @@ -0,0 +1,277 @@ | |||
| // Copyright (c) 2019-2024, Lawrence Livermore National Security, LLC and | |||
There was a problem hiding this comment.
Is the naming redundant here? Maybe we can remove test_ from the name, but then it's easily confused with functional_residual.hpp. Hmm, maybe just leave it.
There was a problem hiding this comment.
because its hard to tell if a file is a test, example, or library code, I've suggestion we come up with a naming convention. LiDO does something similar, we could adopt their convention, though I'm ok with this one too.
There was a problem hiding this comment.
This should be a meeting topic. I have thoughts but wont die on this hill
| using VectorSpace = serac::H1<disp_order, dim>; | ||
| using DensitySpace = serac::L2<disp_order - 1>; | ||
|
|
||
| enum STATE |
There was a problem hiding this comment.
enum class entries are not size_t, so it doesn't achieve what I'm trying to do here, which is simply give names to the indices to improve readability without having to add lies (aka, comments).
| VELO | ||
| }; | ||
|
|
||
| enum PAR |
There was a problem hiding this comment.
same, these are indented to be classical enums to index into things with names.
| serac::StateManager::newState(VectorSpace{}, "shape_displacement", mesh->tag()); | ||
| serac::FiniteElementState density = serac::StateManager::newState(DensitySpace{}, "density", mesh->tag()); | ||
|
|
||
| states = {disp, velo}; |
There was a problem hiding this comment.
Can these be moved here, or does serac::StateManager need to know they exist? Though I think there's still a copy required here, so it probably doesn't matter.
There was a problem hiding this comment.
there are all shared_ptr, I'm not worried about the copy and reference counting cost at this high of a level.
| protected: | ||
| /// @brief Utility to evaluate residual using all fields in vector | ||
| template <int... i> | ||
| auto evaluateResidual(std::integer_sequence<int, i...>, double time, const std::vector<FieldPtr>& fs) const |
There was a problem hiding this comment.
Doesn't look like this is used anywhere. Should it be removed?
There was a problem hiding this comment.
Good catch, removing. It was needed in an earlier iteration of the design, no longer.
| class SolidResidual<order, dim, Parameters<parameter_space...>, std::integer_sequence<int, parameter_indices...>> | ||
| : public Residual { | ||
| template <int order, int dim, typename... InputSpaces> | ||
| class SolidResidual<order, dim, Parameters<InputSpaces...>> |
There was a problem hiding this comment.
How does this work if we create a SolidResidual built on, say, dFEM?
There was a problem hiding this comment.
I suppose we could call this SolidFunctionalResidual, when we are there, there will be a DfemResidual, then maybe a SolidDfemResidual based on that. We can do the name changes at that point if we feel like it.
This completes some of the follow ons from the previous review (naming, _, etc.), but also extends and simplifies the use by including a serac::FunctionalResidual, which will eliminate a TON of duplication in the downstream smith new physics. Also, now SolidResidual derives from FunctionalResidual.