OOFEM 3.0
Loading...
Searching...
No Matches
oofem::MaterialMappingAlgorithm Class Referenceabstract

#include <materialmappingalgorithm.h>

Inheritance diagram for oofem::MaterialMappingAlgorithm:

Public Member Functions

 MaterialMappingAlgorithm ()
 Constructor.
virtual ~MaterialMappingAlgorithm ()
 Destructor.
void init (Domain *dold, IntArray &varTypes, GaussPoint *gp, Set &sourceElemSet, TimeStep *tStep, bool iCohesiveZoneGP=false)
virtual void __init (Domain *dold, IntArray &varTypes, const FloatArray &coords, Set &sourceElemSet, TimeStep *tStep, bool iCohesiveZoneGP=false)=0
virtual void finish (TimeStep *tStep)=0
virtual int mapVariable (FloatArray &answer, GaussPoint *gp, InternalStateType type, TimeStep *tStep)
virtual int __mapVariable (FloatArray &answer, const FloatArray &coords, InternalStateType type, TimeStep *tStep)=0
virtual int mapStatus (MaterialStatus &oStatus) const =0
virtual void initializeFrom (InputRecord &ir)
virtual void giveInputRecord (DynamicInputRecord &input)
virtual const char * giveClassName () const =0
 Returns class name of the receiver.
std::string errorInfo (const char *func) const
 Error printing helper.

Detailed Description

The class representing the general material model mapping algorithm. The basic task is to map the selected internal variable from old mesh to specific integration point on new mesh. Unfortunately, there are two principal ways how to implement adaptive mapping: 1) The material service is called for each IP to perform all mappings. The mapper object is used (created locally or class object) to map all necessary variables. The problem is that some mappers can be used efficiently if they are initialized for specific position and then they can be reused for all internal variables. The others, however, are efficient if if they are initialized for certain variable (of smoothing type) and then are used for all possible points. This is the key problem, whether to initialize mapper for position or for variable first. This also prevents to create some general efficient interface. 2) The other possibility is to make mapper object responsible for mapping variables in all IPs of material model. Mapper is responsible for mapping required variables, which are specified. The advantage is, that mapper can decide, whether to initialize yourself for certain variable and map all points or initialize for given point and map all necessary variables. Such approach allows efficient handling of the problem, but some additional support is required: there must exists standard way, how to access and update required history variable, elements must provide access to all integration points, and there is another tradeoff - mapper should perform loop only over elements belonging to corresponding material model and there is no efficient support for this at this time.

The idea used here is to use option (1): material model is responsible. The mappers are all assumed to require first initialization for all variables in given point. So the mappers requiring the initialization based on position can ignore given variable list and can setup for given position. The mappers requiring variable init must in general support initialization for multiple variables, but even if this operation is global, i.e., recovered variables are computed in whole domain, they should be kept, since other gp's will have typically the same requests. This also assumes that all mappers are are stored as class variables of material model in order to reuse their initialization.

Definition at line 81 of file materialmappingalgorithm.h.

Constructor & Destructor Documentation

◆ MaterialMappingAlgorithm()

◆ ~MaterialMappingAlgorithm()

virtual oofem::MaterialMappingAlgorithm::~MaterialMappingAlgorithm ( )
inlinevirtual

Destructor.

Definition at line 87 of file materialmappingalgorithm.h.

Member Function Documentation

◆ __init()

virtual void oofem::MaterialMappingAlgorithm::__init ( Domain * dold,
IntArray & varTypes,
const FloatArray & coords,
Set & sourceElemSet,
TimeStep * tStep,
bool iCohesiveZoneGP = false )
pure virtual

Initializes the receiver state before mapping. The idea is to place some common global operations before mapping particular IP's if necessary. Stores Times stamp of last initialization, so multiple calls for same step do not initialize receiver again.

Parameters
doldOld domain.
varTypesArray of InternalStateType values, identifying all vars to be mapped.
coordsCoordinates of the receiver point.
regionIf > 0 region id of receiver point, if < 0 ignore regions.
tStepTime step.

Implemented in oofem::MMAClosestIPTransfer, oofem::MMAContainingElementProjection, oofem::MMALeastSquareProjection, and oofem::MMAShapeFunctProjection.

Referenced by init().

◆ __mapVariable()

virtual int oofem::MaterialMappingAlgorithm::__mapVariable ( FloatArray & answer,
const FloatArray & coords,
InternalStateType type,
TimeStep * tStep )
pure virtual

