Conversation
Now materials of type TPZMatSingleSpaceBC can also print their solution
|
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;} |
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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
Lines 89 to 104 in 1fb1c08
Material/TPZBndCondBase.h
Outdated
| [[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 |
There was a problem hiding this comment.
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
| uint64_t &du_col) const override; | ||
| void Solution(const TPZMaterialDataT<TVar> &data, | ||
| int var, TPZVec<TVar> &solOut) override; | ||
| void SolutionBC(const TPZMaterialDataT<TVar> &data, |
There was a problem hiding this comment.
This large number of "extra methods" couldn't be hidden in one of the "Interfaces"? A material that implements a BC post processing interface?
There was a problem hiding this comment.
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(); | |||
| } | |||
|
|
|||
There was a problem hiding this comment.
The method SolutionBC could be avoided if SolutionBC existed in an interface?
There was a problem hiding this comment.
I am not sure what you mean, could you please elaborate?
|
The interface would only exist for SingleSpaces? Shouldn't it exist for CombinedSpaces as well? |
|
@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. |
14a6292 to
303538f
Compare
303538f to
ec1635d
Compare
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) constvirtual 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 finalApart from this, one check was removed in
TPZAnalysis.cpp.For seeing it in action, check the updated target
HCurlProjectionofNeoPZExamples: https://github.com/labmec/NeoPZExamples/blob/main/Tutorial/Projections/HCurlProjection.cpp