% ___________________________________________________________________________ % | | % | DEBUT DU TEXTE | % |___________________________________________________________________________| %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Introduction} \section{Rationale for Med Memory} The Med data exchange model (DEM in proper english) is the format used in the Salome platform for communicating data between different components. It manipulates objects that describe the meshes underlying scientific computations and the value fields lying on these meshes. This data exchange can be achieved either through files using the Med-file formalism or directly through memory with the Med Memory (\verb+MEDMEM+) library. The Med libraries are oganized in multiple layers: \begin{itemize} \item The MED file layer : C and Fortran API to implement mesh and field persistency. \item The MED Memory level C++ API to create and manipulate mesh and field objects in memory. \item Python API generated using SWIG which wraps the complete C++ API of the MED Memory \item CORBA API to simplify distributed computation inside SALOME (Server Side). \item MED Client classes to simplify and optimize interaction of distant objects within the local solver. \end{itemize} Thanks to Med Memory, any component can access a distant mesh or field object. Two codes running on different machines can thus exchange meshes and fields. These meshes and fields can easily be read/written in a Med file format, enabling access to the whole Salome suite of tools (CAD, meshing, Visualization, other components). \section{Outline} In this document, we describe the API of the Med Memory library (available in C++ and in Python). This document is intended for developers who are in charge of integrating existing applications in the Salome platform. As will be seen in section \ref{sec:objects}, the API consists of very few classes: \begin{itemize} \item a general MED container, \item meshes, \item supports and derived classes, \item fields \item drivers for reading and writing in MED, GIBI and VTK files. \end{itemize} All these are detailed in the following sections. The C++ formalism will be used for the description in these sections. Python syntax is very similar and is given in appendix \ref{sec:python}. \section{Naming conventions} The naming conventions are rather straightforward, but the user used to the Med-File semantics may find that there are a few noticeable differences (see the following section). \begin{description} \item[cell] entity of dimension equal to the mesh dimension ($1$, $2$ or $3$). \item[component] in a field, represents a value that is available for each element of the support (for instance : $T$, $v_x$, $\sigma_{xy}$)). \item[connectivity (descending)] connectivity table expressing connectivity of dimension $d$ elements in terms of list of dimension $d-1$ elements. \item[connectivity (nodal)] connectivity table expressing connectivity of dimension $d$ elements in terms of list of nodes. \item[coordinates] in a mesh, coordinates can be described by strings giving the names of the coordinates, the units of the coordinates, and the type of coordinates ('CARTESIAN', 'SPHERICAL' or 'CYLINDRICAL'). \item[description] string of characters used to describ an object without giving any access to a query method. \item[dimension] Med Memory discriminates the mesh dimension from the space dimension (a surface shape in $3D$ will have $2$ as a mesh dimension). \item[driver] object attached to a mesh or a field to read (resp. write) data from (resp. to) a Med-file. \item[edge] entity of dimension $1$ in a $2D$ mesh. \item[element] elementary component of a mesh ($0D$, $1D$, $2D$ or $3D$). \item[entity] category giving information on the dimension of elementary components of meshes : node, edge, face (only in $3D$) or cell. \item[face] for $3D$ meshes, faces are the $2D$ entities. \item[family] support which is composed of a set of groups, which do not intersect each other, and which gives access to those groups. \item[field] array of integer, integer array, real or real array lying on a support (the dimension of the array of values for each element of the support is called the number of components). A field is uniquely defined by its name, its support, its iteration number and its order number. $-1$ is the default value of those two numbers. \item[group] support with additional access to parent families. \item[iteration number] information attached to a field that expresses the number of the time step in the computation ($-1$ is its default value). \item[name] information attached to a mesh, support or field to name it and access to it. \item[node] entity of dimension $0$. \item[order number] information attached to a field that expresses the number of an internal iteration inside a time step in the computation ($-1$ is its default value). \item[support] list of elements of the same entity. \item[type] category of an entity (triangle, segment, quadrangle, tetrahedron, hexahedron, etc...). \end{description} \section{Limitations and advantages regarding Med-File} The Med Memory may only read meshes defined by their nodale connectivities. Following this assumption, in Med File framework all elements defined in the mesh should be stored as a {\bf MED\_MAILLE}. The Med Memory is able to read meshes defined by their nodale connectivities, and where somme geometric faces are stored as a {\bf MED\_FACE} or a {\bf MED\_ARETE} Med files. Which is not really Med File compliant. {\bf MED\_MAILLE}, {\bf MED\_FACE} and {\bf MED\_ARETE} should be taken in the Med File sense. In future version, meshes defined by their descending connectivities could be treated. The field notion in Med File and Med Memory is quite different. In Med memory a field is of course its name, but as well its iteration number, its order number and finally its corresponding sot of values. But in Med File a field is only flagged by its name. \chapter{Med Memory API}\label{sec:objects} \section{Conventions} \begin{itemize} \item In this document, one refers to the main user documentation \cite{RefManualMedMemory} where the variable \verb+$MED_ROOT_DIR+ (resp. \verb+$MED_SRC_DIR+) is the Med Memory directory installation (resp. sources directory). \item All numberings start at one (take care of array index !). \item When one gets a C (resp. C++) type array (resp. container) using a \texttt{get...} method, one should not replace some value of it. Access is in read only. Other use may product an impredicable result. To modify a such array (resp. container) use a \texttt{set...} method. \item There are many couple of methods that have similar syntaxes (one singular and one plural). The plural method returns an array and the singular one returns one particular value in this array (see \method{double getCoordinate(int i)} and \method{double* getCoordinates()} for example). \item Difference between local and global number in mesh element connectivity list~: when one talks about an element number, one could see $i^{th}$ quadrangle ($i^{th}$ in quadrangles array~: local numbering) or $j^{th}$ element ($j^{th}$ in all elements array~: global numbering). These two numbering are equivalent only if one has only one geometric type ; \end{itemize} \section{Namespaces} Med Memory uses two namespaces : \verb+MEDMEM+ which is the general namespace where the main classes are defined and \verb+MED_EN+ which defines enums that can be used by an English-speaking programer. \section{Classes} At a basic usage level, the API consists in few classes which are located in the \verb+MEDMEM+ C++ namespace (consult figure \ref{fig:uml_light} which gives an UML diagram view of the main Med Memory classes~: \begin{description} \item[MED] the global container; \item[MESH] the class containing 2D or 3D mesh objects; \item[SUPPORT] the class containing mainly a list of mesh elements; \item[FIELD] the class template containing list of values lying on a particular support. \end{description} \begin{center} \begin{figure} \includegraphics[width=15cm]{MEDMEM_UML_light.png} \caption{UML diagram of basic Med Memory API classes.}\label{fig:uml_light} \end{figure} \end{center} The API of those classes is quite sufficient for most of the component integrations in the Salome platform. The use of the Med Memory libraries may make easier the code coupling in the Salome framework. With these classes, it is possible to~: \begin{itemize} \item read/write meshes and fields from MED-files; \item create fields containing scalar or vectorial values on list of elements of the mesh; \item communicate these fields between different components; \item read/write such fields. \end{itemize} Note that on the figure \ref{fig:uml_light} as well as \ref{fig:uml} that the MED container controls the life cycle of all the objects it contains~: its destructor will destroy all the objects it aggregates. On the other hand, the life cycle of mesh, support and field objects are independent. Destroying a support (resp. a mesh) will have no effect on the fields (resp. on the support) which refer to it. But the user has to maintain the link~: a mesh agregates a support which agregates a field. If the user has to delete Med Memory objects, the field has to be deleted first, then the support and finally the mesh. A more advanced usage of the Med Memory is possible through other classes. Figure \ref{fig:uml} gives a complete view of the Med Memory API. It includes : \begin{description} \item[GROUP] a class inherited from the SUPPORT class used to create supports linked to mesh groups. It stores restricted list of elements used to set boundary conditions, initial values. \item[FAMILY] which is used to manipulate a certain kind of support and does not intersect each other; \item[MESHING] which builds meshes from scratch, it can be used to transform meshes from a specific format to the MED format or to integrate a mesher within Salome platform (note that class does not add element or node to a mesh); \item[Driver classes] which enable the user to get a fine control of the I/O operations. \end{description} \begin{center} \begin{figure} \includegraphics[width=15cm]{MEDMEM_UML.png} \caption{UML diagram of Med Memory API classes.}\label{fig:uml} \end{figure} \end{center} \section{Enums} A few enums are defined in the \verb+MED_EN+ namespace : \begin{itemize} \item The \verb+medGeometryElement+ enum which defines geometry types. The available types are linear and quadratic elements (consult \cite{RefManualMedMemory}). The entries of the enum are quite self-explanatory~: \begin{itemize} \item \verb+MED_NONE+ \item \verb+MED_POINT1+ \item \verb+MED_SEG2+ \item \verb+MED_SEG3+ \item \verb+MED_TRIA3+ \item \verb+MED_QUAD4+ \item \verb+MED_TRIA6+ \item \verb+MED_QUAD8+ \item \verb+MED_TETRA4+ \item \verb+MED_PYRA5+ \item \verb+MED_PENTA6+ \item \verb+MED_HEXA8+ \item \verb+MED_TETRA10+ \item \verb+MED_PYRA13+ \item \verb+MED_PENTA15+ \item \verb+MED_HEXA20+ \item \verb+MED_POLYGON+ \item \verb+MED_POLYHEDRA+ \item \verb+MED_ALL_ELEMENTS+ \end{itemize} \item an enum which contains the different mesh entities, \verb+medEntityMesh+, the entries of which being : \begin{itemize} \item \verb+MED_CELL+ \item \verb+MED_FACE+ \item \verb+MED_EDGE+ \item \verb+MED_NODE+ \item \verb+MED_ALL_ENTITIES+ \end{itemize} \item an enum which describes the way node coordinates or field values are stored, \begin{itemize} \item \verb+MED_FULL_INTERLACE+ for arrays such that $x_1,y_1,z_1,x_2,y_2,z_2,\ldots,x_n,y_n,z_n$; \item \verb+MED_NO_INTERLACE+ for arrays such that $x_1,x_2,\ldots,x_n,y_1,y_2,\ldots,y_n,z_1,z_2,\ldots,z_n$; \item \verb+MED_UNDEFINED_INTERLACE+, the undefined interlacing mode. \end{itemize} \item an enum which describes the type of connectivity \begin{itemize} \item \verb+MED_NODAL+ for nodal connectivity; \item \verb+MED_DESCENDING+ for descending connectivity. \end{itemize} \end{itemize} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{How to use MED object} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \section{General Information} A typical use of this object is to mount in memory what is in a MED file (or any type of driver in red or read/write mode) and it will manage its memory on its own. Then from this object one can get some information such as~: \begin{itemize} \item the number of meshes stored in this object using the {\method{getNumberOfMeshes}}. \item the number of fields stored in this object using the {\method{getNumberOfFields}}. \item a list of mesh names using the {\method{getMeshNames}}. \item a list of field names using the {\method{getFieldNames}}. \item a list of MESH object using the {\method{getMesh}} \item a list of FIELD object using the {\method{getField}} \item a list of SUPPORT object on all type of entities (node, cell, face in 3d or edge on 2d) using the {\method{getSupport}}. \end{itemize} The destructor of this object will destruct itself all FIELD, SUPPORT and MESH objects; via its get method you will have a pointer on this object and you should never delete it. One can add as well some MESH or FIELD object via the {\method{addMesh}} and the {\method{addField}} respectively. To write a complete MED object in an available writing format, on may use {\method{addDriver}} and then {\method{write}}. For an example using these methods, one may see the Python scripts in the directory \verb+$MED_ROOT_DIR/bin/salome/+,\verb+testMedObj.py+, or C++ example program in the directory \verb+$MED_SRC_DIR/src/MEDMEM+, \verb+duplicateMED.cxx+. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{How to use MESH object} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \section{General Information} We could get some general information about a MESH object such as~: \begin{itemize} \item name (\method{getName}) \item a description (\method{getDescription}) \item the space dimension (\method{getSpaceDimension}) \item the mesh dimension (\method{getMeshDimension}) \end{itemize} Here is a small C++ example program which the Python version may be found in \ref{MESHgeneral.py}. \fileCxx{MESHgeneral.cxx} \section{Information about nodes} \begin{enumerate} \item I want to get the number of nodes~: Really simple, use \method{getNumberOfNodes}. \item I want to get the coordinates components names~: use \method{getCoordinatesNames} which returns a string array (one string for each space dimension) \item I want to get the coordinates components units~: use \method{getCoordinatesUnits} which returns a string array (one string for each space dimension) \item I want to get the coordinates system~: use \method{getCoordinatesSystem} which returns a string (\verb+"CARTESIAN"+, \verb+"CYLINDRICAL"+ or \verb+"SPHERICAL"+). \item I want to get the nodes coordinates~: use \method{getCoordinates} which return a pointer to the coordinates array where values are interlace or no. \textbf{Warning~:} \begin{itemize} \item When we get coordinates in \verb+MED_NO_INTERLACE+ mode, we get an array where values are ordered like (\verb+X1,X2,X..., Y1,Y..., Z1,Z...+). \item When we get coordinates in \verb+MED_FULL_INTERLACE+ mode, we get an array where values are ordered like (\verb+X1,Y1,Z1, X2,Y2,Z2, ...+). \end{itemize} \item I want to get one particular value of coordinate~: use \method{getCoordinate} which returns the value of \( i^{th} \) node and \( j^{th} \) axis. \end{enumerate} Here is a small C++ example program which the Python version may be found in \ref{MESHcoordinates.py}. \fileCxx{MESHcoordinates.cxx} \section{Information about cells} \begin{enumerate} \item I want to get the number of geometric type for a mesh entity~: use \method{getNumberOfTypes} \textbf{C++ Example~:} \verb+int NumberOfCellsTypes = myMesh.getNumberOfTypes(MED_CELL);+ %%%%%%%%%%%%%%%%% \item I want to get all geometric type for a mesh entity~: use \method{getTypes} to get an array of \verb+medGeometryElement+ (to use directly in others methods). \textbf{C++ Example~:} \verb+const medGeometryElement * Types = myMesh.getTypes(MED_CELL);+ (array is of size \verb+NumberOfCellsTypes+) \item I want to get the number of cells~: use \method{getNumberOfElements} which return this information. You must give the mesh entity (\verb+MED_CELL+, \verb+MED_FACE+, \verb+MED_EDGE+ or \verb+MED_NODE+) and a geometric type of this entity. \textbf{C++ Example~:} \verb+int NumberOfTriangle = myMesh.getNumberOfElements(MED_FACE,MED_TRIA3);+ \verb+int NumberOfFace = myMesh.getNumberOfElements(MED_FACE,MED_ALL_ELEMENT);+ \item I want to get the geometric type of one element~: use \method{getElementType} which return a \verb+medGeometryElement+. \textbf{C++ Example~:} \verb+medGeometryElement myType = myMesh.getElementType(MED_FACE,10);+ Return the \verb+medGeometryElement+ of \( 10^{th} \) face. \item I want to get a connectivity~: use \method{getConnectivity} which return an array with connectivity values. \label{getConnectivity} \textbf{C++ Example~:} \begin{verbatim} int NumberOfTetrahedron = myMesh.getNumberOfElements(MED_CELL,MED_TETRA4); const int * TetrahedronConnectivity = myMesh.getConnectivity(MED_FULL_ENTERLACE, MED_NODAL, MED_CELL, MED_TETRA4); \end{verbatim} \verb+TetrahedronConnectivity+ contain nodal connectivity of tetrahedron in mesh. It is arranged in full enterlace mode and its size is \verb+NumberOfTetrahedron x 4+. If you want to get connectivity of all elements (with \verb+Type=MED_ALL_ELEMENTS+), you must use the index array (return by \method{getConnectivityIndex}) to get connectivity for each elements (see example \myref{MESHconnectivities.cxx}). \item I want to get an element number from a connectivity~: use \method{getElementNumber} which return the global number of a given connectivity. \textbf{C++ Example~:} \begin{verbatim} int * myElementConnectivity = {2,10,12,14}; int myNumber = myMesh.getElementNumber(MED_NODAL,MED_CELL, myElementConnectivity); \end{verbatim} %%%%%%%%%%% WITH POLY METHODS %%%%%%%%%%%% \item The listed above methods do not take into account information about \verb+polygonal+ and \verb+polyhedral+ cells contained in a MESH object. To get full information about cell types, use the same methods with \verb+WithPoly+ postfix: \begin{itemize} \item use \method{getNumberOfTypesWithPoly} to get the number of geometric types for a mesh entity; \item use \method{getTypesWithPoly} to get all geometric types for a mesh entity; \item use \method{getNumberOfElementsWithPoly} to get the number of cells; \item use \method{getElementTypeWithPoly} to get the geometric type of one element. \end{itemize} There are separate methods to get number of polygons and polyhedrons: \method{getNumberOfPolygons} and \method{getNumberOfPolyhedron} To get connectivity of polygonal elements, use \method{getPolygonsConnectivity} along with \method{getPolygonsConnectivityIndex} (see example \myref{MESHconnectivities.cxx}). To get nodal connectivity of polyhedral elements, it is necessary use together 3 methods: \method{getPolyhedronConnectivity}, \method{getPolyhedronFacesIndex} and \method{getPolyhedronIndex} (see example \myref{MESHconnectivities.cxx}). \end{enumerate} Here is a small C++ example program which the Python version may be found in \ref{MESHconnectivities.py}. \fileCxx{MESHconnectivities.cxx} \section{Information about FAMILY and GROUP} If one wants to get from a MESH object To write a complete MESH object in an available writing format, on may use {\method{addDriver}} and then {\method{write}}. For an example using these methods, one may see the Python scripts in the directory \verb+$MED_ROOT_DIR/bin/salome/+,\verb+med_test1.py+, or C++ example program in the directory \verb+$MED_SRC_DIR/src/MEDMEM+, \verb+med_test.cxx+. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{How to use SUPPORT object} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \section{Create a SUPPORT object} \label{CreateSupport} To create a SUPPORT object, you must give : \begin{itemize} \item a reference to a MESH object \item its name \item on which mesh entity it apply to \end{itemize} \textbf{C++ example~:} \verb+SUPPORT mySupport(myMesh,"support on all faces",MED_FACE) ;+ By default, this support is defined on all elements of the given entity. If you want a restricted SUPPORT, you must add manualy information about what do you want~: \begin{itemize} \item is not on all elements~: \verb+mySupport.setAll(false);+ \item on how many geometric type~:\\ \verb+mySupport.setNumberOfGeometricType(myNumberOfGeometricType);+ \item on which geometric type~:\\ \verb+mySupport.setGeometricType(myGeometricType);+ \item Temporary : the Gauss point number for each geometric type~:\\ \verb+mySupport.setNumberOfGaussPoint(myNumberOfGaussPoint);+ \item the number of elements for each geometric type~:\\ \verb+mySupport.setNumberOfEntities(myNumberOfEntities);+ \item the total number of elements~:\\ \verb+mySupport.setTotalNumberOfEntities(myTotalNumberOfEntities);+ \item the array which contains elements for each geometric type~:\\ \verb+mySupport.setNumber(myNumber);+ \end{itemize} You could also use \method{setpartial} which set all you need. \section{Use a SUPPORT object} You could get all basic information (as you set them in \myref{CreateSupport})~: \begin{itemize} \item \verb+getName()+ \item \verb+getDescription()+ \item \verb+getMesh()+ \item \verb+getEntity()+ \item \verb+isOnAllElements()+ \item \verb+getNumberOfTypes()+ \item \verb+getTypes()+ %\item \verb+getNumberOfGaussPoint()+ %\item \verb+getNumberOfGaussPoint(myGeometricType)+ \item \verb+getGeometricTypeNumber()+ \item \verb+getNumberOfElements(myGeometricType)+ \item \verb+getNumber(myGeometricType)+ \item \verb+getNumberIndex()+ \end{itemize} For details about this methods, see the reference manual \cite{RefManualMedFile}. The use of \method{getNumber} and \method{getNumberIndex} are the same as \method{getConnectivity} and \method{getConnectivityIndex} (see item \myref{getConnectivity} There is another particular method to blend another SUPPORT object into it. For example in C++ : \begin{verbatim} SUPPORT mySupport ; SUPPORT myOtherSupport ; ... mySupport.blending(myOtherSupport) ; \end{verbatim} \verb+mySupport+ contain now all elements defined originally in it, more those defined in \verb+myOtherSupport+. \section{Case of FAMILY object} A FAMILY is a SUPPORT with some additionnal methods that concern some optional attribut (we could have none) and group (we could also have none) : \begin{itemize} \item \method{getIdentifier} return the family identifier (an integer) \item \method{getNumberOfAttributes} return the number of attributes of this family \item \method{getAttributesIdentifiers} and \method{getAttributeIdentifier} return an integer array or an integer that represent attribut identifier. \item \method{getAttributesValues} and \method{getAttributeValue} return an integer array or an integer that represent attribut value. \item \method{getAttributesDescriptions} and \method{getAttributeDescription} return a string array or a string that represent attribut description. \item \method{getNumberOfGroups} return the number of groups which it belog to. \item \method{getGroupsNames} and \method{getGroupName} return a string array or a string that represent the group name which it belog to. \end{itemize} \section{Case of GROUP object} A GROUP is a SUPPORT with some additionnal methods to find FAMILY that make up it : \begin{itemize} \item \method{getNumberOfFamilies} return the number of FAMILY that make up the GROUP ; \item \method{getFamilies} and \method{getFamily} return a FAMILY array or a FAMILY that make up the GROUP. \end{itemize} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{How to use Field} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \section{Introduction} A field is characterized by its name (\method{getName}) and an optional description (\method{getDescription}). It is also characterized by this calculating moment : \begin{itemize} \item an iteration number (time step number) \item an order number (use if there are internal iteration in a time step) \item the time that correspond to this iteration number. \end{itemize} By default, there are no iteration and order number defined (value MED\_NOPDT and MED\_NONOR). A field contain values which apply on some nodes or elements (cell, face or edge). We find these informations from a SUPPORT object (see \method{getSupport}). Each field have a number of components (\method getNumberOfComponents) and all these components have a name (\method{getComponentsNames} and \method{getComponentName}), a description (\method{getComponentsDescriptions} and \method{getComponentDescription}) and an unit (\method{getMEDComponentsUnits} and \method{getMEDComponentUnit}). To get values of a FIELD, you could use \method{getValue}, \method{getValueI} and \method{getValueIJ}~: \begin{itemize} \item First return a reference to all values in the given mode (full or no interlace). \item Second return a reference to $i^{th}$ element values or component values (in accordance with the given mode). \item Third return the $j^{th}$ component of $i^{th}$ element. \end{itemize} Here is a small C++ example program which the Python version may be found in \ref{FIELDgeneral.py}. \fileCxx{FIELDgeneral.cxx} \section{Create a Field} It is simple to create a field object. You must know its SUPPORT and the number of components. \textbf{Example :} \verb+FILED myField(mySupport,NumberOfComponents) ;+ You must now set a name (\method{setName}) and optionaly a description (\method{setDescription}). By default there are no iteration and order number (negative values) and time is null. You could change this by using \method{setIterationNumber}, \method{setOrderNumber} and \method{setTime}. You \textbf{SHOULD} also set unit of your components with \method{setMEDComponentUnit} To set value, use \method{setValueIJ} to put new value of field. Here is a small C++ example program which the Python version may be found in \ref{FIELDcreate.py}. \fileCxx{FIELDcreate.cxx} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{How to use MESHING object} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% This class is a derivated class of MESH class to build a MESH object from scratch (use of set methods). All verifications are under user responsability : If arrays values or arrays dimensions are wrongs, results are impredicable. All arrays in arguments in set methods are duplicated in MESHING object. \section{Build a MESHING} \label{BuildMeshing} \subsection{Coordinates} First we must defined points coordinates of the mesh. We use \method{setCoordinates}. \textbf{C++ Example~:} \begin{verbatim} MESHING myMeshing ; const int SpaceDimension=2; const int NumberOfNodes=6; int * Coordinates = new int[SpaceDimension*NumberOfNodes] ; string System="CARTESIAN"; medModeSwitch MED_FULL_INTERLACE ; myMeshing.setCoordinates(SpaceDimension,NumberOfNodes,Coordinates,System,Mode); \end{verbatim} Then you could set the coordinates names and units (with \method{setCoordinatesNames} and \method{setCoordinatesUnits}). \subsection{Connectivities} When coordinates are defined, we could defined connectivities. First we must defined connectivity of MED\_CELL elements. After, we could defined constituent connectivity if necesary (MED\_FACE and/or MED\_EDGE). For each connectivities, you could use some methods in the following order : \begin{itemize} \item \method{setNumberOfTypes} to set the number of differents geometrics types (3 for example). This method allocates all arrays which size is this number ; \item \method{setTypes} to set the differents geometrics types ({MED\_TETRA4,MED\_PYRA5,MED\_HEXA8} for example). Types should be given in increasing order of number of nodes for this type ; \item \method{setNumberOfElements} to set the number of elements for each geometric type. This method allocates connectivities array ; \item \method{setConnectivity} to set the connectivity in MED\_FULL\_INTERLACE mode for each geometric type (use \method{setPolygonsConnectivity} and \method{setPolyhedraConnectivity} for poly elements); \end{itemize} \textbf{C++ Example~:} \begin{verbatim} MESHING myMeshing ; myMeshing.setCoordinates(SpaceDimension,NumberOfNodes,Coordinates,System,Mode); myMeshing.setNumberOfTypes(2,MED_CELL); myMeshing.setTypes({MED_TRIA3,MED_QUAD4},MED_CELL); myMeshing.setNumberOfElements({3,2},MED_CELL); // 3 MED_TRIA3 and 2 MED_QUAD4 myMeshing.setConnectivity({1,2,3,6,8,9,4,5,6},MED_CELL,MED_TRIA3); myMeshing.setConnectivity({1,3,4,5,4,5,7,8},MED_CELL,MED_QUAD4); \end{verbatim} \section{Defined a GROUP object} To add a group in a MESHING object, use \method{addGroup}. This method duplicate the GROUP object in the MESH object. To build this GROUP object, use SUPPORT methods \ref{CreateSupport} to set all attributes. \subsection{WARNING} For instance, translation from GROUP objects to FAMILY objects are not completed ! You MUST set GROUP objects as if they are FAMILY objects. This feature will be fully implemented in next release of med memory. Here is a small C++ example program which the Python version may be found in \ref{MESHINGexample.py}. \fileCxx{MESHINGexample.cxx} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Using drivers} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% The generic driver mecanism gives users the possibility to write/read the content of an object according to a specified file format. The semantic remains the same whatever the object is (MESH, FIELD, MED). By the way it allows using several file formats for writting an object. \section{Invoking a driver} \subsection{Invoking a driver at creation object time} This is the simplest way of invoking a driver. The driver parameters are given to the constructor of the object. Except for the MED object, this way of invoking a driver assume you know exactly the name of the MESH/FIELD you want read from a file of type . ex 1.1 : For a FIELD object, invoking FIELD myField(MED\_DRIVER,fileName,fieldName) create a FIELD object and a driver which loads the mesh from the MED file (Not implemented yet !). ex 1.2 : To remove the default driver previously created myField->rmDriver(); ex 2 : For a MESH object, invoking MESH myMesh(MED\_DRIVER,fileName,meshName) create a MESH object and a driver which loads the mesh from the MED file . ex 3 : For a MED object, invoking MED myMed(MED\_DRIVER,fileName) create a MED object to explore the MED file . rem 1 : ex1 is equivalent to \ref{sec:invoking_a_driver_from_the_std_drv_method} ex1. rem 2 : Since the driver has read the object, the associated file is closed. You can reread the object with the default driver by calling the read() method : myObject.read(). Here is a small C++ example program which the Python version may be found in \ref{MEDMEM_InvokingDriverAtObjectCreationTime.py}. \fileCxx{MEDMEM_InvokingDriverAtObjectCreationTime.cxx} \subsection{Invoking a driver from the standard driver method of an object\label{sec:invoking_a_driver_from_the_std_drv_method}} This way of invoking a driver give the possiblility to add several drivers to an exiting object. ex1 : First we create a FIELD without any driver FIELD~{*}~myField1~=~new~FIELD; then we add a driver with int myDriver1 = myField1->addDriver(driverType1, fileName1, fieldName1); for reading from file with myField1->read(myDriver1); ex2 : We add a new driver of type int myDriver2 = myField1->addDriver(driverType2, fileName2,fieldName2); in order to write myField1 in file with name using command myField1->write(myDriver2); rem 1 : Files are openned then closed each time you call read() or write() methods. rem 2 : If you use more than a driver you need to keep the driver handlers (myDriverI ). Here is a small C++ example program which the Python version may be found in \ref{MEDMEM_InvokingDriverFromStandardObjectMethod.py}. \fileCxx{MEDMEM_InvokingDriverFromStandardObjectMethod.cxx} \subsection{Invoking a driver and attaching it to an existing object} The methods exposed in the two previous sections always create drivers in read/write access mode. Another way of creating a driver is to create a driver with a specific access mode. ex1 : First we create a FIELD without any driver FIELD~{*}~myField1~=~new FIELD(); then we create a read-only driver MED\_FIELD\_RDONLY\_DRIVER~myRdOnlyDriver(fileName1,myField1); and attached it to myField1. Finally you must set the fieldName1 you want to acess in fileName1 with myRdOnlyDriver->setFieldName(fieldName1); in order to read the field with myRdOnlyDriver->open(); myRdOnlyDriver->read(); Don't forget to close the file with myRdOnlyDriver->close(). ToDo : By now when you create such specific drivers, the object doesn't know anything about it. Here is a small C++ example program which the Python version may be found in \ref{MEDMEM_InvokingDriverByAttachingItToAnObject.py}. \fileCxx{MEDMEM_InvokingDriverByAttachingItToAnObject.cxx} \section{Using the MED driver} The MED object provides the ability of : \begin{enumerate} \item \noindent Obtainning a reference on the whole structure contained in a file. \item Obtainning the list of all the Meshes/Fields names contained in a file. \item Obtainning a Mesh/Field reference using a name. \item Writting a whole set of independent objects with a simple command. \end{enumerate} \subsection{Exploring files} In this first use case the user wants to explore the meshes \& fields containned within a file of type given by the parameter. ex 1 : Calling MED {*} myMed = new MED(driverType1, fileName1); create a MED object which open fileName1, read all MESHes/FIELDs relations then close the file. This is equivalent to MED~{*}~myMed~=~new~MED(); myDriver~=~myMed->addDriver(driverType1,fileName1); myMed->readFileStruct(myDriver); ex 2 : To get the list of meshNames from a MED object, first ask the object how many meshes it had by calling int numberOfMeshes~=~myMed->getNumberOfMeshes(); then get the list with myMeshNames~=~new string{[}getMeshNames{]}; myMed->getMeshNames(myMeshNames). Note you can also use the deque getMeshNames() method. ex 3 : To get a list of fieldNames from a MED object, first ask the object how many fields it had by calling int numberOfFields~=~myMed->getNumberOfFields(); then get the list with myFieldNames~=~new string{[}getFieldNames{]}; myMed->getFieldNames(myFieldNames). ex 4 :To get a particular MESH use MESH {*} myMesh1 = myMED->getMesh(myMeshNames{[}0{]}) ex 5 :To get a particular FIELD you first need to know what (time step, iteration number) list is used by calling deque~myField1DtIt~=~myMed->getFieldIteration(FieldName{[}0{]}) ; then you can ask for getting a specific FIELD with FIELD~{*}~myField1~=~myMED->getField(myFieldNames{[}0{]},myField1DtIt{[}0{]}.dt,myField1DtIt{[}0{]}.it). ex2 : To write the whole content of a MED object first add a driver myDriver2~=~myMed.addDriver(driverType2,~fileName2); then ask for writing the object myMed->write(myDriver2); (not implemented yet !) You can remove the driver with myMed->rmDriver(myDriver2); rem 1 : It is possible to use multiple drivers to read a set of FIELDs / MESHes from various file formats and writing the whole set through a specific write.(not implemented yet !) \subsubsection{Adding existing MESHes/FIELDs objects} Not yet implemented. \section{Using the VTK driver} This driver allow to save all MESH and FIELD objects in an ASCII file in VTK format \cite{vtk}. You could use this driver only from a MED object, because VTK file format impose to write objects in particular order. \textbf{C++ Example~:} \begin{verbatim} MED myMed(MED_DRIVER,"file.med"); myMed.read(); int id = myMed.addDriver(VTK_DRIVER,"file.vtk"); myMed.write(id) ; \end{verbatim} \section{Using the GIBI driver} This driver allow to load a mesh from a GIBI file (ASCII file with the extension '.sauve'), puting the mesh into a MESH object of MED. It's a read only driver and is applicable only to a MESH object. \textbf{C++ Example~:} \begin{verbatim} MESH * myMesh= new MESH() ; GIBI_MESH_RDONLY_DRIVER myGibiMeshDriver("file.sauve", myMesh) ; myGibiMeshDriver.open() ; myGibiMeshDriver.read() ; myGibiMeshDriver.close() ; \end{verbatim} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Appendix: Python example scripts.}\label{sec:python} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \section{Full Python example for \ref{MESHgeneral.cxx}~:} \label{MESHgeneral.py} \verbatiminput{@srcdir@/MESHgeneral.py} \section{Full Python example for \ref{MESHcoordinates.cxx}~:} \label{MESHcoordinates.py} \verbatiminput{@srcdir@/MESHcoordinates.py} \section{Full Python example for \ref{MESHconnectivities.cxx}~:} \label{MESHconnectivities.py} \verbatiminput{@srcdir@/MESHconnectivities.py} \section{Full Python example for \ref{FIELDgeneral.cxx}~:} \label{FIELDgeneral.py} \verbatiminput{@srcdir@/FIELDgeneral.py} \section{Full Python example for \ref{FIELDcreate.cxx}~:} \label{FIELDcreate.py} \verbatiminput{@srcdir@/FIELDcreate.py} \section{Full Python example for \ref{MESHINGexample.cxx}~:} \label{MESHINGexample.py} \verbatiminput{@srcdir@/MESHINGexample.py} \section{Full Python example for \ref{MEDMEM_InvokingDriverAtObjectCreationTime.cxx}~:} \label{MEDMEM_InvokingDriverAtObjectCreationTime.py} \verbatiminput{@srcdir@/MEDMEM_InvokingDriverAtObjectCreationTime.py} \section{Full Python example for \ref{MEDMEM_InvokingDriverFromStandardObjectMethod.cxx}~:} \label{MEDMEM_InvokingDriverFromStandardObjectMethod.py} \verbatiminput{@srcdir@/MEDMEM_InvokingDriverFromStandardObjectMethod.py} \section{Full Python example for \ref{MEDMEM_InvokingDriverByAttachingItToAnObject.cxx}~:} \label{MEDMEM_InvokingDriverByAttachingItToAnObject.py} \verbatiminput{@srcdir@/MEDMEM_InvokingDriverByAttachingItToAnObject.py}