Parallel error post processing

[orlandini]

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]

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]

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

https://github.com/labmec/neopz/blob/6cabfbbf87bb7a5bd1d5c4885adedb3827a3e2f6/Mesh/pzinterpolationspace.cpp#L1098-L1122

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]

any updates @karolinneoc ?