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

Parallel error post processing #119

Open
orlandini opened this issue Sep 27, 2021 · 3 comments
Open

Parallel error post processing #119

orlandini opened this issue Sep 27, 2021 · 3 comments
Assignees

Comments

@orlandini
Copy link
Member

The error vector is resized several times during the computation of the error. The SBFem unit test has revealed that, if a thread does not compute errors for any element, its corresponding error vector will not be resize thus leading to an error (threads with error vectors of different sizes).

Any suggestions on how to set the size of the error vec? Since it depends on the material, perhaps we could check if all the materials in the mesh have the same value for int TPZMatError::NEvalErrors() and get this value before we actually start the error processing.

@philippedevloo
Copy link
Member

Before entering the error computation, NEvalErrors() should be polled for all materials involved. If a material returns a different number of errors, DebugStop() should be called

@orlandini
Copy link
Member Author

That seems good.
Currently we have the following code at pzinterpolationspace.cpp:

auto *material = this->Material();
auto* materror =
dynamic_cast<TPZMatErrorSingleSpace<STATE> *>(this->Material());
//TPZMaterial * matptr = material.operator->();
if (!material) {
PZError << __PRETTY_FUNCTION__;
PZError << " Element wihtout material.\n";
PZError << "Aborting...\n";
DebugStop();
return;
}
if (dynamic_cast<TPZBndCond *>(material)) {
LOGPZ_INFO(logger, "Exiting EvaluateError - null error - boundary condition material.");
return;
}
if (!materror->HasExactSol()) {
PZError << __PRETTY_FUNCTION__;
PZError << " Material has no associated solution.\n";
PZError << "Aborting...\n";
DebugStop();
return;
}
const auto NErrors = materror->NEvalErrors();
errors.Resize(NErrors);
errors.Fill(0.);

Which can then be used as a guideline for the following checks:

Checks to be performed at TPZAnalysis::PostProcessError:

before switching between serial and parallel approaches:

  • All the materials involved have the TPZMatError interface
  • All the materials involved have the same value of TPZMatError::NEValErrors

Once we perform these checks, we could then clean a lot of code (mostly calls to TPZVec::Resize, but also a few other checks) from:

Code to be reviewed/General cleanup

  • TPZAnalysis::PostProcessErrorParallel
  • TPZAnalysis::PostProcessErrorSerial
  • TPZAnalysis::ThreadData::ThreadWork
  • TPZCompMesh::EvaluateError
  • TPZInterpolationSpace::EvaluateError
  • TPZElementGroup::EvaluateError
  • TPZSBFemVolumeMultiphysics::EvaluateError
  • TPZSubCompMesh::EvaluateError
  • TPZMultiphysicsCompEl::EvaluateErrorT

@philippedevloo are you ok with this? any input?

@orlandini
Copy link
Member Author

any updates @karolinneoc ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants