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

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

Module Input fields for Circle

These are general enough to be able to use outside this class.

Namespace oofem

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

Replace abort() with OOFEM_ERROR

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

Make this hack fit more nicely into OOFEM in general;

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

Make this hack fit more nicely into OOFEM in general;

Member oofem::AbaqusUserMaterial::giveFirstPKStressVector_3d (FloatArray &answer, GaussPoint *gp, const FloatArray &reducedF, TimeStep *tStep)

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 (FloatArray &answer, GaussPoint *gp, const FloatArray &reducedStrain, TimeStep *tStep)

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)

check if computeTraceD is necessary and check its implementation

Member oofem::AnisotropicMassTransferMaterial::initializeFrom (InputRecord *ir)

Why hardcode this for 2d ? Just take the whole matrix as the input instead and not worry about it.

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

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)

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

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

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

Introduce interpolator and remove these two:

Member oofem::BondCEBMaterial::give3dStiffnessMatrix_Eng (FloatMatrix &answer, MatResponseMode rMode, GaussPoint *gp, TimeStep *tStep)

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::BSplineInterpolation::giveNumberOfKnotSpanBasisFunctions (const IntArray &knotSpan)

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)

What about thickness?

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)

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

Member oofem::CohesiveSurface3d::initializeFrom (InputRecord *ir)

Why not a vector input instead?

This will never execute. Verify this / Mikael

Member oofem::CommBuffType

Document this

Class oofem::CompoDamageMat

This class should overload give1dMaterialStiffMtrx

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

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

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

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

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

CHECK

Member oofem::ConcreteDPM2::sig

These values should not be stored by the material model itself. As temp values in the status they would be OK, but this will be thread unsafe (and makes the model into a complete spagetti code) / Mikael

Class oofem::ContextIOERR

Document more.

Class oofem::DataStream

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

Member oofem::DEIDynamic::solveYourselfAt (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::Delamination::appendInputRecords (DynamicDataReader &oDR)

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

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)

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::DofDistributedPrimaryField::applyBoundaryCondition (BoundaryCondition &bc, TimeStep *tStep)

It's unfortunate that we have to search for the dofid twice.

Member oofem::DofDistributedPrimaryField::update (ValueModeType mode, TimeStep *tStep, const FloatArray &vectorToStore, const UnknownNumberingScheme &s)

This should not be here / 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::initializeFrom (InputRecord *ir)

This is unnecessary, we should just check if user has supplied a dofidmask field or not and just drop "numberOfDofs"). It is left for now because it will give lots of warnings otherwise, but it is effectively ignored.

This should eventually be removed, still here to preserve backwards compatibility:

Member oofem::DofManager::restoreContext (DataStream &stream, ContextMode mode, void *obj=NULL)

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::instanciateYourself (DataReader &dr)

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

Eventually remove this backwards compatibility:

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::DruckerPragerCutMat::giveIPValue (FloatArray &answer, GaussPoint *gp, InternalStateType type, TimeStep *tStep)

Actually export the relevant damage value here!

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

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)

Implement warning about unread entries

Member oofem::DynamicInputRecord::report_error (const char *_class, const char *proc, InputFieldType id, IRResultType result, const char *file, int line)

We should never directly exit when dealing with user input.

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)

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.

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::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)

only study normal stress for now

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

To be removed when sets are used for loads.

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

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)

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

Class oofem::FEI2dLineLin

{Some more routines to be implemented here}

Class oofem::FEI2dLineQuad

Some more routines to be implemented here.

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

Move this to the cubic solver.

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

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

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

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

Member oofem::FEI3dHexaTriQuad::giveBoundaryIntegrationRule (int order, int boundary)

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

Member oofem::FEI3dHexaTriQuad::giveIntegrationRule (int order)

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)

Check this part

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

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)

Not sure about this.

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

Not sure about this matrix

Class oofem::FEI3dTetQuad

This class is entirely unchecked.

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

Implement this

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

Implement this

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

