Skip to content

Solution on boundary elements#138

Open
orlandini wants to merge 8 commits intodevelopfrom
SolOnBoundaryEls
Open

Solution on boundary elements#138
orlandini wants to merge 8 commits intodevelopfrom
SolOnBoundaryEls

Conversation

@orlandini
Copy link
Member

@orlandini orlandini commented Jan 27, 2022

This PR adds support for visualization of the solution on boundary elements for materials deriving from TPZMatSingleSpace.
For this, the following methods were created:

  • [[nodiscard]] virtual int TPZMaterial::NSolutionVariablesBC(int var) const
  • virtual void TPZMaterialSingleSpaceT::SolutionBC(const TPZMaterialDataT<TVar> &data, int var, TPZVec<TVar> &sol)
  • [[nodiscard]] int TPZBndCondBase::NSolutionVariables(int var) const final
  • [[nodiscard]] int TPZBndCondBase::VariableIndex(const std::string &name) const final
    Apart from this, one check was removed in TPZAnalysis.cpp.

For seeing it in action, check the updated target HCurlProjection of NeoPZExamples : https://github.com/labmec/NeoPZExamples/blob/main/Tutorial/Projections/HCurlProjection.cpp

@gustavobat
Copy link
Member

That seems very neat, @orlandini. I don't see any caveat and therefore approve this PR.


[[nodiscard]] int Dimension() const final
{return this->fMaterial->Dimension();}
{return this->fMaterial->Dimension() - 1;}
Copy link
Member

Choose a reason for hiding this comment

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

The object bndcond cant have its own dimension attribute?
I still can't figure out how TPZBndCond functions. I must have studied it at least 5 times...

Copy link
Member Author

Choose a reason for hiding this comment

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

It could have, yes. and I think it would be a nice contribution if anyone is willing to write it.

regarding how TPZBndCond works: it is simply an interface. Any actual boundary condition material will be of type:
TPZBndCondBase<TVar, typename Interfaces::TInterfaceBC...>, inheriting from TPZMaterialT, TPZBndCondT and any additional interfaces.

This is performed in

template<class TVar, class... Interfaces>
template<class... AddInterfaces>
TPZBndCondT<TVar> *
TPZMatBase<TVar, Interfaces...>::CreateBCImpl(TPZMaterial *reference, int id, int type, const TPZFMatrix<TVar> &val1,
const TPZVec<TVar> &val2) {
return new TPZBndCondBase<TVar, typename Interfaces::TInterfaceBC...,
typename AddInterfaces::TInterfaceBC...>(reference, id, type, val1, val2);
}
template<class TVar, class... Interfaces>
TPZBndCondT<TVar> *TPZMatBase<TVar, Interfaces...>::CreateBC(TPZMaterial *ref, int id, int type,
const TPZFMatrix<TVar> &val1, const TPZVec<TVar> &val2) {
return CreateBCImpl<>(ref, id, type, val1, val2);
}

[[nodiscard]] int NSolutionVariables(int var) const final
{ return this->fMaterial->NSolutionVariablesBC(var);}
/** @brief Returns the variable index associated with a given name */
[[nodiscard]] int VariableIndex(const std::string &name) const final
Copy link
Member

Choose a reason for hiding this comment

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

If there is a NSolutionVariablesBC method then there should exist a VariableIndexBC method also. Adopting the variable index of the material is imprudent. There are many post processed quantities that cant be generated for a boundary condition

Copy link
Member Author

Choose a reason for hiding this comment

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

addressed in 66d107f

uint64_t &du_col) const override;
void Solution(const TPZMaterialDataT<TVar> &data,
int var, TPZVec<TVar> &solOut) override;
void SolutionBC(const TPZMaterialDataT<TVar> &data,
Copy link
Member

Choose a reason for hiding this comment

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

This large number of "extra methods" couldn't be hidden in one of the "Interfaces"? A material that implements a BC post processing interface?

Copy link
Member Author

Choose a reason for hiding this comment

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

There are 4 extra methods. Creating specific interfaces for that would require additional changes in the post processing routines.

@@ -57,6 +57,17 @@ void TPZMatSingleSpaceT<TVar>::Solution(const TPZMaterialDataT<TVar> &data, int
DebugStop();
}

Copy link
Member

Choose a reason for hiding this comment

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

The method SolutionBC could be avoided if SolutionBC existed in an interface?

Copy link
Member Author

Choose a reason for hiding this comment

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

I am not sure what you mean, could you please elaborate?

@philippedevloo
Copy link
Member

The interface would only exist for SingleSpaces? Shouldn't it exist for CombinedSpaces as well?
I believe defining an "interfacePostProbBCSS" and "interfacePostProcCS" would be a "cleaner" solution

@orlandini
Copy link
Member Author

@philippedevloo since post processing the solution on the domain itself is not part of an additional interface, I've opted to do the same for the solution on the boundaries, since this would require additional changes in several methods related to post processing operations.

Regarding CombinedSpaces, yes, it would work just the same, if someone is willing to implement it I think this PR gives a good guideline.

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.

3 participants