Background
Now that we have started to experiment with the "new" multi-stage analysis mechanism ("orchestrator"), we need to have proper (de)serialization of our geo-technical classes to support branching. Since user-defined material models play an important role in the GeoMechanicsApplication, we need to implement and test---as a bare minimum---the save and load member functions of the following UDSM-related classes: SmallStrainUDSM3DLaw and SmallStrainUDSM2DPlaneStrainLaw.
Class SmallStrainUDSM3DLaw has the following data members:
mpGetParamCount: a pointer to the function that fetches the number of parameters.mpGetStateVarCount: a pointer to the function that fetches the number of state variables.mpUserMod: a pointer to the function that requests the user-defined material model to carry out computations.mIsModelInitializedmIsUDSMLoadedmAttributesmProjectDirectorymStateVariablesmStateVariablesFinalizedmStressVectormStressVectorFinalizedmDeltaStrainVectormStrainVectorFinalizedmMatrixD
The first three of them don't need to be serialized. They are function pointers that can be reset by calling member function loadUDSM given the (saved) material properties. Data member mIsUDSMLoaded is a flag that is being set using the return value of loadUDSM, and as such also doesn't need to be saved and loaded. The other data members that have been typeset in bold face are the ones that are currently (de)serialized (even though the meaning of some of them is a bit unclear).
Note that the final five data members in the above list are protected data members rather than private ones.
Class SmallStrainUDSM2DPlaneStrainLaw derives from class SmallStrainUDSM3DLaw, but it doesn't add any new data members. It does implement the member functions save and load, but they call the (de)serialization functions of the incorrect base class!
Look into loading the same DLL twice!
@WPK4FEM and @avdg81 will have a look at whether this issue is ready for refinement.
** 10-04-2026 @WPK4FEM **
@indigocoral has done the checking for loading multiple DLL's and using a single DLL multiple times. That all proved to function correctly.
Background
Now that we have started to experiment with the "new" multi-stage analysis mechanism ("orchestrator"), we need to have proper (de)serialization of our geo-technical classes to support branching. Since user-defined material models play an important role in the GeoMechanicsApplication, we need to implement and test---as a bare minimum---the
saveandloadmember functions of the following UDSM-related classes:SmallStrainUDSM3DLawandSmallStrainUDSM2DPlaneStrainLaw.Class
SmallStrainUDSM3DLawhas the following data members:mpGetParamCount: a pointer to the function that fetches the number of parameters.mpGetStateVarCount: a pointer to the function that fetches the number of state variables.mpUserMod: a pointer to the function that requests the user-defined material model to carry out computations.mIsModelInitializedmIsUDSMLoadedmAttributesmProjectDirectorymStateVariablesmStateVariablesFinalizedmStressVectormStressVectorFinalizedmDeltaStrainVectormStrainVectorFinalizedmMatrixDThe first three of them don't need to be serialized. They are function pointers that can be reset by calling member function
loadUDSMgiven the (saved) material properties. Data membermIsUDSMLoadedis a flag that is being set using the return value ofloadUDSM, and as such also doesn't need to be saved and loaded. The other data members that have been typeset in bold face are the ones that are currently (de)serialized (even though the meaning of some of them is a bit unclear).Note that the final five data members in the above list are
protecteddata members rather thanprivateones.Class
SmallStrainUDSM2DPlaneStrainLawderives from classSmallStrainUDSM3DLaw, but it doesn't add any new data members. It does implement the member functionssaveandload, but they call the (de)serialization functions of the incorrect base class!Look into loading the same DLL twice!
@WPK4FEM and @avdg81 will have a look at whether this issue is ready for refinement.
** 10-04-2026 @WPK4FEM **
@indigocoral has done the checking for loading multiple DLL's and using a single DLL multiple times. That all proved to function correctly.