Implement this

Class oofem::FEI3dTrLin

This class is entirely unchecked.

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

Implement this

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

Implement this

Member oofem::FEI3dTrLin::giveBoundaryIntegrationRule (int order, int boundary)

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)

Implement this

Class oofem::FEI3dTrQuad

This class is entirely unchecked.

Member oofem::FEI3dTrQuad::computeLocalSurfaceMapping (IntArray &edgeNodes, int iedge)

- fix wrt xfem

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

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)

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)

this is for linear triangle

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

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)

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

Member oofem::FEI3dWedgeLin::giveTransformationJacobian (const FloatArray &lcoords, const FEICellGeometry &cellgeo)

Should this really be a factor 1/2 here?

Member oofem::FEI3dWedgeQuad::giveBoundaryIntegrationRule (int order, int boundary)

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

Member oofem::FEI3dWedgeQuad::giveIntegrationRule (int order)

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

Member oofem::FEI3dWedgeQuad::giveTransformationJacobian (const FloatArray &lcoords, const FEICellGeometry &cellgeo)

Should this really be a factor 1/2 here?

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

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

This must be wrong, it will use the last evaluated G (from the last fiber), outside the loop. FIXME!

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

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

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

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::distance_square (const FloatArray &x) const

This isn't a distance to "from"?!

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

Change to this (faster)

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

Use this when obtaining eigen values is implemented.

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

Verify that this is correct for for all models.

Member oofem::FluidMaterialEvaluator::solveYourself ()

We should ask the material model for this initial guess.

More flexible control of convergence needed. Something relative?

Member oofem::FractureManager::instanciateYourself (DataReader &dr)

Make so that this can't fail.

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

Fix this old ProblemCommMode__NODE_CUT value

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

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::Hexa21Stokes::computeBoundarySurfaceLoadVector (FloatArray &answer, BoundaryLoad *load, int boundary, CharType type, ValueModeType mode, TimeStep *tStep, bool global=true)

Check this.

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)

better via HydrationModelInterface

mode is VM_Total for nltransientstatic

Class oofem::HyperElasticMaterial

Should we even have this? Isn't this identical to the isotropic linear elastic model? / Mikael

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

This will eventually not be optional.

Member oofem::InitialCondition::initializeFrom (InputRecord *ir)

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

Member oofem::InitModuleManager::initializeFrom (InputRecord *ir)

This is named differently from _IFT_ModuleManager_nmodules . Should we change or keep it?

Member oofem::InstanciateProblem (DataReader &dr, problemMode mode, int contextFlag, EngngModel *master=0, bool parallelFlag=false)

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)

this part is enough to do once

Member oofem::IntElLine2::computeGaussPoints ()

- should be a parameter with num of ip

Member oofem::IntElSurfTr1::computeGaussPoints ()

add parameter for ngp

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

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

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

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

Member oofem::InterfaceElem1d::initializeFrom (InputRecord *ir)

Move into postInitialize ?

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

Use the interpolator everywhere in this file:

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

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 (FloatArray &answer, GaussPoint *gp, const FloatArray &jumpVector, const FloatMatrix &F, TimeStep *tStep)

only study normal stress for now

Member oofem::IntMatBilinearCZFagerstrom::giveFirstPKTraction_3d (FloatArray &answer, GaussPoint *gp, const FloatArray &jump, const FloatMatrix &F, TimeStep *tStep)

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

Martin: check with Mikael/Jim

Member oofem::IntMatBilinearCZFagerstromRate::giveFirstPKTraction_3d (FloatArray &answer, GaussPoint *gp, const FloatArray &jump, const FloatMatrix &F, TimeStep *tStep)

- 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)

Martin: check need of this

Member oofem::IntMatBilinearCZJansson::giveFirstPKTraction_3d (FloatArray &answer, GaussPoint *gp, const FloatArray &jump, const FloatMatrix &F, TimeStep *tStep)

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

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

Martin: check need of this