Maps and update the unknown of given type from old mesh oldd to new mesh to which gp belongs to. The result is stored in answer array.

Parameters
answerContains result.
typeDetermines the type of internal variable.
coordsCoordinates of receiver point to which mapping occur.
tStepTime step.
Returns
Nonzero if o.k.

Implemented in oofem::MMAClosestIPTransfer, oofem::MMAContainingElementProjection, oofem::MMALeastSquareProjection, and oofem::MMAShapeFunctProjection.

Referenced by mapVariable().

◆ errorInfo()

std::string oofem::MaterialMappingAlgorithm::errorInfo ( const char * func) const
inline

Error printing helper.

Definition at line 161 of file materialmappingalgorithm.h.

References giveClassName().

◆ finish()

virtual void oofem::MaterialMappingAlgorithm::finish ( TimeStep * tStep)
pure virtual

Finishes the mapping for given time step. Used to perform cleanup. Typically some mappers require to compute some global mesh data related to current step, which are valid for all IPs - so they are computed only once for all IPs.

Parameters
tStepTime step.

Implemented in oofem::MMAClosestIPTransfer, oofem::MMAContainingElementProjection, oofem::MMALeastSquareProjection, and oofem::MMAShapeFunctProjection.

References mapVariable().

◆ giveClassName()

virtual const char * oofem::MaterialMappingAlgorithm::giveClassName ( ) const
pure virtual

◆ giveInputRecord()

virtual void oofem::MaterialMappingAlgorithm::giveInputRecord ( DynamicInputRecord & input)
inlinevirtual

Setups the input record of receiver.

Parameters
inputInput record to be filled.

Reimplemented in oofem::MMALeastSquareProjection.

Definition at line 157 of file materialmappingalgorithm.h.

◆ init()

void oofem::MaterialMappingAlgorithm::init ( Domain * dold,
IntArray & varTypes,
GaussPoint * gp,
Set & sourceElemSet,
TimeStep * tStep,
bool iCohesiveZoneGP = false )

Initializes the receiver state before mapping. The idea is to place some common global operations before mapping particular IP's if necessary. Stores Times stamp of last initialization, so multiple calls for same step do not initialize receiver again.

Parameters
doldOld domain.
varTypesArray of InternalStateType values, identifying all vars to be mapped.
gpIntegration point of to initialize.
tStepTime step.

Definition at line 41 of file materialmappingalgorithm.C.

References __init(), and oofem::GaussPoint::giveGlobalCoordinates().

◆ initializeFrom()

virtual void oofem::MaterialMappingAlgorithm::initializeFrom ( InputRecord & ir)
inlinevirtual

Reimplemented in oofem::MMALeastSquareProjection.

Definition at line 152 of file materialmappingalgorithm.h.

◆ mapStatus()

virtual int oofem::MaterialMappingAlgorithm::mapStatus ( MaterialStatus & oStatus) const
pure virtual

Initializes receiver according to object description stored in input record. InitString can be imagined as data record in component database belonging to receiver. Receiver may use value-name extracting functions to extract particular field from record. Map all internal state variables in one stroke.

Implemented in oofem::MMAClosestIPTransfer, oofem::MMAContainingElementProjection, oofem::MMALeastSquareProjection, and oofem::MMAShapeFunctProjection.

◆ mapVariable()

int oofem::MaterialMappingAlgorithm::mapVariable ( FloatArray & answer,
GaussPoint * gp,
InternalStateType type,
TimeStep * tStep )
virtual

Maps and update the unknown of given type from old mesh oldd to new mesh to which gp belongs to. The result is stored in answer array.

Parameters
answerContains result.
typeDetermines the type of internal variable.
gpIntegration point belonging to new domain to which mapping occur.
tStepTime step.
Returns
Nonzero if o.k.

Reimplemented in oofem::MMAShapeFunctProjection.

Definition at line 49 of file materialmappingalgorithm.C.

References __mapVariable(), and oofem::GaussPoint::giveGlobalCoordinates().

Referenced by finish().


The documentation for this class was generated from the following files:

This page is part of the OOFEM-3.0 documentation. Copyright Copyright (C) 1994-2025 Borek Patzak Bořek Patzák
Project e-mail: oofem@fsv.cvut.cz
Generated at for OOFEM by doxygen 1.15.0 written by Dimitri van Heesch, © 1997-2011