These aren't limited to just functions of "t" anymore; rename these.

Member _IFT_RotatingBoundary_frequency

Unused ( But it makes sense that you'd have this, can you check it Andreas? ) / Mikael

The history parameter determines how many time steps to remember.

FieldType and UnknownType basically determine the same thing. Should be possible to stick to one. Combinations of fields should be possible with logical bitfields.

Namespace oofem

We shouldn't have this for assembling vectors or matrices(!) / Mikael

Replace abort() with OOFEM_ERROR

Member oofem::AbaqusUserMaterial::give3dMaterialStiffnessMatrix (MatResponseMode mode, GaussPoint *gp, TimeStep *tStep) const override

Make this hack fit more nicely into OOFEM in general;

Member oofem::AbaqusUserMaterial::give3dMaterialStiffnessMatrix_dPdF (MatResponseMode mode, GaussPoint *gp, TimeStep *tStep) const override

Make this hack fit more nicely into OOFEM in general;

Member oofem::AbaqusUserMaterial::giveFirstPKStressVector_3d (const FloatArrayF< 9 > &vF, GaussPoint *gp, TimeStep *tStep) const override

Check this. I'm just guessing. Maybe intrinsic time instead?

Right default value? umat routines may change this (although we ignore it)

Large deformations?

Include the characteristic element length

No idea about these parameters

Member oofem::AbaqusUserMaterial::giveRealStressVector_3d (const FloatArrayF< 6 > &strain, GaussPoint *gp, TimeStep *tStep) const override

Check this. I'm just guessing. Maybe intrinsic time instead?

Right default value? umat routines may change this (although we ignore it)

Include the characteristic element length

No idea about these parameters

Member oofem::AdaptiveNonLinearStatic::assembleInitialLoadVector (FloatArray &loadVector, FloatArray &loadVectorOfPrescribed, AdaptiveNonLinearStatic *sourceProblem, int domainIndx, TimeStep *tStep)

Likely memory leak here with new TimeStep; Check.

Member oofem::AnisotropicDamageMaterial::giveRealStressVector (FloatArray &answer, GaussPoint *gp, const FloatArray &reducedStrain, TimeStep *tStep) const override

check if computeTraceD is necessary and check its implementation

Member oofem::AxisymElement::computeBHmatrixAt (GaussPoint *gp, FloatMatrix &answer) override

not checked if correct, is dw/dz = u/r for large deformations? /JB

Member oofem::AxisymElement::computeStressVector (FloatArray &answer, const FloatArray &strain, GaussPoint *gp, TimeStep *tStep) override

This won't work properly with "useUpdatedGpRecord" (!)

Member oofem::B3SolidMaterial::giveEModulus (GaussPoint *gp, TimeStep *tStep) const override

THREAD UNSAFE!

Member oofem::BCTracker::initialize ()

Should we have a seperate entry for edge loads? Just sticking to the general "boundaryload" for now.

Member oofem::Beam3d::giveIntegrationDomain () const override

Introduce interpolator and remove these two:

Member oofem::BodyFluxFunctor::evaluate (FloatArray &answer, const FloatArray &lcoords, MPElement &cell, const Variable *testField, TimeStep *tStep) const override

Make sure this part is correct.

Member oofem::BondCEBMaterial::give3dStiffnessMatrix_Eng (MatResponseMode rMode, GaussPoint *gp, TimeStep *tStep) const override

Only elastic tangent supported

Member oofem::BoundaryCondition::setPrescribedValue (double s)

This function isn't as meaningful anymore. Possibly keep it if we change it to a vector. No inheriting b.c.s can overload this in a meaningful way.

Member oofem::BoundaryFluxFunctor::evaluate (FloatArray &answer, const FloatArray &lcoords, MPElement &cell, const Variable *testField, TimeStep *tStep) const override

Make sure this part is correct.

Member oofem::BSplineInterpolation::giveNumberOfKnotSpanBasisFunctions (const IntArray &knotSpan) const override

This loop seems meaningless. It just returns degree[nsd-1]+1 in the end ?

Member oofem::CBS::giveTractionPressure (Dof *dof)

This should just disappear completely.

Member oofem::CCTPlate::computeVolumeAround (GaussPoint *gp) override

What about thickness?

Member oofem::CebFipSlip90Material::giveEngTraction_1d (double jump, GaussPoint *gp, TimeStep *tStep) const override

This isn't slip, this is the normal displacement. This code should be rewritten to deal with a 3D jump.

Member oofem::CemhydMatStatus::AnalyticHomogenizationPaste (double &E, double &nu, int perc_unperc_flag)

What is this supposed to do?

Member oofem::Circle::computeIntersectionPoints (Element *element, std ::vector< FloatArray > &oIntersectionPoints) override

Move semantics or something would be useful here to avoid multiple copies.

Member oofem::CommBuffType

Document this

Class oofem::CompoDamageMat

This class should overload give1dMaterialStiffMtrx

Member oofem::CompoDamageMat::checkSnapBack (GaussPoint *gp, MaterialMode mMode) const

Check value here for 1d mat (old broken code used undeclared variable)

Member oofem::Concrete3::giveCrackingModulus (MatResponseMode rMode, GaussPoint *gp, double crackStrain, int i) const override

This isn't used. Is it right?! / Micke

Member oofem::ConcreteDPM2::computeRateFactor (double alpha, double timeFactor, GaussPoint *gp, TimeStep *deltaTime) const

CHECK

Class oofem::ContextIOERR

Document more.

Class oofem::ConvergenceException

A material, an element, or another object can throw an exception when convergence of a local algorithm, e.g., return mapping algorithm is lost to indicate step reduction. The engineering model catch the exception and call timestepcontroller to do an appropriate action such as the cut of the step

Class oofem::DataStream

Are the "long" and "unsigned long" functions really necessary?

Member oofem::DEIDynamic::solveYourselfAt (TimeStep *tStep) override

This rotation matrix is not flexible enough.. it can only work with full size matrices and doesn't allow for flexibility in the matrixassembler.

Member oofem::Delamination::appendInputRecords (DynamicDataReader &oDR) override

almost everything is copied from EnrichmentItem :: giveInputRecord, should be written in a better way

Class oofem::DGProblem

Documentation errors (there is no "UnknownsField" used here).

Member oofem::DGProblem::requiresEquationRenumbering (TimeStep *tStep) override

This method should be set as the default behavior instead of relying on a user specified flag. Then this function should be removed.

Member oofem::DGProblem::updateSolution (FloatArray &solutionVector, TimeStep *tStep, Domain *d) override

NRSolver should report when the solution changes instead of doing it this way.

Need to reset the boundary conditions properly since some "update" is doing strange things such as applying the (wrong) boundary conditions. This call will be removed when that code can be removed.

Member oofem::DIIDynamic::timesMtrx (FloatArray &answer, FloatArray &vec, CharType type, Domain *domain, TimeStep *tStep)

This rotation matrix is not flexible enough.. it can only work with full size matrices and doesn't allow for flexibility in the matrixassembler.

Member oofem::DirectErrorIndicatorRC::exchangeDofManDensities ()

Compute local shared dofman densities

Member oofem::DirectErrorIndicatorRC::exchangeDofManIndicatorVals (TimeStep *tStep)

Compute local shared dofman indicator values

Member oofem::DKTPlate::computeVolumeAround (GaussPoint *gp) override

What about thickness?

Member oofem::Dof::packUnknowns (DataStream &buff, ValueModeType mode, TimeStep *tStep)

Remove this? It is not inherited by MasterDof. Is this leftovers? / Mikael

Member oofem::Dof::unpackAndUpdateUnknown (DataStream &buff, ValueModeType mode, TimeStep *tStep)

Remove this? It is not inherited by MasterDof. Is this leftovers? / Mikael

Member oofem::DofManager::computeM2LTransformation (FloatMatrix &answer, const IntArray &dofIDArry)

I don't think this should be called like this since it relies on the order of the dofs.

Member oofem::DofManager::givePrescribedUnknownVector (FloatArray &answer, const IntArray &dofMask, ValueModeType mode, TimeStep *tStep)

Remove all usage of this. Just ask for the unknown vector instead, they are the same.

Member oofem::DofManager::restoreContext (DataStream &stream, ContextMode mode) override

Smart pointers would be nicer here

Member oofem::Domain::clear ()

bp: how to clear/reset topology data?

Member oofem::Domain::commitTransactions (DomainTransactionManager *tm)

This is really quite bad. We shouldn't do unique ptrs like this (we have the same ptr in 2 different unique_ptrs!!!)

Member oofem::Domain::createDofs ()

This will eventually not be optional.

Remove this input method whenever we decide on deprecating the old approach.

This will eventually not be optional.

Remove this input method whenever we decide on deprecating the old approach.

Member oofem::Domain::Domain (int n, int serNum, EngngModel *e)

This seems like dead, old unused code. Remove it? / Mikael

Member oofem::Domain::initializeFinish ()

Eventually remove this backwards compatibility:

Member oofem::Domain::instanciateYourself (DataReader &dr, InputRecord &ir)

Change this to default 0 when the domaintype record has been removed.

Member oofem::Domain::mDomainType

I don't see why this has to be stored, and there is only one? /Mikael

Member oofem::Domain::restoreContext (DataStream &stream, ContextMode mode)

Saving and restoring xfemmanagers.

Member oofem::dot (const FloatMatrixF< N, M > &a, const FloatMatrixF< M, P > &b)

BLAS for larger matrix sizes (maybe)

Member oofem::dotT (const FloatMatrixF< N, M > &a, const FloatMatrixF< P, M > &b)

BLAS for larger matrix sizes (maybe)

Member oofem::DruckerPragerCutMat::giveIPValue (FloatArray &answer, GaussPoint *gp, InternalStateType type, TimeStep *tStep) override

Actually export the relevant damage value here!

Member oofem::DustMaterial::giveIPValue (FloatArray &answer, GaussPoint *gp, InternalStateType type, TimeStep *tStep) override

This is actually the mean, not the volumetric part. / Mikael

Class oofem::DynamicDataReader

InputRecordType is ignored. It shouldn't be too difficult to respect it, but it's not necessary.

Member oofem::DynamicInputRecord::DynamicInputRecord (const DynamicInputRecord &)

Make FEMComponent const

Member oofem::DynamicInputRecord::finish (bool wrn=true) override

Implement warning about unread entries

Member oofem::EIPrimaryFieldInterface::EIPrimaryFieldI_evaluateFieldVectorAt (FloatArray &answer, PrimaryField &pf, const FloatArray &coords, IntArray &dofId, ValueModeType mode, TimeStep *tStep)=0

This should use local coordinates instead of having all elements search for it manually.

Shouldn't this just be part of Element? It's very much the core of functionality for elements.

Member oofem::EIPrimaryUnknownMapper::mapAndUpdate (FloatArray &answer, ValueModeType mode, Domain *oldd, Domain *newd, TimeStep *tStep) override

Shouldn't we pass a primary field or something to this function?

This doesn't respect local coordinate systems in nodes. Supporting that would require major reworking.

Member oofem::Element::computeBoundaryEdgeLoadVector (FloatArray &answer, BoundaryLoad *load, int edge, CharType type, ValueModeType mode, TimeStep *tStep, bool global=true)

Change the load type to "BoundaryEdgeLoad" maybe?

Member oofem::Element::computeVectorOf (const IntArray &dofIDMask, ValueModeType u, TimeStep *tStep, FloatArray &answer, bool padding=false)

This rotation matrix needs to have the dofidmask/eid/primary field or something passed to it, otherwise it won't work generally.

Member oofem::Element::dofManArray

We should remove this parameter. It's redundant (and therefore possibly wrong) since the dofManArray stores it's length internally.

Member oofem::Element::giveGlobalIPValue (FloatArray &answer, GaussPoint *gp, InternalStateType type, TimeStep *tStep)

Check transpose here

Member oofem::Element::giveIntegrationRuleLocalCodeNumbers (IntArray &answer, IntegrationRule &ie)

This is currently not used. It is intended for IGA elements? This seems redundant.

Member oofem::Element::giveIPValue (FloatArray &answer, GaussPoint *gp, InternalStateType type, TimeStep *tStep)

Which "error type" should be used? Why are there several? I don't see the point of this enum when there could be different function calls just as well (and different IST values)

Member oofem::Element::giveNumberOfBoundarySides ()

Just ask the interpolator instead?

Member oofem::Element::giveSpatialDimension ()

Just ask the interpolator instead?

Member oofem::EngngModel::assemble (SparseMtrx &answer, TimeStep *tStep, const MatrixAssembler &ma, const UnknownNumberingScheme &s, Domain *domain)

This rotation matrix is not flexible enough.. it can only work with full size matrices and doesn't allow for flexibility in the matrixassembler.

Member oofem::EngngModel::assemble (SparseMtrx &answer, TimeStep *tStep, const MatrixAssembler &ma, const UnknownNumberingScheme &r_s, const UnknownNumberingScheme &c_s, Domain *domain)

This rotation matrix is not flexible enough.. it can only work with full size matrices and doesn't allow for flexibility in the matrixassembler.

Member oofem::EngngModel::assembleExtrapolatedForces (FloatArray &answer, TimeStep *tStep, CharType type, Domain *domain)

This is not perfect. It is probably no good for viscoelastic materials, and possibly other scenarios that are rate dependent (tangent will be computed for the previous step, with whatever deltaT it had)

Deal with element deactivation and reactivation properly.

Member oofem::EngngModel::assemblePrescribedExtrapolatedForces (FloatArray &answer, TimeStep *tStep, CharType type, Domain *domain)

This is not perfect. It is probably no good for viscoelastic materials, and possibly other scenarios that are rate dependent (tangent will be computed for the previous step, with whatever deltaT it had)

Deal with element deactivation and reactivation properly.

Member oofem::EngngModel::assembleVectorFromDofManagers (FloatArray &answer, TimeStep *tStep, const VectorAssembler &va, ValueModeType mode, const UnknownNumberingScheme &s, Domain *domain, FloatArray *eNorms=NULL)

This should be removed when loads are given through sets.

Member oofem::EngngModel::assembleVectorFromElements (FloatArray &answer, TimeStep *tStep, const VectorAssembler &va, ValueModeType mode, const UnknownNumberingScheme &s, Domain *domain, FloatArray *eNorms=NULL)

Checking the chartype is not since there could be some other chartype in the future. We need to try and deal with chartype in a better way. For now, this is the best we can do.

Consider using private answer variables and sum them up at the end, but it just might be slower then a shared variable.

Member oofem::EngngModel::newDofHandling ()

When all models have converted to using a field, this should be removed.

Member oofem::EngngModel::packDofManagers (ArrayWithNumbering *src, ProcessCommunicator &processComm)

Shouldn't hardcode domain number 1

Must fix: Internal dofmanagers in xfem and bc

Member oofem::EngngModel::printOutputAt (FILE *file, TimeStep *tStep, const IntArray &nodeSets, const IntArray &elementSets)

Add general support for reaction forces

Member oofem::EngngModel::unpackDofManagers (ArrayWithNumbering *dest, ProcessCommunicator &processComm)

Shouldn't hardcode domain number 1

Must fix: Internal dofmanagers in bc

Member oofem::EngngModel::updateSharedDofManagers (FloatArray &answer, const UnknownNumberingScheme &s, int ExchangeTag)

The name and description of this function is misleading, the function really just accumulates the total values for shared "equations".

Member oofem::ExpCZMaterial::giveEngTraction_3d (FloatArray &answer, GaussPoint *gp, const FloatArray &jump, TimeStep *tStep) override

only study normal stress for now

Class oofem::ExportRegion

Rename this to something like "ExportPiece" and move it to a separate file (it doesn't actually contain anything VTK-specific).

Member oofem::ExportRegion::clear ()

Will this give a memory leak? / JB

Member oofem::ExternalForceAssembler::vectorFromElement (FloatArray &vec, Element &element, TimeStep *tStep, ValueModeType mode) const override

To be removed when sets are used for loads.

Member oofem::ExternalForceAssembler::vectorFromLoad (FloatArray &vec, Element &element, BodyLoad *load, TimeStep *tStep, ValueModeType mode) const override

Temporary: Remove when switch to sets is complete

Member oofem::FastMarchingMethod::initialize (FloatArray &dmanValues, const std ::list< int > &bcDofMans, double F)

This uses "i" which will always be equal to "node" from the earlier loop. Unsafe coding.

Member oofem::FE2FluidMaterial::giveIPValue (FloatArray &answer, GaussPoint *gp, InternalStateType type, TimeStep *tStep) override

What should one call this value? Relation between pressure and volumetric strain-rate.

Class oofem::FEI2dLineConst

Class oofem::FEI2dLineLin

Class oofem::FEI2dLineQuad

Some more routines to be implemented here.

Member oofem::FEI2dLineQuad::global2local (FloatArray &answer, const FloatArray &gcoords, const FEICellGeometry &cellgeo) const override

Move this to the cubic solver.

Member oofem::FEI2dQuadBiQuad::_evaldNdx (const FloatArrayF< 2 > &lcoords, const FEICellGeometry &cellgeo) const

check transpose

Member oofem::FEI2dQuadQuad::evaldNdx (const FloatArrayF< 2 > &lcoords, const FEICellGeometry &cellgeo) const

check transpose

Member oofem::FEI2dTrQuad::evaldNdx (const FloatArrayF< 2 > &lcoords, const FEICellGeometry &cellgeo) const

check transpose

Member oofem::FEI3dHexaLin::evaldNdx (const FloatArrayF< 3 > &lcoords, const FEICellGeometry &cellgeo)

cellgeo should give a FloatArrayF<3>, this will add a "costly" construction now:

Member oofem::FEI3dHexaQuad::edgeEvaldNdx (FloatMatrix &answer, int iedge, const FloatArray &lcoords, const FEICellGeometry &cellgeo) const override

I think the "x" in dNdx implies global cs. It should be

Member oofem::FEI3dHexaQuad::evaldNdx (const FloatArrayF< 3 > &lcoords, const FEICellGeometry &cellgeo)

cellgeo should give a FloatArrayF<3>, this will add a "costly" construction now:

Member oofem::FEI3dHexaQuad::giveCharacteristicLength (const FEICellGeometry &cellgeo) const

Change this so that it is not dependent on node order.

Member oofem::FEI3dHexaTriQuad::evaldNdx (const FloatArrayF< 3 > &lcoords, const FEICellGeometry &cellgeo)

cellgeo should give a FloatArrayF<3>, this will add a "costly" construction now:

Member oofem::FEI3dHexaTriQuad::giveBoundaryIntegrationRule (int order, int boundary, const Element_Geometry_Type) const override

Verify: Is +6 correct for dealing with "detJ" on this surface?

Member oofem::FEI3dHexaTriQuad::giveIntegrationRule (int order, const Element_Geometry_Type) const override

Verify: Is +15 correct for dealing with "detJ"? If it is, perhaps we shouldn't go for exact integration since it is likely overkill.

Member oofem::FEI3dLineLin::evald2Ndx2 (FloatMatrix &answer, const FloatArray &lcoords, const FEICellGeometry &cellgeo) const override

Check this part

Member oofem::FEI3dLineLin::evaldNdx (FloatMatrix &answer, const FloatArray &lcoords, const FEICellGeometry &cellgeo) const override

Not clear what this function should return. Just dNds would make sense if the caller defines a local coordinate system.

Member oofem::FEI3dLineLin::giveBoundaryIntegrationRule (int order, int boundary, const Element_Geometry_Type) const override

Not sure about this.

Member oofem::FEI3dLineLin::giveJacobianMatrixAt (FloatMatrix &jacobianMatrix, const FloatArray &lcoords, const FEICellGeometry &cellgeo) const override

Not sure about this matrix

Class oofem::FEI3dQuadLin

This class is entirely unchecked.

Member oofem::FEI3dQuadLin::edgeComputeLength (const IntArray &edgeNodes, const FEICellGeometry &cellgeo) const

Implement this

Member oofem::FEI3dQuadLin::edgeGiveTransformationJacobian (int iedge, const FloatArray &lcoords, const FEICellGeometry &cellgeo) const override

Implement this

Member oofem::FEI3dQuadLin::giveArea (const FEICellGeometry &cellgeo) const

Not sure about what defines boundaries on these elements.

Member oofem::FEI3dQuadLin::giveBoundaryIntegrationRule (int order, int boundary, const Element_Geometry_Type) const override

Not sure about what defines boundaries on these elements.

Member oofem::FEI3dQuadLin::surfaceEvaldNdx (FloatMatrix &answer, int isurf, const FloatArray &lcoords, const FEICellGeometry &cellgeo) const override

Implement this

Class oofem::FEI3dTetQuad

This class is entirely unchecked.

Member oofem::FEI3dTetQuad::edgeComputeLength (const IntArray &edgeNodes, const FEICellGeometry &cellgeo) const

Implement this

Member oofem::FEI3dTetQuad::edgeEvaldNdx (FloatMatrix &answer, int iedge, const FloatArray &lcoords, const FEICellGeometry &cellgeo) const override

Implement this

Member oofem::FEI3dTetQuad::edgeGiveTransformationJacobian (int iedge, const FloatArray &lcoords, const FEICellGeometry &cellgeo) const override

Implement this

Member oofem::FEI3dTetQuad::evaldNdx (const FloatArrayF< 3 > &lcoords, const FEICellGeometry &cellgeo)

cellgeo should give a FloatArrayF<3>, this will add a "costly" construction now:

Class oofem::FEI3dTrLin

This class is entirely unchecked.

Member oofem::FEI3dTrLin::edgeComputeLength (const IntArray &edgeNodes, const FEICellGeometry &cellgeo) const

Implement this

Member oofem::FEI3dTrLin::edgeGiveTransformationJacobian (int iedge, const FloatArray &lcoords, const FEICellGeometry &cellgeo) const override

Implement this

Member oofem::FEI3dTrLin::giveBoundaryIntegrationRule (int order, int boundary, const Element_Geometry_Type) const override

Not sure about what defines boundaries on these elements. 2 surfaces + 3 edges? Ask Jim about this.

Member oofem::FEI3dTrLin::surfaceEvaldNdx (FloatMatrix &answer, int isurf, const FloatArray &lcoords, const FEICellGeometry &cellgeo) const override

Implement this

Class oofem::FEI3dTrQuad

This class is entirely unchecked.

Member oofem::FEI3dTrQuad::computeLocalSurfaceMapping (int iedge) const override

- fix wrt xfem

Member oofem::FEI3dTrQuad::edgeComputeLength (const IntArray &edgeNodes, const FEICellGeometry &cellgeo) const

Implement this

Member oofem::FEI3dTrQuad::giveArea (const FEICellGeometry &cellgeo) const

this only correct for a planar triangle in the xy-plane

Member oofem::FEI3dTrQuad::giveBoundaryIntegrationRule (int order, int boundary, const Element_Geometry_Type) const override

Not sure about what defines boundaries on these elements. 2 surfaces + 3 edges? Ask Jim about this.

Member oofem::FEI3dTrQuad::global2local (FloatArray &answer, const FloatArray &lcoords, const FEICellGeometry &cellgeo) const override

this is for linear triangle

Member oofem::FEI3dTrQuad::surfaceEvaldNdx (FloatMatrix &answer, int isurf, const FloatArray &lcoords, const FEICellGeometry &cellgeo) const override

Implement this

Member oofem::FEI3dWedgeLin::giveCharacteristicLength (const FEICellGeometry &cellgeo) const

Change this so that it is not dependent on node order.

Member oofem::FEI3dWedgeLin::giveIntegrationRule (int order, const Element_Geometry_Type) const override

This function below isn't supported for wedges. We must decide how we should do this.

Member oofem::FEI3dWedgeQuad::giveBoundaryIntegrationRule (int order, int boundary, const Element_Geometry_Type) const override

Is +2 correct for dealing with "detJ" on this surface?

Member oofem::FEI3dWedgeQuad::giveCharacteristicLength (const FEICellGeometry &cellgeo) const

Change this so that it is not dependent on node order.

Member oofem::FEI3dWedgeQuad::giveIntegrationRule (int order, const Element_Geometry_Type) const override

This function below isn't supported. We must decide on how to deal with wedges.

Member oofem::FEInterpolation::boundaryEdgeEvalN (FloatArray &answer, int boundary, const FloatArray &lcoords, const FEICellGeometry &cellgeo) const =0

Member oofem::FiberedCrossSection::giveIPValue (FloatArray &answer, GaussPoint *gp, InternalStateType type, TimeStep *tStep) override

For now, create material status according to the first fiber material

so far this only works for elements where each layer has its own integration rule

Member oofem::FiberedCrossSection::giveMaterial (IntegrationPoint *ip) const override

We should keep track in integration point (integration rule) what material from layer is assigned. Otherwise difficulties due to different elements and IP numbering.

Member oofem::FiberedCrossSection::isCharacteristicMtrxSymmetric (MatResponseMode mode) const override

As far as I can see, it only uses diagonal components for the 3dbeam, but there is no way to check here.

Member oofem::FloatArray::beColumnOf (const FloatMatrix &mat, int col)

This duplicates the "copyColumn" from FloatMatrix.

Member oofem::FloatArray::resize (Index s)

Change to this (faster)

Member oofem::FloatMatrix::computeNorm (char p) const

Use this when obtaining eigen values is implemented.

Member oofem::FluidMaterialEvaluator::solveYourself () override

We should ask the material model for this initial guess.

More flexible control of convergence needed. Something relative?

Member oofem::FreeWarping::estimateMaxPackSize (IntArray &commMap, DataStream &buff, int packUnpackType) override

Fix this old ProblemCommMode__NODE_CUT value

Member oofem::GaussIntegrationRule::getRequiredNumberOfIntegrationPoints (integrationDomain dType, int approxOrder) override

Assuming same approximation order for triangle as line. Not totally sure about these /JB

Member oofem::GaussPoint::giveMaterial ()

giveMaterial routine most be removed from gauss-points, it doesn't fit with different types of cross-sections.

Member oofem::giveInternalStateValueType (InternalStateType type)

Should be have these are S3E or just S3?

Member oofem::GnuplotExportModule::outputReactionForces (TimeStep *tStep)

This function should be using the primaryfield instead of asking BCs directly. / Mikael

Member oofem::GradDpElement::computeStiffnessMatrix_ku (FloatMatrix &, MatResponseMode, TimeStep *)

This can't possibly work if this is uncommented (!) / Mikael

Member oofem::GradDpElement::giveInternalForcesVector (FloatArray &answer, TimeStep *tStep, int useUpdatedGpRecord)

This code relies on locU and locK already exists. Design seems highly unsafe. Instead locU and locK shoulld be statically determined (cf. with the Taylor-Hood elements) / Mikael

Member oofem::GradDpElement::giveLocalInternalForcesVector (FloatArray &answer, TimeStep *tStep, int useUpdatedGpRecord)

is this check really necessary?

Member oofem::GradientDamageElement::giveInternalForcesVector_u (FloatArray &answer, TimeStep *tStep, int useUpdatedGpRecord)

is this check really necessary?

Member oofem::Hexa21Stokes::computeBoundarySurfaceLoadVector (FloatArray &answer, BoundaryLoad *load, int boundary, CharType type, ValueModeType mode, TimeStep *tStep, bool global=true) override

Check this.

Member oofem::HOMExportModule::doOutput (TimeStep *tStep, bool forcedOutput=false) override

need reaction forces from engngm model, not separately from sm/tm modules as it is implemented now

Member oofem::HuertaErrorEstimatorInterface::setupRefinedElementProblem1D (Element *element, RefinedElement *refinedElement, int level, int nodeId, IntArray &localNodeIdArray, IntArray &globalNodeIdArray, HuertaErrorEstimatorInterface ::SetupMode mode, TimeStep *tStep, int nodes, FloatArray *corner, FloatArray &midNode, int &localNodeId, int &localElemId, int &localBcId, IntArray &controlNode, IntArray &controlDof, HuertaErrorEstimator ::AnalysisMode aMode, const char *edgetype)

This should change the cross-section number instead of the material number.

Member oofem::HydratingIsoHeatMaterial::computeInternalSourceVector (FloatArray &val, GaussPoint *gp, TimeStep *tStep, ValueModeType mode) const override

better via HydrationModelInterface

mode is VM_Total for nltransientstatic

Member oofem::IncrementalLinearStatic::solveYourselfAt (TimeStep *tStep) override

This will eventually not be optional.

Member oofem::InitialCondition::initializeFrom (InputRecord &ir) override

Make these both not optional (and remove the old approach). Not done right now because it breaks backwards compatibility with input files.

Member oofem::InstanciateProblem (DataReader &dr, problemMode mode, int contextFlag, EngngModel *_master, bool parallelFlag)

Make this function robust, it can't be allowed to fail (the record keyword is not a normal field-id)

Member oofem::IntegrationRuleType

Breaks modularity, reconsider this;

Member oofem::IntElLine1PF::computeStiffnessMatrix (FloatMatrix &answer, MatResponseMode rMode, TimeStep *tStep) override

this part is enough to do once

Member oofem::IntElLine2::computeGaussPoints () override

- should be a parameter with num of ip

Member oofem::IntElSurfQuad1::computeGaussPoints () override

add parameter for ngp

Member oofem::IntElSurfQuad1::drawRawGeometry (oofegGraphicContext &gc, TimeStep *tStep) override

this code not tested, onlu copied from interfaceelem3dtrlin.C //JB

Member oofem::IntElSurfTr1::computeGaussPoints () override

add parameter for ngp

Member oofem::IntElSurfTr1::drawRawGeometry (oofegGraphicContext &gc, TimeStep *tStep) override

this code not tested, onlu copied from interfaceelem3dtrlin.C //JB

Member oofem::InterfaceElem1d::drawScalar (oofegGraphicContext &gc, TimeStep *tStep) override

This code was here, but it can't possible do anything useful:

Member oofem::InterfaceElem2dQuad::computeBmatrixAt (GaussPoint *gp, FloatMatrix &answer, int=1, int=ALL_STRAINS) override

Use the interpolator everywhere in this file:

Member oofem::InterfaceElem2dQuad::drawRawGeometry (oofegGraphicContext &gc, TimeStep *tStep) override

Deprecated? Is so, remove it. / Mikael

Member oofem::InterfaceElement3dTrLin::interpolation

Implement FEI3dTrLin, then remove giveIntegrationDomain and giveElementGeometry and overload giveInterpolation()

Member oofem::IntMatBilinearCZElastic::giveFirstPKTraction_3d (const FloatArrayF< 3 > &jump, const FloatMatrixF< 3, 3 > &F, GaussPoint *gp, TimeStep *tStep) const override

only study normal stress for now

Member oofem::IntMatBilinearCZFagerstrom::giveFirstPKTraction_3d (const FloatArrayF< 3 > &jump, const FloatMatrixF< 3, 3 > &F, GaussPoint *gp, TimeStep *tStep) const override

- need to rearrange traction and stiffness matrix so the first component is normal

Martin: check with Mikael/Jim

Member oofem::IntMatBilinearCZFagerstromRate::giveFirstPKTraction_3d (const FloatArrayF< 3 > &jump, const FloatMatrixF< 3, 3 > &F, GaussPoint *gp, TimeStep *tStep) const override

- need to rearrange traction and stiffness matrix so the first component is normal

Martin: check with Mikael/Jim

Member oofem::IntMatBilinearCZFagerstromStatus::printOutputAt (FILE *file, TimeStep *tStep) const override

Martin: check need of this

Member oofem::IntMatBilinearCZJansson::giveFirstPKTraction_3d (const FloatArrayF< 3 > &jump, const FloatMatrixF< 3, 3 > &F, GaussPoint *gp, TimeStep *tStep) const override

- need to rearrange traction and stiffness matrix so the first component is normal

Member oofem::IntMatBilinearCZJanssonStatus::printOutputAt (FILE *file, TimeStep *tStep) const override

Martin: check need of this

Member oofem::IntMatBilinearCZStatus::IntMatBilinearCZStatus (GaussPoint *g)

- need to rearrange traction and stiffness matrix so the first component is normal

Member oofem::IntMatIsoDamage::give2dStiffnessMatrix_Eng (MatResponseMode rMode, GaussPoint *gp, TimeStep *tStep) const override

this is only the secant stiffness - tangent stiffness is broken!

Member oofem::IsotropicHeatTransferMaterial::computeFlux3D (const FloatArrayF< 3 > &grad, double field, GaussPoint *gp, TimeStep *tStep) const override

Shouldn't the conductivity typically depend on the primary field and/or its gradient?

Class oofem::LastEquilibratedInternalForceAssembler

The need for this is just due to some other design choices.

Class oofem::LatticeStructuralMaterial

Update documentation

Member oofem::LayeredCrossSection::give2dBeamStiffMtrx (MatResponseMode mode, GaussPoint *gp, TimeStep *tStep) const override

The logic in this whole class is pretty messy to support both slave-gp's and normal gps. Rethinking the approach is necessary. Just using the gp number doesn't nicely support more than 1 gp per layer. Must rethink.

Member oofem::LayeredCrossSection::give2dPlateStiffMtrx (MatResponseMode mode, GaussPoint *gp, TimeStep *tStep) const override

Just using the gp number doesn't nicely support more than 1 gp per layer. Must rethink.

Member oofem::LayeredCrossSection::give3dShellStiffMtrx (MatResponseMode mode, GaussPoint *gp, TimeStep *tStep) const override

The logic in this whole class is pretty messy to support both slave-gp's and normal gps. Rethinking the approach is necessary. Just using the gp number doesn't nicely support more than 1 gp per layer. Must rethink.

Member oofem::LayeredCrossSection::giveGeneralizedStress_Beam2d (const FloatArrayF< 3 > &generalizedStrain, GaussPoint *gp, TimeStep *tStep) const override

This should be replaced with a general "CrossSectionStatus"

Member oofem::LayeredCrossSection::giveGeneralizedStress_Plate (const FloatArrayF< 5 > &generalizedStrain, GaussPoint *gp, TimeStep *tStep) const override

This should be replaced with a general "CrossSectionStatus"

Member oofem::LayeredCrossSection::giveGeneralizedStress_Shell (const FloatArrayF< 8 > &generalizedStrain, GaussPoint *gp, TimeStep *tStep) const override

This should be replaced with a general "CrossSectionStatus"

Member oofem::LayeredCrossSection::giveGeneralizedStress_ShellRot (const FloatArrayF< 9 > &generalizedStrain, GaussPoint *gp, TimeStep *tStep) const override

This should be replaced with a general "CrossSectionStatus"

Member oofem::LayeredCrossSection::giveIPValue (FloatArray &answer, GaussPoint *ip, InternalStateType type, TimeStep *tStep) override

so far this only works for elements where each layer has its own integration rule

Member oofem::LayeredCrossSection::giveMaterial (IntegrationPoint *ip) const override

We should keep track in integration point (integration rule) what material from layer is assigned. Otherwise difficulties due to different elements and IP numbering.

Member oofem::LayeredCrossSection::giveSlaveGaussPoint (GaussPoint *gp, int layer, int igp) const

Generalize to multiple integration points per layer

Member oofem::LayeredCrossSection::setupIntegrationPoints (IntegrationRule &irule, int npoints, Element *element) override

We must send arrays for integration points instead of just a single scalar.

Member oofem::LEPlic::updatePosition (TimeStep *tStep) override

Can't have OOFEG stuff here, it will crash when running OOFEM normally.

Member oofem::LIBeam2dNL::giveIPValue (FloatArray &answer, GaussPoint *gp, InternalStateType type, TimeStep *tStep) override

This should be a common inheritance for all 3d beams (and a similar one for 2D beams) to support all the sensible moment/force tensors.

Member oofem::LIBeam3d::giveIPValue (FloatArray &answer, GaussPoint *gp, InternalStateType type, TimeStep *tStep) override

This should be a common inheritance for all 3d beams (and a similar one for 2D beams) to support all the sensible moment/force tensors.

Member oofem::LIBeam3dNL::giveIPValue (FloatArray &answer, GaussPoint *gp, InternalStateType type, TimeStep *tStep) override

This should be a common inheritance for all 3d beams (and a similar one for 2D beams) to support all the sensible moment/force tensors.

Member oofem::LinearElasticMaterial::giveRealStressVector_3dDegeneratedShell (const FloatArrayF< 6 > &reducedF, GaussPoint *gp, TimeStep *tStep) const

Should this be virtual? It's never used. It's not part of the base class.

Member oofem::LinearElasticMaterial::giveRealStressVector_Warping (const FloatArrayF< 2 > &reducedStrain, GaussPoint *gp, TimeStep *tStep) const override

Why is this warping method implemented here? It seems to assume isotropic linear elastic material, so it should be implemented in the subclass instead of relying on "giveShearModulus" which is only implemented there anyway.

Member oofem::LinearElasticMaterial::giveShearModulus () const

This makes no sense in this base class, it should belong to isotropiclinearelastic material.

Member oofem::LinearizedDilationForceAssembler::vectorFromElement (FloatArray &vec, Element &element, TimeStep *tStep, ValueModeType mode) const override

Problematic: Needs direct access to material model. Should do without (can be easily done by adding lots of code, but I'm searching for a simple, general, implementation) / Mikael

Member oofem::LinearStability::giveNumericalMethodForLinStaticProblem (TimeStep *tStep)

Support other solvers

Member oofem::LinearStability::solveYourselfAt (TimeStep *tStep) override

Don't hardcode skyline matrix only

Member oofem::LinearStatic::estimateMaxPackSize (IntArray &commMap, DataStream &buff, int packUnpackType) override

Fix this old ProblemCommMode__NODE_CUT value

Member oofem::LoadBalancer::unpackMigratingData (Domain *, ProcessCommunicator &pc)

Unsafe! Find a better way to preserve ownership.

Member oofem::M1MaterialStatus::restoreContext (DataStream &stream, ContextMode mode) override

All fields

Member oofem::M1MaterialStatus::saveContext (DataStream &stream, ContextMode mode) override

All fields

Member oofem::M4MaterialStatus::restoreContext (DataStream &stream, ContextMode mode) override

, save microplanestress etc.

Member oofem::M4MaterialStatus::saveContext (DataStream &stream, ContextMode mode) override

, save microplanestress etc.

Member oofem::MixedGradientPressureDirichlet::computeTangents (FloatMatrix &Ed, FloatArray &Ep, FloatArray &Cd, double &Cp, TimeStep *tStep) override

Get this from engineering model

Member oofem::MixedGradientPressureDirichlet::MixedGradientPressureDirichlet (int n, Domain *d)

Creating these statically in the constructor is a bad idea.. it should be part of Domain::createDofs()

Member oofem::MixedGradientPressureNeumann::computeTangents (FloatMatrix &Ed, FloatArray &Ep, FloatArray &Cd, double &Cp, TimeStep *tStep) override

Get this from engineering model

Member oofem::MixedGradientPressureNeumann::MixedGradientPressureNeumann (int n, Domain *d)

Rethink this. Should be created as part of createDofs()

Member oofem::MixedGradientPressureWeakPeriodic::computeTangents (FloatMatrix &Ed, FloatArray &Ep, FloatArray &Cd, double &Cp, TimeStep *tStep) override

Get this from engineering model

Member oofem::MixedPressureMaterialExtensionInterface::giveDeviatoricConstitutiveMatrix (FloatMatrix &answer, MatResponseMode, GaussPoint *gp, TimeStep *tStep) const

Move this to StructuralCrossSection ?

Member oofem::MixedPressureMaterialExtensionInterface::giveRealStressVector (FloatArray &answer, GaussPoint *gp, const FloatArray &reducedStrain, double pressure, TimeStep *tStep) const

Move this to StructuralCrossSection ?

Member oofem::MKLPardisoSolver::solve (SparseMtrx &A, FloatArray &b, FloatArray &x) override

pardisoinit seems to write outside this array

I might be misunderstanding something, but this iterative solver still does a full factorization. No options for incomplete factorizations.

I have no idea if this is suitable value. Examples use 2. / Mikael

This is not included in the table of options for some reason!

Member oofem::MPlasticMaterial2::giveIPValue (FloatArray &answer, GaussPoint *gp, InternalStateType type, TimeStep *tStep) override

Fill in correct full form values here! This just adds zeros!

Member oofem::MPlasticMaterial::giveIPValue (FloatArray &answer, GaussPoint *gp, InternalStateType type, TimeStep *tStep) override

Fill in correct full form values here! This just adds zeros!

Class oofem::MPMProblem

Documentation errors (there is no "UnknownsField" used here).

Member oofem::MPMProblem::requiresEquationRenumbering (TimeStep *tStep) override

This method should be set as the default behavior instead of relying on a user specified flag. Then this function should be removed.

Member oofem::MPMProblem::solveYourselfAt (TimeStep *tStep) override

Hack to ensure that internal RHS is evaluated before the tangent. This is not ideal, causing this to be evaluated twice for a linearproblem. We have to find a better way to handle this.

Member oofem::MPMProblem::updateComponent (TimeStep *tStep, NumericalCmpn cmpn, Domain *d) override

NRSolver should report when the solution changes instead of doing it this way.

Need to reset the boundary conditions properly since some "update" is doing strange things such as applying the (wrong) boundary conditions. This call will be removed when that code can be removed.

Member oofem::MPMProblem::updateSolution (FloatArray &solutionVector, TimeStep *tStep, Domain *d) override

NRSolver should report when the solution changes instead of doing it this way.

Need to reset the boundary conditions properly since some "update" is doing strange things such as applying the (wrong) boundary conditions. This call will be removed when that code can be removed.

Member oofem::NewtonianFluidMaterial::checkConsistency () override

Fix this, checkConsistency shouldn't be a replacement for "post-initialization" but should be completely optional.

Member oofem::NlDEIDynamic::computeMassMtrx (FloatArray &mass, double &maxOm, TimeStep *tStep)

This rotation matrix is not flexible enough.. it can only work with full size matrices and doesn't allow for flexibility in the matrixassembler.

Member oofem::NlDEIDynamic::estimateMaxPackSize (IntArray &commMap, DataStream &buff, int packUnpackType) override

Fix this old ProblemCommMode__NODE_CUT value

Member oofem::NLStructuralElement::computeStiffnessMatrix (FloatMatrix &answer, MatResponseMode rMode, TimeStep *tStep) override

We probably need overloaded function (like above) here as well.

Verify that it works with large deformations

Member oofem::NLStructuralElement::giveInternalForcesVector (FloatArray &answer, TimeStep *tStep, int useUpdatedGpRecord=0) override

Is this really what we should do for inactive elements?

This is actaully inefficient since it constructs B and twice and collects the nodal unknowns over and over.

is this check really necessary?

what is meant?

Class oofem::NLTransientTransportProblem

Documentation errors (there is no "UnknownsField" used here).

Member oofem::NLTransientTransportProblem::giveUnknownComponent (ValueModeType mode, TimeStep *tStep, Domain *d, Dof *dof) override

Shouldn't it be enough to just run this?

Member oofem::Node::computeL2GTransformation (FloatMatrix &answer, const IntArray &dofIDArry) override

This relies on the order of the dofs, not good.. / Mikael

Member oofem::NodeCommunicator::setProcessCommunicatorToSendArry (ProcessCommunicator *processComm, IntArray &map) override

We could call separate functions for node and elements instead of passing an argument

Member oofem::NonLinearDynamic::estimateMaxPackSize (IntArray &commMap, DataStream &buff, int packUnpackType) override

Fix this old ProblemCommMode__NODE_CUT value

Member oofem::NonLinearDynamic::timesMtrx (FloatArray &answer, FloatArray &vec, CharType type, Domain *domain, TimeStep *tStep)

This rotation matrix is not flexible enough.. it can only work with full size matrices and doesn't allow for flexibility in the matrixassembler.

Member oofem::NonlinearFluidMaterial::computeDeviatoricStress3D (const FloatArrayF< 6 > &eps, GaussPoint *gp, TimeStep *tStep) const override

This doesn't look like a strain norm?

Member oofem::NonLinearStatic::assembleIncrementalReferenceLoadVectors (FloatArray &_incrementalLoadVector, FloatArray &_incrementalLoadVectorOfPrescribed, SparseNonLinearSystemNM ::referenceLoadInputModeType _refMode, Domain *sourceDomain, TimeStep *tStep)

This was almost definitely wrong before. It never seems to be used. Is this code even relevant?

Member oofem::NonLinearStatic::estimateMaxPackSize (IntArray &commMap, DataStream &buff, int packUnpackType) override

Fix this old ProblemCommMode__NODE_CUT value

Member oofem::NonLinearStatic::giveLoadBalancer () override

Make the name possibly optional (but currently, there is just one choice, "parmetis")

Member oofem::NonLinearStatic::giveNumericalMethod (MetaStep *mStep) override

If there is ever a major version change, remove this (for backward compatibility)

Member oofem::NonLinearStatic::updateAttributes (MetaStep *mStep) override

If there is ever a major version change, remove this (for backward compatibility)

Member oofem::NonlocalMaterialWTP::unpackRemoteElements (Domain *d, ProcessCommunicator &pc)

Can be do safer than just releasing?

Member oofem::NonStationaryTransportProblem::bcRhs

Remove this and use nonlinear methods.

Member oofem::NonStationaryTransportProblem::linSolver

Remove this and use nonlinear methods.

Member oofem::NonStationaryTransportProblem::solveYourselfAt (TimeStep *tStep) override

missing this->updateInternalState(& TauStep);

Member oofem::NonStationaryTransportProblem::updateYourself (TimeStep *tStep) override

Find a cleaner way to do these cemhyd hacks

Member oofem::NRSolver::checkConvergence (FloatArray &RT, FloatArray &F, FloatArray &rhs, FloatArray &ddX, FloatArray &X, double RRT, const FloatArray &internalForcesEBENorm, int nite, bool &errorOutOfRange)

This is almost always the case for displacement error. nrsolveR_ERROR_NORM_SMALL_NUM is no good.

Member oofem::NRSolver::forceErrVec

This doesn't check units, it is nonsense and must be corrected / Mikael

Member oofem::NRSolver::solve (SparseMtrx &k, FloatArray &R, FloatArray *R0, FloatArray &X, FloatArray &dX, FloatArray &F, const FloatArray &internalForcesEBENorm, double &l, referenceLoadInputModeType rlm, int &nite, TimeStep *) override

This doesn't check units, it is nonsense and must be corrected / Mikael

Member oofem::OctantRec::giveChild (int xi, int yi, int zi)

We could inline the entire block if we do: std::unique_ptr<OctantRec[2][2][2]> child;

Member oofem::OOFEMTXTDataReader::OOFEMTXTDataReader (std ::string inputfilename)

This could be parallelized, but I'm not sure it is worth it (might make debugging faulty input files harder for users as well)

Member oofem::OrthotropicLinearElasticMaterial::giveInputRecord (DynamicInputRecord &input) override

Should add optional arguments:

Member oofem::ParallelContext::accumulate (const FloatArray &local, FloatArray &global)

Why aren't we using the C++ MPI functions?

Member oofem::ParallelContext::init (int newDi)

Should we even do this here? The user of the requested ParallelContext will just set this manually instead.

This shouldn't be hardcoded to just the default numbering schemes. In fact, this shouldn't even have "prescribed" and "free", just use the given numbering.

Member oofem::PardisoProjectOrgSolver::solve (SparseMtrx &A, FloatArray &b, FloatArray &x) override

pardisoinit seems to write outside this array

I might be misunderstanding something, but this iterative solver still does a full factorization. No options for incomplete factorizations.

I have no idea if this is suitable value. Examples use 2. / Mikael

This is not included in the table of options for some reason!

Member oofem::PatchIntegrationRule::restoreContext (DataStream &stream, ContextMode mode) override

Implement me

Member oofem::PatchIntegrationRule::saveContext (DataStream &stream, ContextMode mode) override

Implement me

Member oofem::PerfectlyPlasticMaterial::giveIPValue (FloatArray &answer, GaussPoint *gp, InternalStateType type, TimeStep *tStep) override

Fill in correct full form values here! This just adds zeros!

Member oofem::PetscSolver::petsc_solve (PetscSparseMtrx &A, Vec b, Vec x)

I'm not 100% on the choice MatStructure. SAME_NONZERO_PATTERN should be safe.

Member oofem::PetscSparseMtrx::buildInternalStructure (EngngModel *eModel, int di, const UnknownNumberingScheme &r_s, const UnknownNumberingScheme &c_s) override

I haven't looked at the parallel code yet (lack of time right now, and i want to see it work first). / Mikael

Member oofem::PetscSparseMtrx::buildInternalStructure (EngngModel *eModel, int di, const UnknownNumberingScheme &s) override

Split this into upper and lower triangular part like for the sequential matrix (we can then use SBAIJ which is a huge performance boost)

Take into account active boundary conditions here.

Member oofem::PhaseFieldElement::computeDisplacementUnknowns (FloatArray &answer, ValueModeType valueMode, TimeStep *stepN)

Remove these functions Jim, they work identically to the one in Element.

Member oofem::PhaseFieldElement::computeStiffnessMatrix (FloatMatrix &, MatResponseMode, TimeStep *)

this part is enough to do once

Member oofem::PhaseFieldElement::internalLength

move these to a cross section model later

Member oofem::PhaseFieldElement::PhaseFieldElement (int i, Domain *aDomain)

will be set by the cross section later

Member oofem::PlaneStrainElement::computeBHmatrixAt (GaussPoint *gp, FloatMatrix &answer) override

not checked if correct

Member oofem::PlaneStrainElement::computeStressVector (FloatArray &answer, const FloatArray &strain, GaussPoint *gp, TimeStep *tStep) override

This won't work properly with "useUpdatedGpRecord" (!)

Member oofem::PlaneStressElement::computeBHmatrixAt (GaussPoint *gp, FloatMatrix &answer) override

not checked if correct

Member oofem::PlaneStressElement::computeStressVector (FloatArray &answer, const FloatArray &strain, GaussPoint *gp, TimeStep *tStep) override

This won't work properly with "useUpdatedGpRecord" (!)

Class oofem::PlaneStressPhF2d

in development

Member oofem::PlaneStressPhF2d::giveDofManDofIDMask (int inode, IntArray &answer) const override

add damage dofID later

Member oofem::PlasticMaterial::giveIPValue (FloatArray &answer, GaussPoint *gp, InternalStateType type, TimeStep *tStep) override

Fill in correct full form values here! This just adds zeros!

Member oofem::PLCZdamageRadius::propagateInterface (Domain &iDomain, EnrichmentFront &iEnrFront, TipPropagation &oTipProp) override

Could this be done smarter? / Mikael

Member oofem::PLHoopStressCirc::propagateInterface (Domain &iDomain, EnrichmentFront &iEnrFront, TipPropagation &oTipProp) override

Could this be done smarter? / Mikael

Member oofem::PLMaterialForce::propagateInterface (Domain &iDomain, EnrichmentFront &iEnrFront, TipPropagation &oTipProp) override

Could this be done smarter? / Mikael

Member oofem::PolygonLine::computeIntersectionPoints (Element *element, std ::vector< FloatArray > &oIntersectionPoints) override

Move semantics or something would be useful here to avoid multiple copies.

Member oofem::PrescribedGenStrainShell7::computeTangent (FloatMatrix &tangent, EquationID eid, TimeStep *tStep)

Get this from engineering model

Member oofem::PrescribedGenStrainShell7::evalCovarBaseVectorsAt (FloatArray &genEps, double zeta)

Perhaps this routine should only give results for the dof it prescribes?

Member oofem::PrescribedGenStrainShell7::updateCoefficientMatrix (FloatMatrix &C)

Perhaps this routine should only give results for the dof it prescribes?

Member oofem::PrescribedGradient::computeTangent (FloatMatrix &tangent, TimeStep *tStep) override

Get this from engineering model

Member oofem::PrescribedGradient::give (Dof *dof, ValueModeType mode, double time) override

Use the user-specified dofs here instead:

Member oofem::PrescribedGradient::updateCoefficientMatrix (FloatMatrix &C)

Perhaps this routine should only give results for the dof it prescribes?

Member oofem::PrescribedGradientBCNeumann::computeTangent (FloatMatrix &tangent, TimeStep *tStep) override

Get this from engineering model

Member oofem::PrescribedGradientBCPeriodic::computeTangent (FloatMatrix &E, TimeStep *tStep) override

Get this from engineering model

Member oofem::PrescribedGradientBCWeak::computeTangent (FloatMatrix &E, TimeStep *tStep) override

Get this from engineering model

Member oofem::PrimaryField::giveUnknownValue (Dof *dof, ValueModeType mode, TimeStep *tStep)

Clean this up, this is a hack for when we ask for the increment in the first step.

Class oofem::ProblemSequence

This class is far from finished and is still lacking vital functionality. It does not work yet.

Member oofem::ProblemSequence::solveYourself () override

Still lacking the all important code to connect the subsequent analysis!

Member oofem::PythonExpression::initializeFrom (InputRecord &ir) override

Check this stuff; Is this OK to do? We need a way to fetch the global dictionary..

Member oofem::PythonExpression::~PythonExpression ()

Is this right?

Member oofem::QDKTPlate::computeVolumeAround (GaussPoint *gp) override

What about thickness?

Member oofem::QPlaneStrain::giveInterface (InterfaceType it) override

//check this probably ok now when derived from PE-element

Class oofem::QPlaneStressPhF2d

in development

Member oofem::QPlaneStressPhF2d::giveDofManDofIDMask (int inode, IntArray &answer) const override

add damage dofID later

Member oofem::Quad1Mindlin::computeBmatrixAt (GaussPoint *gp, FloatMatrix &answer, int=1, int=ALL_STRAINS) override

Check sign here

Member oofem::Quad1Mindlin::computeBodyLoadVectorAt (FloatArray &answer, Load *load, TimeStep *tStep, ValueModeType mode) override

Other/higher integration for lumped mass matrices perhaps?

Member oofem::Quad1Mindlin::computeLumpedMassMatrix (FloatMatrix &answer, TimeStep *tStep) override

Other/higher integration for lumped mass matrices perhaps?

Member oofem::Quad1MindlinShell3D::computeBmatrixAt (GaussPoint *gp, FloatMatrix &answer, int=1, int=ALL_STRAINS) override

Check the rows for both parts here, to be consistent with _3dShell material definition

Check sign here

Member oofem::Quad1MindlinShell3D::computeBodyLoadVectorAt (FloatArray &answer, Load *load, TimeStep *tStep, ValueModeType mode) override

Check potential transpose here.

Member oofem::Quad1MindlinShell3D::computeGaussPoints () override

Deal with updated geometries and such.

Member oofem::Quad1MindlinShell3D::computeLoadLEToLRotationMatrix (FloatMatrix &answer, int iEdge, GaussPoint *gp) override

I haven't even looked at this code yet / Mikael

Member oofem::Quad1MindlinShell3D::giveInternalForcesVector (FloatArray &answer, TimeStep *tStep, int useUpdatedGpRecord=0) override

Decide on how to alpha should be defined.

Class oofem::Quad1PlaneStrain

Removed for now.

Member oofem::Quad1PlateSubSoil::computeBmatrixAt (GaussPoint *gp, FloatMatrix &answer, int=1, int=ALL_STRAINS) override

Check sign here

Member oofem::Quad2PlateSubSoil::computeBmatrixAt (GaussPoint *gp, FloatMatrix &answer, int=1, int=ALL_STRAINS) override

Check sign here

Class oofem::QuadAxisym1_ht

Use the interpolation classes.

Member oofem::RankineMat::giveIPValue (FloatArray &answer, GaussPoint *gp, InternalStateType type, TimeStep *tStep) override

Fix this value!

Member oofem::rcond (const FloatMatrixF< N, N > &mat, int p=1)

Do we need lapack here?

Member oofem::RCSDMaterial::giveCrackingModulus (MatResponseMode rMode, GaussPoint *gp, double crackStrain, int i) const override

This overwrites the previous (untouched) value of Ft above. Is this right?

Member oofem::RCSDNLMaterial::giveRealStressVector (FloatArray &answer, GaussPoint *gp, const FloatArray &, TimeStep *tStep) const override

Double-Check the logic here with the mask:

Member oofem::ReactionErrorCheckingRule::check (Domain *domain, TimeStep *tStep) override

These would be easier to use if they just returned some more useable structure. Perhaps embed inside a PrimaryField, or just some std::pair/tuple. Now we instead have two calls and have to decipher the information from that.

Member oofem::ReactionErrorCheckingRule::getValue (double &value, Domain *domain, TimeStep *tStep) override

These would be easier to use if they just returned some more useable structure. Perhaps embed inside a PrimaryField, or just some std::pair/tuple. Now we instead have two calls and have to decipher the information from that.

Member oofem::REGISTER_Material_Alt (BinghamFluidMaterial2, binghamfluid2)

Remove the alternative ID. Just stick to "binghamfluid".

Member oofem::REGISTER_Material_Alt (ConcreteDPM, concreteidp)

Eventually remove this old input string (replacing the name in input files is easy anyway).

Member oofem::RowColumn::growTo (int)

Might be better to just store the data in the opposite order instead, so that a resize "does the right thing" directly.

Class oofem::ScalarAdvectionLhsAssembler

Need to parametrize individual contributing terms, ther locations and multilication factors.

Class oofem::ScalarAdvectionRhsAssembler

Need to parametrize individual contributing terms, ther locations and multilication factors.

Member oofem::ScalarFunction::isDefined () const

Support FloatArray inputs in the value dictionary, then implement this convenience function;

Member oofem::Set::updateLocalElementNumbering (EntityRenumberingFunctor &f)

Check order of element number and boundary number (same for edges)

Class oofem::Shell7Base

Add ref. to paper!

Member oofem::Shell7Base::computeConvectiveMassForce (FloatArray &answer, TimeStep *tStep)

: very old version should be checked

replace with triangle which has a xi3-coord

fix this method

Member oofem::Shell7Base::computeMassMatrix (FloatMatrix &answer, TimeStep *tStep) override

replce with triangle which has a xi3-coord

: Should be changed to integration over the layers and use the corresponding material

Member oofem::Shell7Base::computePressureTangentMatrix (FloatMatrix &answer, Load *load, const int iSurf, TimeStep *tStep)

replce with triangle which has a xi3-coord

Member oofem::Shell7Base::edgeComputeLengthAround (GaussPoint *gp, const int iedge)

should be moved to tr-elements

Member oofem::Shell7Base::giveGlobalZcoordInLayer (double xi, int layer)

move to layered crosssection

Member oofem::Shell7Base::giveInternalForcesVector (FloatArray &answer, TimeStep *tStep, int useUpdatedGpRecord=0) override

How to treat the convective force? Only active during dynamic simulations

Member oofem::Shell7Base::NodalRecoveryMI_computeNNMatrix (FloatArray &answer, int layer, InternalStateType type)

Make a "lumpMatrix" function in FloatArray ? (summing over columns would also be faster)

Member oofem::Shell7Base::NodalRecoveryMI_computeNValProduct (FloatMatrix &answer, int layer, InternalStateType type, TimeStep *tStep)

this is hard coded for stress recovery

Member oofem::Shell7Base::temp_computeBoundaryVectorOf (IntArray &dofIdArray, int boundary, ValueModeType u, TimeStep *tStep, FloatArray &answer)

: NOT CHECKED!!!

uses new standard method

Member oofem::Shell7Base::ZZNodalRecoveryMI_ComputeEstimatedInterpolationMtrx (FloatArray &answer, GaussPoint *gp, InternalStateType type)

fix this whole compostie recovery thing in a better way

Member oofem::Shell7BaseXFEM::computeBoundaryEdgeLoadVector (FloatArray &answer, BoundaryLoad *load, int boundary, CharType type, ValueModeType mode, TimeStep *tStep, bool global) override

Add support for load defined over certain area

Member oofem::Shell7BaseXFEM::computeCohesiveTangentAt (FloatMatrix &answer, TimeStep *tStep, Delamination *dei, EnrichmentItem *ei_j, EnrichmentItem *ei_k)

Use N*lambda and then apply plusProductUnsym instead;

Member oofem::Shell7BaseXFEM::computeFailureCriteriaQuantities (FailureCriteriaStatus *fc, TimeStep *tStep) override

Ugly code and not tested in a while so probably broken

Member oofem::Shell7BaseXFEM::computeMassMatrixNum (FloatMatrix &answer, TimeStep *tStep) override

broken!

Member oofem::Shell7BaseXFEM::computePressureTangentMatrixDis (FloatMatrix &KCC, FloatMatrix &KCD, FloatMatrix &KDD, IntegrationPoint *ip, Load *load, const int iSurf, TimeStep *tStep)

Fix 090814

Member oofem::Shell7BaseXFEM::edgeGiveUpdatedSolutionVector (FloatArray &answer, const int iedge, TimeStep *tStep) override

should this be here?

Member oofem::Shell7BaseXFEM::giveFictiousNodeCoordsForExport (int layer, int subCell)

Check this Jim, you overwrite "localCoords" the the code above is useless.

Member oofem::Shell7BaseXFEM::giveInterface (InterfaceType it) override

remove

Member oofem::SimpleCrossSection::give3dBeamStiffMtrx (MatResponseMode mode, GaussPoint *gp, TimeStep *tStep) const override

Do this by using the general 3d tangent matrix instead somehow!!!

Member oofem::SimpleCrossSection::giveGeneralizedStress_MembraneRot (const FloatArrayF< 4 > &generalizedStrain, GaussPoint *gp, TimeStep *tStep) const override

We should support nonlinear behavior for the membrane part. In fact, should be even bundle the rotation part with the membrane? We gain nothing from this design anyway as the rotation field is always separate. Separate manual integration by the element would be an option.

Class oofem::SimpleTransportCrossSection

There will eventually be a layered version of this cross-section, so it must capture all the values.

Member oofem::SloanGraph::findBestRoot ()

Use the timer functionalities from OOFEM here, instead of clock() directly

Member oofem::SloanGraph::initialize ()

Add connections from dof managers to boundary condition internal dof managers.

FIXME This is inherently limited; It assumes that dofmanagers cannot be slaves to internal dofmanagers in BCs or Elements. If we were able to get the masters dofmanagers are pointers we could fix this.

Member oofem::SolutionbasedShapeFunction::initializeFrom (InputRecord &ir) override

This should be in the constructor:

Member oofem::SpoolesSolver::solve (SparseMtrx &A, FloatArray &b, FloatArray &x) override

These factorizations should be kept in the matrix itself, rather than the solver.

Member oofem::StaggeredSolver::checkConvergenceDofIdArray (FloatArray &RT, FloatArray &F, FloatArray &rhs, FloatArray &ddX, FloatArray &X, double RRT, const FloatArray &internalForcesEBENorm, int nite, bool &errorOutOfRange, TimeStep *tStep, IntArray &dofIdArray)

This is almost always the case for displacement error. ERROR_NORM_SMALL_NUM is no good.

Member oofem::StaticStructural::estimateMaxPackSize (IntArray &commMap, DataStream &buff, int packUnpackType) override

Fix this old ProblemCommMode__NODE_CUT value

Member oofem::StaticStructural::initializeFrom (InputRecord &ir) override

Where is the best place to create these?

Member oofem::StaticStructural::solveYourself () override

Generalize this to engngmodel?

Member oofem::StaticStructural::solveYourselfAt (TimeStep *tStep) override

Need to find a general way to support this before enabling it by default.

Member oofem::StationaryTransportProblem::initializeFrom (InputRecord &ir) override

Combine this option with structural problems, where it is possible to keep the secant tangent elastic tangent (or generally, the initial tangent) etc. One option should fit all common needs here.

Member oofem::StationaryTransportProblem::updateSolution (FloatArray &solutionVector, TimeStep *tStep, Domain *d) override

this->field->update(VM_Total, tStep, solutionVector, EModelDefaultEquationNumbering());

Member oofem::StokesFlow::initializeFrom (InputRecord &ir) override

Deal with this parameter (set to some reasonable value by default now)

Member oofem::StokesFlowVelocityHomogenization::applyPressureGradient (const FloatArray &grad)

This should either be a specialized boundary condition so that this routine can be replaced by something else

Member oofem::StokesFlowVelocityHomogenization::computeTangent (FloatMatrix &answer, TimeStep *tStep)

This is a hack. We should have these as user input instead.

Member oofem::StokesFlowVelocityHomogenization::integrateNMatrix (FloatMatrix &N, Element &elem, TimeStep *tStep)

Ask the element for the N-matrix instead

Member oofem::Structural2DElement::computeNumberOfDofs () override

move one hiearchy up and generalize

Member oofem::Structural3DElement::computeLoadLEToLRotationMatrix (FloatMatrix &answer, int iEdge, GaussPoint *gp) override

how should this be supported

Member oofem::Structural3DElement::computeNumberOfDofs () override

move one hiearchy up and generalize

Member oofem::Structural3DElement::computeStressVector (FloatArray &answer, const FloatArray &strain, GaussPoint *gp, TimeStep *tStep) override

This won't work properly with "useUpdatedGpRecord" (!)

Member oofem::Structural3DElement::giveMaterialOrientationAt (FloatArray &x, FloatArray &y, FloatArray &z, const FloatArray &lcoords)

This is subject to change. I'm not sure which is the best way to define a local c.s.

Member oofem::StructuralCrossSection::giveCauchyStresses (FloatArray &answer, GaussPoint *gp, const FloatArray &reducedFIncrement, TimeStep *tStep)=0

should this then be in a multiplicative way? /JB

Member oofem::StructuralCrossSection::giveFirstPKStresses (const FloatArray &reducedF, GaussPoint *gp, TimeStep *tStep) const

should this then be in a multiplicative way? /JB

Member oofem::StructuralCrossSection::giveMaterial (IntegrationPoint *ip) const override

This shouldn't be optional

Member oofem::StructuralCrossSection::giveRealStresses (const FloatArray &reducedStrain, GaussPoint *gp, TimeStep *tStep) const

this part only works for simple cross section and will be removed soon when new interface elements are done /JB

Member oofem::StructuralElement::addNonlocalStiffnessContributions (SparseMtrx &dest, const UnknownNumberingScheme &s, TimeStep *tStep)

Take into account cross section model (slaves)

Member oofem::StructuralElement::computeBoundaryEdgeLoadVector (FloatArray &answer, BoundaryLoad *load, int boundary, CharType type, ValueModeType mode, TimeStep *tStep, bool global=true) override

Make sure this part is correct.

Support this...

Member oofem::StructuralElement::computeBoundarySurfaceLoadVector (FloatArray &answer, BoundaryLoad *load, int boundary, CharType type, ValueModeType mode, TimeStep *tStep, bool global=true) override

Make sure this part is correct.

Support this...

Some way to ask for the thickness at a global coordinate maybe?

Member oofem::StructuralElement::computeLoadVector (FloatArray &answer, BodyLoad *load, CharType type, ValueModeType mode, TimeStep *tStep) override

This assumption of dead-weight loads needs to be lifted. We can have other body loads, such as

Class oofem::StructuralElementEvaluator

Member oofem::StructuralElementEvaluator::giveCharacteristicVector (FloatArray &answer, CharType type, ValueModeType mode, TimeStep *tStep)

Only for total value mode type (?)

Member oofem::StructuralElementEvaluator::giveInternalForcesVector (FloatArray &answer, TimeStep *tStep, bool useUpdatedGpRecord=false)

This part computes the B matrix again; Inefficient.

Member oofem::StructuralEngngModel::computeReaction (FloatArray &answer, TimeStep *tStep, int di)

All engineering models should be using this (for consistency)

This method is overloaded in some functions, it needs to be generalized.

Member oofem::StructuralInterfaceElement::computeTraction (FloatArray &traction, IntegrationPoint *ip, const FloatArray &jump, TimeStep *tStep)

compute F in a proper way

Member oofem::StructuralInterfaceElement::giveEngTraction (FloatArray &answer, GaussPoint *gp, const FloatArray &jump, TimeStep *tStep)

Should probably convert to 2nd PK traction to be consistent with continuum elements.

compute F properly

Member oofem::StructuralInterfaceElement::giveNumberOfIPForMassMtrxIntegration ()

not sure if we should allow these elements to have mass - JB

Member oofem::StructuralInterfaceElement::giveStiffnessMatrix_Eng (FloatMatrix &answer, MatResponseMode rMode, IntegrationPoint *ip, TimeStep *tStep)

dT1dj = d(F*T2)/dj = dF/dj*T2 + F*dT2/dj - should we assume dFdj = 0? Otherwise it will be very complex!

Member oofem::StructuralInterfaceElementPhF::computeFreeEnergy (GaussPoint *gp, TimeStep *tStep)

put in material model

Member oofem::StructuralInterfaceElementPhF::computeStiffnessMatrix (FloatMatrix &answer, MatResponseMode rMode, TimeStep *tStep) override

this part is enough to do once

Member oofem::StructuralInterfaceElementPhF::internalLength

move these to a cross section model later

Class oofem::StructuralMaterial

Update documentation

Member oofem::StructuralMaterial::computeStressIndependentStrainVector (GaussPoint *gp, TimeStep *tStep, ValueModeType mode) const

Hack for loose gausspoints. We shouldn't ask for "gp->giveElement()". FIXME

Member oofem::StructuralMaterial::computeStressIndependentStrainVector_3d (GaussPoint *gp, TimeStep *tStep, ValueModeType mode) const

Hack for loose gausspoints. We shouldn't ask for "gp->giveElement()". FIXME

Member oofem::StructuralMaterial::convert_dSdE_2_dPdF_1D (const FloatMatrixF< 1, 1 > &dSdE, const FloatArrayF< 1 > &S, const FloatArrayF< 1 > &F)

is this really correct??

Member oofem::StructuralMaterial::give3dMaterialStiffnessMatrix_dCde (FloatMatrix &answer, MatResponseMode mode, GaussPoint *gp, TimeStep *tStep)

what should be default implementaiton?

Member oofem::StructuralMaterial::giveIPValue (FloatArray &answer, GaussPoint *gp, InternalStateType type, TimeStep *tStep) override

What about the stress meassure in large deformations here? The internal state type should specify "Cauchy" or something.

Fill in correct full form values here! This just adds zeros!

Member oofem::StructuralMaterial::giveRealStressVector (FloatArray &answer, GaussPoint *gp, const FloatArray &reducedStrain, TimeStep *tStep) const

Move this to StructuralCrossSection ?

Member oofem::StructuralMaterial::giveRealStressVector_StressControl (const FloatArray &reducedE, const IntArray &strainControl, GaussPoint *gp, TimeStep *tStep) const

We need a relative tolerance here! A relative tolerance like this could work, but if a really small increment is performed it won't work (it will be limited by machine precision)

Member oofem::StructuralMaterial::giveVoigtSymVectorMask (IntArray &answer, MaterialMode mmode)

This isn't actually fixed yet. Should be made compatible with 3dShell and 2dBeam

Member oofem::StructuralMaterial::giveVoigtVectorMask (IntArray &answer, MaterialMode mmode)

add additional modes if they relevant.

Member oofem::StructuralPythonMaterialStatus::initTempStatus () override

What to do here? Reset dicitonaries? I don't like this function at all.

Member oofem::StructuralPythonMaterialStatus::updateYourself (TimeStep *tStep) override

Does this suffice? I'm not sure about what happens to references into the dictionary itself. I want a deep copy. / Mikael

Member oofem::Subdivision::unpackRemoteElements (Domain *d, ProcessCommunicator &pc)

Can we do better than this unsafe code?

Can we do etter than this unsafe code?

Member oofem::SUPG::deltaT

Use ScalarFunction here!

Member oofem::SUPGElement2::computeDiffusionDerivativeTerm_MC (FloatMatrix &answer, TimeStep *tStep) override

Is this really correct? It makes the whole loop meaningless. If it is, please describe why with a comment.

Member oofem::SUPGElement2::computePressureTerm_MB (FloatMatrix &answer, TimeStep *tStep) override

Is this right? It's the same integration rule as above, why not merge them?

Member oofem::SurfaceTensionBoundaryCondition::computeLoadVectorFromElement (FloatArray &answer, Element *e, int side, TimeStep *tStep)

More of this grunt work should be moved to the interpolation classes

This should rely on the xindex and yindex in the interpolator..

Member oofem::SurfaceTensionBoundaryCondition::computeTangentFromElement (FloatMatrix &answer, Element *e, int side, TimeStep *tStep)

More of this grunt work should be moved to the interpolation classes

The thickness is not often relevant or used in FM.

Member oofem::T3DInterface::t3d_2_OOFEM (const char *t3dOutFile, Domain **dNew)

This is bad idea, dofs can be autogenerated. Don't fix the dofs. This method should be removed.

Member oofem::TangentAssembler::rmode

This is more general than just material responses; we should make a "TangentType"

Member oofem::Tdot (const FloatMatrixF< M, N > &a, const FloatMatrixF< M, P > &b)

BLAS for larger matrix sizes (maybe)

Member oofem::tet21ghostsolid::computeBoundarySurfaceLoadVector (FloatArray &answer, BoundaryLoad *load, int boundary, CharType type, ValueModeType mode, TimeStep *tStep, bool global=true) override

Make sure this part is correct.

Support this...

Some way to ask for the thickness at a global coordinate maybe?

Member oofem::Tet21Stokes::computeBoundarySurfaceLoadVector (FloatArray &answer, BoundaryLoad *load, int boundary, CharType type, ValueModeType mode, TimeStep *tStep, bool global=true) override

Check this.

Class oofem::TMLhsAssembler

Need to parametrize individual contributing terms, ther locations and multilication factors.

Member oofem::tolerance

This unit has a unit! There are no small numbers, and we should change the code to avoid the need for this at all cost. / Mikael

Member oofem::TopologyDescription::replaceFEMesh ()

Placing it in a new domain is probably preferable.

Member oofem::TR1_2D_CBS::computeDensityRhsVelocityTerms (FloatArray &answer, TimeStep *tStep) override

Check the following again:

Class oofem::TR1_2D_SUPG2

Save & restore context will not work (some way how to save/restore dynamic integration rules have to be found: element has to restore these rules based on restored data, and then rules will be restored, or integration rule can store more info about gauss points if desired (when dynamic).

Integrate sub_IPRule as ordinary element integration rule.

Class oofem::Tr1_ht

Use the interpolation classes.

Member oofem::Tr1Darcy::giveGeometryType () const override

This isn't actually correct.

Member oofem::Tr1Darcy::NodalAveragingRecoveryMI_computeNodalValue (FloatArray &answer, int node, InternalStateType type, TimeStep *tStep) override

Write support function for getting the closest gp given local c.s. and use that here

Member oofem::TR21_2D_SUPG::LS_PCS_computedN (FloatMatrix &answer) override

This code makes no sense to me. Without the weight and jacobian this is dependant on the number of gauss points.

Member oofem::TR_SHELL02::computeGaussPoints () override

In time delete

Member oofem::TR_SHELL11::giveArea ()

replace with call to linear triangle interpolator

Member oofem::Tr_Warp::computeBmatrixAt (GaussPoint *gp, FloatMatrix &answer, int li, int ui) override

Why?! Is this really called not by this elements own GP?!?!?! If so, ouch! / Mikael

Member oofem::TrabBone3D::initializeFrom (InputRecord &ir) override

Why not use vectors?

Member oofem::trace (const FloatMatrixF< N, N > &mat)

Move these more costly operations to a seperate header?

Member oofem::TransientTransportProblem::requiresEquationRenumbering (TimeStep *tStep) override

This method should be set as the default behavior instead of relying on a user specified flag. Then this function should be removed.

Member oofem::TransientTransportProblem::solveYourselfAt (TimeStep *tStep) override

Hack to ensure that internal RHS is evaluated before the tangent. This is not ideal, causing this to be evaluated twice for a linearproblem. We have to find a better way to handle this.

Member oofem::TransientTransportProblem::updateComponent (TimeStep *tStep, NumericalCmpn cmpn, Domain *d) override

NRSolver should report when the solution changes instead of doing it this way.

Need to reset the boundary conditions properly since some "update" is doing strange things such as applying the (wrong) boundary conditions. This call will be removed when that code can be removed.

Fix this, assembleVector shouldn't zero eNorm inside the functions. / Mikael

Member oofem::TransientTransportProblem::updateInternalRHS (FloatArray &answer, TimeStep *tStep, Domain *d, FloatArray *eNorm) override

Fix this, assembleVector shouldn't zero eNorm inside the functions. / Mikael

Member oofem::TransientTransportProblem::updateSolution (FloatArray &solutionVector, TimeStep *tStep, Domain *d) override

NRSolver should report when the solution changes instead of doing it this way.

Need to reset the boundary conditions properly since some "update" is doing strange things such as applying the (wrong) boundary conditions. This call will be removed when that code can be removed.

Member oofem::TransportCrossSection::giveMaterial () const =0

Temporary function that hands out the material. Must be removed for future layered support, but input files will still look the same.

Member oofem::TransportElement::computeBCSubMtrxAt (FloatMatrix &answer, TimeStep *tStep, ValueModeType mode, int indx)

Deal with coupled fields

Member oofem::TransportElement::computeBmatrixAt (FloatMatrix &answer, const FloatArray &lcoords)

We should change the transposition in evaldNdx;

Member oofem::TransportElement::computeBoundaryEdgeLoadVector (FloatArray &answer, BoundaryLoad *load, int edge, CharType type, ValueModeType mode, TimeStep *tStep, bool global=true) override

Very similar to function computeBoundaryLoadVector and computeEdgeBCSubVectorAt. They should be all merged together.

Deal with coupled fields (I think they should be another class of problems completely).

Member oofem::TransportElement::computeBoundarySurfaceLoadVector (FloatArray &answer, BoundaryLoad *load, int boundary, CharType type, ValueModeType mode, TimeStep *tStep, bool global=true) override

Deal with coupled fields (I think they should be another class of problems completely).

Member oofem::TransportElement::computeConductivitySubMatrix (FloatMatrix &answer, int iri, MatResponseMode rmode, TimeStep *tStep)

Is this expression really correct?

Member oofem::TransportElement::computeEdgeBCSubVectorAt (FloatArray &answer, Load *load, int iEdge, TimeStep *tStep, ValueModeType mode, int indx)

Deal with coupled fields

Member oofem::TransportElement::computeGradientMatrixAt (FloatMatrix &answer, const FloatArray &lcoords)

We should change the transposition in evaldNdx;

Member oofem::TransportElement::computeInternalForcesVector (FloatArray &answer, TimeStep *tStep)

Can/should this part not be built into the flux itself? Probably not? / Mikael

Member oofem::TransportElement::computeLoadVector (FloatArray &answer, BodyLoad *load, CharType type, ValueModeType mode, TimeStep *tStep) override

We could technically support other types of volume loads. Even a bulk load is a type of transmission b.c.

Deal with coupled fields (I think they should be another class of problems completely).

Member oofem::TransportElement::computeSurfaceBCSubVectorAt (FloatArray &answer, Load *load, int iSurf, TimeStep *tStep, ValueModeType mode, int indx)

Deal with coupled fields

Member oofem::TransportElement::computeTangentFromEdgeLoad (FloatMatrix &answer, BoundaryLoad *load, int boundary, MatResponseMode rmode, TimeStep *tStep) override

Deal with coupled fields (I think they should be another class of problems completely).

Member oofem::TransportElement::computeTangentFromSurfaceLoad (FloatMatrix &answer, BoundaryLoad *load, int boundary, MatResponseMode rmode, TimeStep *tStep) override

Deal with coupled fields (I think they should be another class of problems completely).

Member oofem::TransportElement::giveThicknessAt (const FloatArray &gcoords)

Move this into the base element?

Member oofem::TransportElement::updateInternalState (TimeStep *tStep) override

This method should only used when applying IC (but nltransienttransport and nonstationarytransport uses it wrong, and they should be removed)

Why is the state vector the unknown solution at the gauss point? / Mikael

We need to sort out multiple materials for coupled (heat+mass) problems

Member oofem::TransportGradientDirichlet::computeCoefficientMatrix (FloatMatrix &C)

Perhaps this routine should only give results for the dof it prescribes?

Member oofem::TransportGradientDirichlet::computeTangent (FloatMatrix &tangent, TimeStep *tStep)

Get this from engineering model

This rotation matrix is not flexible enough.. it can only work with full size matrices and doesn't allow for flexibility in the matrixassembler.

Member oofem::TransportGradientDirichlet::computeXi ()

Preallocation(?)

Can't do this yet, problem with material model interface (doesn't know the GP material mode). This should be changed.

Preallocation

Can't do this yet, problem with material model interface (doesn't know the GP material mode). This should be changed.

Member oofem::TransportGradientNeumann::computeEta ()

Can't do this yet, problem with material model interface (doesn't know the GP material mode). This should be changed.

Member oofem::TransportGradientNeumann::computeTangent (FloatMatrix &tangent, TimeStep *tStep)

Get this from engineering model

Member oofem::TransportGradientPeriodic::computeTangent (FloatMatrix &E, TimeStep *tStep)

Get this from engineering model

Member oofem::TransportMaterial::giveFluxVector (FloatArray &answer, GaussPoint *gp, const FloatArray &grad, const FloatArray &field, TimeStep *tStep) const

{ Should the field variable just be a scalar? This might change when we rethink the coupled-fields approach. Now its either just [temperature], or [temperature, concentration] so to cover both cases there is a floatarray. }

Member oofem::TransportMaterial::giveIPValue (FloatArray &answer, GaussPoint *gp, InternalStateType type, TimeStep *tStep) override

Shouldn't be named velocity.. instead, "MassFlow" or something suitable like that.

Member oofem::TrAxisym1_ht::computeVolumeAround (GaussPoint *gp) override

What about 2*pi ?

Member oofem::Tria1PlateSubSoil::computeBmatrixAt (GaussPoint *gp, FloatMatrix &answer, int=1, int=ALL_STRAINS) override

Check sign here

Member oofem::Tria2PlateSubSoil::computeBmatrixAt (GaussPoint *gp, FloatMatrix &answer, int=1, int=ALL_STRAINS) override

Check sign here

Class oofem::TriangleMesherInterface

Member oofem::TrPlaneStrRot::giveArea () override

replace with call to linear triangle interpolator

Member oofem::Truss1d::computeBmatrixAt (GaussPoint *gp, FloatMatrix &answer, int=1, int=ALL_STRAINS) override

It would be more suitable to follow the column-major version as done in FEI-classes

Member oofem::Truss1d::computeNmatrixAt (const FloatArray &iLocCoord, FloatMatrix &answer) override

It would be more suitable to follow the column-major order and just do answer.setColumn(...)

BH is just used in nlstructuralelement

Member oofem::Truss2d::giveGeometryType () const override

Introduce interpolator and remove these:

Member oofem::Truss3dnl2::giveInternalForcesVector (FloatArray &answer, TimeStep *tStep, int useUpdatedGpRecord=0) override

Is this really what we should do for inactive elements?

is this check really necessary?

Member oofem::Truss3dnl::giveInternalForcesVector (FloatArray &answer, TimeStep *tStep, int useUpdatedGpRecord=0) override

Is this really what we should do for inactive elements?

is this check really necessary?

Member oofem::TwoFluidMaterialStatus::TwoFluidMaterialStatus (GaussPoint *g, const std::array< Material *, 2 > &slaveMaterial)

This should technically suffice;

Class oofem::UPLhsAssembler

Need to parametrize individual contributing terms, ther locations and multilication factors.

Member oofem::VTKBaseExportModule::exportCellVars (ExportRegion &piece, Set &region, IntArray &cellVarsToExport, TimeStep *tStep)

should be a pointer to an element in the region /JB

Member oofem::VTKBaseExportModule::exportExternalForces (ExportRegion &piece, Set &region, IntArray &externalForcesToExport, TimeStep *tStep)

Add a more flexible solution here, ask the Engineering model for the equivalent to this (perhaps as part of the primary field?) This should be looked into, just as "getNodalVariableFromPrimaryField" is particularly complicated.

Have some mapping for UnknownType -> DofID array

Have to make more assumptions here.. we shouldn't assume EModelDefaultEquationNumbering. Do something nicer than extForces and extForcesP instead.

Member oofem::VTKBaseExportModule::getCellVariableFromIS (FloatArray &answer, Element *el, InternalStateType type, TimeStep *tStep)

This case seems redundant, remove? /JB, /// Why this special treatment for pressure? / Mikael

Is this part necessary now when giveIPValue returns full form? Only need to symmetrize in case of 6 components /JB

Some material models aren't exporting values correctly (yet) / Mikael

Member oofem::VTKBaseExportModule::getNodalVariableFromIS (FloatArray &answer, Node *node, TimeStep *tStep, InternalStateType type, Set &region, NodalRecoveryModel &smoother)

Why does this code exists here? DisplacementVector isn't a internal variable. And if its really desired, then why the special treatment for just displacements?

Is this for elements which does not use displacements as primary variables but e.g. the placement x? Move to exportPrimaryVar? /JB

Member oofem::VTKBaseExportModule::getNodalVariableFromPrimaryField (FloatArray &answer, DofManager *dman, TimeStep *tStep, UnknownType type, Set &region, NodalRecoveryModel &smoother)

This method needs to be cleaned up - maybe define the common vector types so certain dofid's are associated with them /JB

in general, shouldn't this apply for 2nd order tensors as well? /JB

Member oofem::VTKXMLExportModule::doOutput (TimeStep *tStep, bool forcedOutput=false) override

Should use probably use PVTU-files instead. It is starting to get messy.

Member oofem::VTKXMLExportModule::writeVTKPieceProlog (ExportRegion &vtkPiece, TimeStep *tStep)

move this below into setNodeCoords since it should alwas be 3 components anyway

Member oofem::VTKXMLExportModule::writeVTKPieceVariables (ExportRegion &vtkPiece, TimeStep *tStep)

giveDataHeaders is currently not updated wrt the new structure -> no file names in headers /JB

Member oofem::VTKXMLLatticeExportModule::writeVTKPieceCross (ExportRegion &vtkPiece, TimeStep *tStep)

move this below into setNodeCoords since it should alwas be 3 components anyway

giveDataHeaders is currently not updated wrt the new structure -> no file names in headers /JB

Member oofem::VTKXMLXFemExportModule::getNodalVariableFromXFEMST (FloatArray &answer, Node *node, TimeStep *tStep, XFEMStateType xfemstype, Set &region, EnrichmentItem *ei)

duplicated code from getNodalVariableFromIS - uneccessary

Member oofem::WeakPeriodicBoundaryCondition::initializeFrom (InputRecord &ir) override

Carl, remove this line and use elementsidespositive/negative instead.

Member oofem::XfemStructureManager::mergeCloseCracks ()

Quite ugly; come up with bettermethods for swapping without releasing from the ptrs.

Member REGISTER_Quasicontinuum (class)

What is this? Doesn't seem needed / Mikael