Member oofem::IntMatBilinearCZStatus::IntMatBilinearCZStatus (int n, Domain *d, GaussPoint *g)

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

Member oofem::IntMatIsoDamage::give2dStiffnessMatrix_Eng (FloatMatrix &answer, MatResponseMode rMode, GaussPoint *gp, TimeStep *tStep)

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

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

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

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

Shouldn't the permeability 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.

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

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 (FloatMatrix &answer, MatResponseMode mode, GaussPoint *gp, TimeStep *tStep)

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

Member oofem::LayeredCrossSection::give3dDegeneratedShellStiffMtrx (FloatMatrix &answer, MatResponseMode rMode, GaussPoint *gp, TimeStep *tStep)

- check-V

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

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 (FloatArray &answer, GaussPoint *gp, const FloatArray &generalizedStrain, TimeStep *tStep)

This should be replaced with a general "CrossSectionStatus"

Member oofem::LayeredCrossSection::giveGeneralizedStress_Plate (FloatArray &answer, GaussPoint *gp, const FloatArray &generalizedStrain, TimeStep *tStep)

This should be replaced with a general "CrossSectionStatus"

Member oofem::LayeredCrossSection::giveGeneralizedStress_Shell (FloatArray &answer, GaussPoint *gp, const FloatArray &generalizedStrain, TimeStep *tStep)

This should be replaced with a general "CrossSectionStatus"

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

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

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

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::giveRealStress_3dDegeneratedShell (FloatArray &answer, GaussPoint *gp, const FloatArray &reducedStrain, TimeStep *tStep)

- check-V

Member oofem::LayeredCrossSection::giveSlaveGaussPoint (GaussPoint *gp, int slaveIndex)

Generalize to multiple integration points per layer

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

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

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

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)

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)

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::LIBeam3dNL2::initializeFrom (InputRecord *ir)

Move this to postInitialize?

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

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::initializeFrom (InputRecord *ir)

Move this to postInitialize?

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

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)

Don't hardcode skyline matrix only

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

Fix this old ProblemCommMode__NODE_CUT value

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

Directly compute dPdF instead.

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

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)

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)

Get this from engineering model

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

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)

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

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

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

Member oofem::NewtonianFluidMaterial::checkConsistency ()

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)

Fix this old ProblemCommMode__NODE_CUT value

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

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)

what is meant?

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?

Class oofem::NLTransientTransportProblem

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

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

Shouldn't it be enough to just run this?

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

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

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

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

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

Fix this old ProblemCommMode__NODE_CUT value

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)

Fix this old ProblemCommMode__NODE_CUT value

Member oofem::NonLinearStatic::giveLoadBalancer ()

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

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

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

Member oofem::NonLinearStatic::proceedStep (int di, TimeStep *tStep)

Martin: ta bort!!!

Use temporary variables. updateYourself() should set the final values, while proceedStep should be callable multiple times for each step (if necessary). / Mikael

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

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

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)

missing this->updateInternalState(& TauStep);

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

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 *)

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

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::OOFEMTXTInputRecord::report_error (const char *_class, const char *proc, InputFieldType id, IRResultType result, const char *file, int line)

We should never directly exit when dealing with user input.

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

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)

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!

Class oofem::ParticleTopologyDescription

Absolutely vital is the use of adaptivity, which is not yet implemented.

Merging of regions is still lacking.

Vanishing pores occasionally experience problems.

Partial reconstruction should be possible.

Member oofem::ParticleTopologyDescription::addCorner (int id, const FloatArray &c, ParticleGrid< ParticlePoint > &grid)

Remove this structure.

Member oofem::ParticleTopologyDescription::calculateShortestDistance (const ParticlePoint *p, std::list< ParticlePoint * > &points, ParticleGrid< ParticlePoint > &grid) const

Adaptivity

Member oofem::ParticleTopologyDescription::collectNeighbors (std::list< ParticlePoint * > &answer, const ParticlePoint *p, double dist=0) const

Change to the local corner information.

Member oofem::ParticleTopologyDescription::instanciateYourself (DataReader &dr)

Merging surfaces and such.

User input.

Member oofem::ParticleTopologyDescription::replaceFEMesh ()

Boundary sets vs. bulk sets?

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

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 &s)

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::PetscSparseMtrx::buildInternalStructure (EngngModel *eModel, int di, const UnknownNumberingScheme &r_s, const UnknownNumberingScheme &c_s)

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::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)

not checked if correct

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

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

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

not checked if correct

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

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

Class oofem::PlaneStressPhF2d

in development

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

add damage dofID later

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

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

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

Could this be done smarter? / Mikael

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

Could this be done smarter? / Mikael

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

Could this be done smarter? / Mikael

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

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 (FloatMatrix &gcov, 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)

Get this from engineering model

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

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)

Get this from engineering model

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

Get this from engineering model

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

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 ()

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

Member oofem::PythonExpression::initializeFrom (InputRecord *ir)

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::Q4Axisymm::initializeFrom (InputRecord *ir)

only works for 1 //JB

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

What about thickness?

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

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

Class oofem::QPlaneStressPhF2d

in development

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

add damage dofID later

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

Check sign here

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

Other/higher integration for lumped mass matrices perhaps?

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

Other/higher integration for lumped mass matrices perhaps?

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

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)

Check potential transpose here.

Member oofem::Quad1MindlinShell3D::computeGaussPoints ()

Deal with updated geometries and such.

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

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

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

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)

Check sign here

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

Check sign here

Class oofem::QuadAxisym1_ht

Use the interpolation classes.

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

Fix this value!

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

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

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

Double-Check the logic here with the mask:

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

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::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)

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)

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)

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)

Ugly code and not tested in a while so probably broken

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

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)

should this be here?

Member oofem::Shell7BaseXFEM::giveFictiousNodeCoordsForExport (std::vector< FloatArray > &nodes, int layer, int subCell)

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

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

remove

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

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

Member oofem::SimpleCrossSection::giveGeneralizedStress_MembraneRot (FloatArray &answer, GaussPoint *gp, const FloatArray &generalizedStrain, TimeStep *tStep)

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)

This should be in the constructor:

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

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)

Fix this old ProblemCommMode__NODE_CUT value

Member oofem::StaticStructural::initializeFrom (InputRecord *ir)

Where is the best place to create these?

Member oofem::StaticStructural::solveYourself ()

Generalize this to engngmodel?

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

Temporary hack, advanceSolution should apply the boundary conditions directly.

Temporary hack to override the incorrect values that is set by "update" above. Remove this when that is fixed.

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

Temporary hack to override the incorrect values that is set by "update" above. Remove this when that is fixed.

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

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

Temporary hack to override the incorrect vavues that is set by "update" above. Remove this when that is fixed.

Member oofem::StationaryTransportProblem::initializeFrom (InputRecord *ir)

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::updateInternalState (TimeStep *tStep)

Remove this, unnecessary with solving as a nonlinear problem (left for now, since nonstationary problems might still need it)

Member oofem::StokesFlow::initializeFrom (InputRecord *ir)

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 ()

move one hiearchy up and generalize

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

how should this be supported

Member oofem::Structural3DElement::computeNumberOfDofs ()

move one hiearchy up and generalize

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

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 (FloatArray &answer, GaussPoint *gp, const FloatArray &reducedFIncrement, TimeStep *tStep)=0

should this then be in a multiplicative way? /JB

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

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)

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)

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)

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

Member oofem::StructuralElement::GetSurfaceIntegrationRule (int order)

Old, only kept until all el have changed to the above

Class oofem::StructuralElementEvaluator

{Class is missing much documentation.}

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)

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 (FloatArray &answer, GaussPoint *gp, TimeStep *tStep, ValueModeType mode)

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

Member oofem::StructuralMaterial::computeStressIndependentStrainVector_3d (FloatArray &answer, GaussPoint *gp, TimeStep *tStep, ValueModeType mode)

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

Member oofem::StructuralMaterial::convert_dSdE_2_dPdF (FloatMatrix &answer, const FloatMatrix &dSdE, const FloatArray &S, const FloatArray &F, MaterialMode matMode)

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::give_dPdF_from (const FloatMatrix &dSdE, FloatMatrix &answer, GaussPoint *gp)

This is unnecessary and inefficient, just a hack for now (it will be changed when everything is in working order!)

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

We need a tolerance here!

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

Have this function:

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

We need a tolerance here!

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

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)

Move this to StructuralCrossSection ?

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

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 ()

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

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

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

Member oofem::SUPG::deltaT

Use ScalarFunction here!

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

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)

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.

Derive expressions for this.

Member oofem::TangentAssembler::rmode

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

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

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)

Check this.

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)

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::computeStiffnessMatrix (FloatMatrix &answer, MatResponseMode mode, TimeStep *tStep)

Should we make it return the transpose instead?

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

This isn't actually correct.

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

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)

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

Member oofem::TR_SHELL01::computeGaussPoints ()

In time delete

Member oofem::TR_SHELL02::computeGaussPoints ()

In time delete

Member oofem::Tr_Warp::ZZNodalRecoveryMI_computeNNMatrix (FloatArray &answer, InternalStateType type)

What is this? Completely unused.

Member oofem::TrabBone3D::initializeFrom (InputRecord *ir)

Why not use vectors?

Member oofem::TrabBoneNLEmbed::computeCumPlastStrain (double &alpha, GaussPoint *gp, TimeStep *tStep)

This is never used.

Member oofem::TransientTransportProblem::applyIC ()

It's rather strange that the models need the initial values.

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

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::updateComponent (TimeStep *tStep, NumericalCmpn cmpn, Domain *d)

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::TransportCrossSection::giveMaterial ()=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)

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)

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)

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, EdgeLoad *load, int boundary, MatResponseMode rmode, TimeStep *tStep)

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

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

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)

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)=0

{ 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)

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

Member oofem::TransportMaterialStatus::letTempStateVectorBe (FloatArray v)

REMOVE THESE: Assigns temporary state vector from a given vector v.

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

What about 2*pi ?

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

Check sign here

Class oofem::TriangleMesherInterface

{Possible reform slightly and merge this with the other meshing interfaces.}

Member oofem::TrPlaneStrRot::giveArea ()

replace with call to linear triangle interpolator

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

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)

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

Member oofem::Truss2d::giveGeometryType () const

Introduce interpolator and remove these:

Class oofem::VTKPiece

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

Member oofem::VTKPiece::clear ()

Will this give a memory leak? / JB

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

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

Member oofem::VTKXMLExportModule::exportCellVars (VTKPiece &piece, const IntArray &elems, TimeStep *tStep)

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

Member oofem::VTKXMLExportModule::exportExternalForces (VTKPiece &piece, IntArray &mapG2L, IntArray &mapL2G, int region, 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::VTKXMLExportModule::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::VTKXMLExportModule::getNodalVariableFromIS (FloatArray &answer, Node *node, TimeStep *tStep, InternalStateType type, int ireg)

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::VTKXMLExportModule::getNodalVariableFromPrimaryField (FloatArray &answer, DofManager *dman, TimeStep *tStep, UnknownType type, int ireg)

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::getNodalVariableFromXFEMST (FloatArray &answer, Node *node, TimeStep *tStep, XFEMStateType xfemstype, int ireg, EnrichmentItem *ei)

duplicated code from getNodalVariableFromIS - uneccessary

Member oofem::VTKXMLExportModule::writeVTKPiece (VTKPiece &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::WeakPeriodicBoundaryCondition::initializeFrom (InputRecord *ir)

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

Member oofem::ZZNodalRecoveryModelInterface::ZZNodalRecoveryMI_computeNNMatrix (FloatArray &answer, InternalStateType type)

What is this? Completely unused.