]> SALOME platform Git repositories - tools/medcoupling.git/blob - doc/MEDMEM/MEDMEM_Content.tex.in
Salome HOME
Join modifications from branch BR_DEBUG_3_2_0b1
[tools/medcoupling.git] / doc / MEDMEM / MEDMEM_Content.tex.in
1 %  ___________________________________________________________________________
2 % |                                                                           |
3 % |                             DEBUT DU TEXTE                                |
4 % |___________________________________________________________________________|
5
6 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
7 \chapter{Introduction}
8 \section{Rationale for Med Memory}
9 The Med data exchange model (DEM in proper english) is the format used in the
10 Salome platform for communicating data between different components. It
11 manipulates objects that describe the meshes underlying scientific
12 computations and the value fields lying on these meshes. This data exchange
13 can be achieved either through files using the Med-file formalism or directly
14 through memory with the Med Memory (\verb+MEDMEM+) library.
15
16 The Med libraries are oganized in multiple layers:
17 \begin{itemize}
18 \item The MED file layer : C and Fortran API to implement mesh and field
19 persistency.
20 \item The MED Memory level C++ API to create and manipulate mesh and field
21 objects in memory.
22 \item Python API generated using SWIG which wraps the complete C++ API of the
23 MED Memory
24 \item CORBA API to simplify distributed computation inside SALOME (Server
25 Side).
26 \item MED Client classes to simplify and optimize interaction of distant
27 objects within the local solver.
28 \end{itemize}
29
30 Thanks to Med Memory, any component can access a distant 
31 mesh or field object. Two codes running on 
32 different machines can thus exchange meshes and fields.
33 These meshes and fields can easily be read/written in a Med file
34 format, enabling access to the whole Salome suite of tools
35 (CAD, meshing, Visualization, other components).
36
37 \section{Outline}
38
39 In this document, we describe the API of the Med Memory library (available in
40 C++ and in Python). This document is intended for developers who are in charge
41 of integrating existing applications in the Salome platform.
42
43 As will be seen in section \ref{sec:objects}, the API consists
44 of very few classes:
45 \begin{itemize}
46 \item a general MED container,
47 \item meshes,
48 \item supports and derived classes,
49 \item fields
50 \item drivers for reading and writing in MED, GIBI and VTK files.
51 \end{itemize}
52
53 All these are detailed in the following sections. The C++ 
54 formalism will be used for the description in these sections.
55  Python syntax is very similar and is given in appendix \ref{sec:python}.
56
57 \section{Naming conventions}
58 The naming conventions are rather straightforward, but the user used to the
59 Med-File semantics may find that there are a few noticeable differences (see
60 the following section).
61 \begin{description}
62 \item[cell] entity of dimension equal to the mesh dimension ($1$, $2$ or $3$).
63 \item[component] in a field, represents a value that is available for each
64 element of the support (for instance : $T$, $v_x$, $\sigma_{xy}$)).
65 \item[connectivity (descending)] connectivity table expressing connectivity of
66 dimension $d$ elements in terms of list of dimension $d-1$ elements.
67 \item[connectivity (nodal)] connectivity table expressing connectivity of
68 dimension $d$ elements in terms of list of nodes.
69 \item[coordinates] in a mesh, coordinates can be described by strings giving
70 the names of the coordinates, the units of the coordinates, and the type of
71 coordinates ('CARTESIAN', 'SPHERICAL' or 'CYLINDRICAL').
72 \item[description] string of characters used to describ an object without
73 giving any access to a query method.
74 \item[dimension] Med Memory discriminates the mesh dimension from the space
75 dimension (a surface shape in $3D$ will have $2$ as a mesh dimension).
76 \item[driver] object attached to a mesh or a field to read (resp. write) data
77 from (resp. to) a Med-file.
78 \item[edge] entity of dimension $1$ in a $2D$ mesh.
79 \item[element]  elementary component of a mesh ($0D$, $1D$, $2D$ or $3D$).
80 \item[entity] category giving information on the dimension of elementary
81 components of meshes : node, edge, face (only in $3D$) or cell.
82 \item[face] for $3D$ meshes, faces are the $2D$ entities.
83 \item[family] support which is composed of a set of groups, which do not
84 intersect each other, and which gives access to those groups.
85 \item[field] array of integer, integer array, real or real array lying on a
86 support (the dimension of the array of values for each element of the support
87 is called the number of components). A field is uniquely defined by its name,
88 its support, its iteration number and its order number. $-1$ is the default
89 value of those two numbers.
90 \item[group] support with additional access to parent families.
91 \item[iteration number] information attached to a field that expresses the
92 number of the time step in the computation ($-1$ is its default value).
93 \item[name] information attached to a mesh, support or field to name it and access to it.
94 \item[node] entity of dimension $0$.
95 \item[order number] information attached to a field that expresses the number
96 of an internal iteration inside a time step in the computation ($-1$ is its
97 default value).
98 \item[support] list of elements of the same entity.
99 \item[type] category of an entity (triangle, segment, quadrangle, tetrahedron,
100 hexahedron, etc...).
101 \end{description}
102
103 \section{Limitations and advantages regarding Med-File}
104 The Med Memory may only read meshes defined by their nodale connectivities.
105 Following this assumption, in Med File framework all elements defined
106 in the mesh should be stored as a {\bf MED\_MAILLE}.
107
108 The Med Memory is able to read meshes defined by their nodale connectivities,
109 and where somme geometric faces are stored as a {\bf MED\_FACE} or a
110 {\bf MED\_ARETE} Med files. Which is not really Med File compliant.
111
112 {\bf MED\_MAILLE}, {\bf MED\_FACE} and {\bf MED\_ARETE} should be taken in the
113 Med File sense. In future version, meshes defined by their descending
114 connectivities could be treated.
115
116 The field notion in Med File and Med Memory is quite different. In Med memory
117 a field is of course its name, but as well its iteration number, its order
118 number and finally its corresponding sot of values. But in Med File a field is
119 only flagged by its name.
120
121 \chapter{Med Memory API}\label{sec:objects}
122
123 \section{Conventions}
124
125 \begin{itemize}
126 \item In this document, one refers to the main user documentation
127 \cite{RefManualMedMemory} where the variable \verb+$MED_ROOT_DIR+ (resp.
128 \verb+$MED_SRC_DIR+) is the Med Memory directory installation (resp. sources
129 directory).
130
131 \item All numberings start at one (take care of array index !).
132
133 \item When one gets a C (resp. C++) type array (resp. container) using a \texttt{get...} method, one should
134 not replace some value of it. Access is in read only. Other use may
135 product an impredicable result. To modify a such array (resp. container) use a \texttt{set...}
136 method.
137
138 \item There are many couple of methods that have similar syntaxes (one singular and one 
139 plural). The plural method returns an array and the singular one returns one 
140 particular value in this array (see \method{double getCoordinate(int i)} and 
141 \method{double* getCoordinates()} for example).
142
143 \item Difference between local and global number in mesh element connectivity list~: when one talks about an 
144 element number, one could see $i^{th}$ quadrangle ($i^{th}$ in quadrangles 
145 array~: local numbering) or $j^{th}$ element ($j^{th}$ in all elements array~: 
146 global numbering). These two numbering are equivalent only if one has only one 
147 geometric type ;
148
149 \end{itemize}
150
151 \section{Namespaces}
152 Med Memory uses two namespaces : \verb+MEDMEM+ which is the general 
153 namespace where the main classes are defined and \verb+MED_EN+
154 which defines enums that can be used by an English-speaking 
155 programer.
156
157 \section{Classes}
158 At a basic usage level, the API consists in few classes which are located in
159 the \verb+MEDMEM+ C++ namespace (consult figure \ref{fig:uml_light} which gives
160 an UML diagram view of the main Med Memory classes~:
161 \begin{description}
162 \item[MED] the global container;
163 \item[MESH] the class containing 2D or 3D mesh objects;
164 \item[SUPPORT] the class containing mainly a list of mesh elements;
165 \item[FIELD] the class template containing list of values lying on a
166 particular support.
167 \end{description}
168 \begin{center}
169 \begin{figure}
170 \includegraphics[width=15cm]{MEDMEM_UML_light.png}
171 \caption{UML diagram of basic Med Memory API classes.}\label{fig:uml_light}
172 \end{figure}
173 \end{center}
174 The API of those classes is quite sufficient for most of the component
175 integrations in the Salome platform. The use of the Med Memory libraries may
176 make easier the code coupling in the Salome framework. With these classes, it
177 is possible to~:
178 \begin{itemize}
179 \item read/write meshes and fields from MED-files;
180 \item create fields containing scalar or vectorial values on list of elements
181 of the mesh;
182 \item communicate these fields between different components;
183 \item read/write such fields.
184 \end{itemize}
185 Note that on the figure \ref{fig:uml_light} as well as \ref{fig:uml} that the
186 MED container controls the life cycle of all the objects it contains~: its
187 destructor will destroy all the objects it aggregates. On the other hand, the
188 life cycle of mesh, support and field objects are independent. Destroying a
189 support (resp. a mesh) will have no effect on the fields (resp. on the support)
190 which refer to it. But the user has to maintain the link~: a mesh agregates a
191 support which agregates a field. If the user has to delete Med Memory objects,
192 the field has to be deleted first, then the support and finally the mesh.
193
194 A more advanced usage of the Med Memory is possible through other classes.
195 Figure \ref{fig:uml} gives a complete view of the Med Memory API. It includes :
196 \begin{description}
197 \item[GROUP] a class inherited from the SUPPORT class used to create supports
198 linked to mesh groups. It stores restricted list of elements used to set
199 boundary conditions, initial values.
200 \item[FAMILY] which is used to manipulate a certain kind of support and does
201 not intersect each other;
202 \item[MESHING] which builds meshes from scratch, it can be used to transform
203 meshes from a specific format to the MED format or to integrate a mesher
204 within Salome platform (note that class does not add element or node to a
205 mesh);
206 \item[Driver classes] which enable the user to get a fine control of the I/O
207 operations.
208 \end{description}
209 \begin{center}
210 \begin{figure}
211 \includegraphics[width=15cm]{MEDMEM_UML.png}
212 \caption{UML diagram of Med Memory API classes.}\label{fig:uml}
213 \end{figure}
214 \end{center}
215 \section{Enums}
216 A few enums are defined in the \verb+MED_EN+ namespace :
217 \begin{itemize}
218 \item The \verb+medGeometryElement+ enum which defines geometry types. The
219 available types are linear and quadratic elements (consult
220 \cite{RefManualMedMemory}). The entries of the enum are quite
221 self-explanatory~:
222 \begin{itemize}
223 \item \verb+MED_NONE+
224 \item \verb+MED_POINT1+
225 \item \verb+MED_SEG2+
226 \item \verb+MED_SEG3+
227 \item \verb+MED_TRIA3+
228 \item \verb+MED_QUAD4+
229 \item \verb+MED_TRIA6+
230 \item \verb+MED_QUAD8+
231 \item \verb+MED_TETRA4+
232 \item \verb+MED_PYRA5+
233 \item \verb+MED_PENTA6+
234 \item \verb+MED_HEXA8+
235 \item \verb+MED_TETRA10+
236 \item \verb+MED_PYRA13+
237 \item \verb+MED_PENTA15+
238 \item \verb+MED_HEXA20+
239 \item \verb+MED_POLYGON+
240 \item \verb+MED_POLYHEDRA+
241 \item \verb+MED_ALL_ELEMENTS+
242 \end{itemize}
243 \item
244 an enum which contains the different mesh entities, \verb+medEntityMesh+, the
245 entries of which being :
246 \begin{itemize}
247 \item \verb+MED_CELL+
248 \item \verb+MED_FACE+
249 \item \verb+MED_EDGE+
250 \item \verb+MED_NODE+
251 \item \verb+MED_ALL_ENTITIES+
252 \end{itemize}
253 \item an enum which describes the way node coordinates or field values are
254 stored,
255 \begin{itemize}
256 \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$;
257 \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$;
258 \item \verb+MED_UNDEFINED_INTERLACE+, the undefined interlacing mode.
259 \end{itemize}
260 \item
261 an enum which describes the type of connectivity
262 \begin{itemize}
263 \item \verb+MED_NODAL+ for nodal connectivity;
264 \item \verb+MED_DESCENDING+ for descending connectivity.
265 \end{itemize}
266 \end{itemize}
267
268 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
269 \chapter{How to use MED object}
270 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
271
272 \section{General Information}
273
274 A typical use of this object is to mount in memory what is in a MED file (or
275 any type of driver in red or read/write mode) and it will manage its memory on
276 its own. Then from this object one can get some information such as~:
277
278 \begin{itemize}
279 \item the number of meshes stored in this object using the
280 {\method{getNumberOfMeshes}}.
281 \item the number of fields stored in this object using the
282 {\method{getNumberOfFields}}.
283 \item a list of mesh names using the {\method{getMeshNames}}.
284 \item a list of field names using the {\method{getFieldNames}}.
285 \item a list of MESH object using the {\method{getMesh}}
286 \item a list of FIELD object using the {\method{getField}}
287 \item a list of SUPPORT object on all type of entities (node, cell,
288  face in 3d or edge on 2d) using the {\method{getSupport}}.
289 \end{itemize}
290
291 The destructor of this object will destruct itself all FIELD, SUPPORT and MESH
292 objects; via its get method you will have a pointer on this object and you
293 should never delete it.
294
295 One can add as well some MESH or FIELD object via the {\method{addMesh}} and
296 the {\method{addField}} respectively.
297
298 To write a complete MED object in an available writing format, on may use
299 {\method{addDriver}} and then {\method{write}}.
300
301 For an example using these methods, one may see the Python scripts in the
302 directory \verb+$MED_ROOT_DIR/bin/salome/+,\verb+testMedObj.py+, or C++
303 example program in the directory \verb+$MED_SRC_DIR/src/MEDMEM+,
304 \verb+duplicateMED.cxx+.
305
306 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
307 \chapter{How to use MESH object}
308 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
309
310
311 \section{General Information}
312
313 We could get some general information about a MESH object such as~: 
314
315 \begin{itemize}
316 \item name (\method{getName}) 
317 \item a description (\method{getDescription}) 
318 \item the space dimension (\method{getSpaceDimension}) 
319 \item the mesh dimension (\method{getMeshDimension}) 
320 \end{itemize}
321
322 Here is a small C++ example program which the Python version may be found in
323 \ref{MESHgeneral.py}.
324
325 \fileCxx{MESHgeneral.cxx}
326
327 \section{Information about nodes}
328
329 \begin{enumerate}
330 \item I want to get the number of nodes~: Really simple, use \method{getNumberOfNodes}. 
331 \item I want to get the coordinates components names~: use \method{getCoordinatesNames}
332 which returns a string array (one string for each space dimension) 
333 \item I want to get the coordinates components units~: use \method{getCoordinatesUnits}
334 which returns a string array (one string for each space dimension) 
335 \item I want to get the coordinates system~: use \method{getCoordinatesSystem}
336 which returns a string (\verb+"CARTESIAN"+, \verb+"CYLINDRICAL"+ or \verb+"SPHERICAL"+). 
337 \item I want to get the nodes coordinates~: use \method{getCoordinates}
338 which return a pointer to the coordinates array where values are interlace
339 or no. 
340
341 \textbf{Warning~:}
342
343 \begin{itemize}
344 \item When we get coordinates in \verb+MED_NO_INTERLACE+ mode, we get an
345 array where values are ordered like (\verb+X1,X2,X..., Y1,Y..., Z1,Z...+). 
346 \item When we get coordinates in \verb+MED_FULL_INTERLACE+ mode, we get
347 an array where values are ordered like (\verb+X1,Y1,Z1, X2,Y2,Z2, ...+). 
348 \end{itemize}
349 \item I want to get one particular value of coordinate~: use \method{getCoordinate}
350 which returns the value of \( i^{th} \) node and \( j^{th} \) axis.
351 \end{enumerate}
352
353 Here is a small C++ example program which the Python version may be found in
354 \ref{MESHcoordinates.py}.
355
356 \fileCxx{MESHcoordinates.cxx}
357
358 \section{Information about cells}
359
360 \begin{enumerate}
361 \item I want to get the number of geometric type for a mesh entity~: use
362 \method{getNumberOfTypes}
363
364
365 \textbf{C++ Example~:}
366
367 \verb+int NumberOfCellsTypes = myMesh.getNumberOfTypes(MED_CELL);+
368
369 %%%%%%%%%%%%%%%%%
370 \item I want to get all geometric type for a mesh entity~: use 
371 \method{getTypes} to get an array of \verb+medGeometryElement+ 
372 (to use directly in others methods).
373
374 \textbf{C++ Example~:}
375
376 \verb+const medGeometryElement * Types = myMesh.getTypes(MED_CELL);+
377
378 (array is of size \verb+NumberOfCellsTypes+)
379
380 \item I want to get the number of cells~: use \method{getNumberOfElements}
381 which return this information. You must give the mesh entity (\verb+MED_CELL+,
382 \verb+MED_FACE+, \verb+MED_EDGE+ or \verb+MED_NODE+) and a geometric
383 type of this entity.
384
385
386 \textbf{C++ Example~:}
387
388 \verb+int NumberOfTriangle = myMesh.getNumberOfElements(MED_FACE,MED_TRIA3);+
389
390 \verb+int NumberOfFace = myMesh.getNumberOfElements(MED_FACE,MED_ALL_ELEMENT);+
391
392 \item I want to get the geometric type of one element~: use \method{getElementType}
393 which return a \verb+medGeometryElement+.
394
395
396 \textbf{C++ Example~:}
397
398 \verb+medGeometryElement myType = myMesh.getElementType(MED_FACE,10);+
399
400 Return the \verb+medGeometryElement+ of \( 10^{th} \) face.
401
402 \item I want to get a connectivity~: use \method{getConnectivity} which
403 return an array with connectivity values.
404
405
406 \label{getConnectivity}
407
408 \textbf{C++ Example~:}
409
410 \begin{verbatim}
411 int NumberOfTetrahedron = myMesh.getNumberOfElements(MED_CELL,MED_TETRA4);
412 const int * TetrahedronConnectivity =
413          myMesh.getConnectivity(MED_FULL_ENTERLACE,
414                                 MED_NODAL,
415                                 MED_CELL,
416                                 MED_TETRA4);
417 \end{verbatim}
418 \verb+TetrahedronConnectivity+ contain nodal connectivity
419 of tetrahedron in mesh. It is arranged in full enterlace mode and
420 its size is \verb+NumberOfTetrahedron x 4+.
421
422 If you want to get connectivity of all elements (with \verb+Type=MED_ALL_ELEMENTS+),
423 you must use the index array (return by \method{getConnectivityIndex})
424 to get connectivity for each elements (see example \myref{MESHconnectivities.cxx}).
425
426 \item I want to get an element number from a connectivity~: use \method{getElementNumber}
427 which return the global number of a given connectivity.
428
429
430 \textbf{C++ Example~:}
431 \begin{verbatim}
432 int * myElementConnectivity = {2,10,12,14};
433 int myNumber = myMesh.getElementNumber(MED_NODAL,MED_CELL,
434                                              myElementConnectivity);
435 \end{verbatim}
436
437 %%%%%%%%%%%  WITH POLY METHODS %%%%%%%%%%%%
438
439 \item The listed above methods do not take into account information about
440   \verb+polygonal+ and \verb+polyhedral+ cells contained in a MESH object. To get
441   full information about cell types, use the same methods with
442   \verb+WithPoly+ postfix:
443 \begin{itemize}
444 \item use \method{getNumberOfTypesWithPoly} to get the number of
445   geometric types for a mesh entity;
446 \item use \method{getTypesWithPoly} to get all geometric types for a mesh entity;
447 \item use \method{getNumberOfElementsWithPoly} to get the number of cells;
448 \item use \method{getElementTypeWithPoly} to get the geometric type of
449   one element.
450 \end{itemize}
451 There are separate methods to get number of polygons and polyhedrons:
452 \method{getNumberOfPolygons} and \method{getNumberOfPolyhedron}
453
454 To get connectivity of polygonal elements, use \method{getPolygonsConnectivity} along with
455 \method{getPolygonsConnectivityIndex} (see example \myref{MESHconnectivities.cxx}).
456
457 To get nodal connectivity of polyhedral elements, it is necessary use together
458 3 methods: \method{getPolyhedronConnectivity}, \method{getPolyhedronFacesIndex}
459 and \method{getPolyhedronIndex} (see example \myref{MESHconnectivities.cxx}).
460
461 \end{enumerate}
462
463 Here is a small C++ example program which the Python version may be found in
464 \ref{MESHconnectivities.py}.
465
466 \fileCxx{MESHconnectivities.cxx}
467
468 \section{Information about FAMILY and GROUP}
469
470 If one wants to get from a MESH object
471
472
473
474
475 To write a complete MESH object in an available writing format, on may use
476 {\method{addDriver}} and then {\method{write}}.
477
478 For an example using these methods, one may see the Python scripts in the
479 directory \verb+$MED_ROOT_DIR/bin/salome/+,\verb+med_test1.py+, or C++ example
480 program in the directory \verb+$MED_SRC_DIR/src/MEDMEM+, \verb+med_test.cxx+.
481
482 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
483 \chapter{How to use SUPPORT object}
484 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
485
486 \section{Create a SUPPORT object}
487
488 \label{CreateSupport}
489
490 To create a SUPPORT object, you must give : 
491
492 \begin{itemize}
493 \item a reference to a MESH object 
494 \item its name 
495 \item on which mesh entity it apply to 
496 \end{itemize}
497 \textbf{C++ example~:}
498
499 \verb+SUPPORT mySupport(myMesh,"support on all faces",MED_FACE) ;+
500 By default, this support is defined on all elements of the given entity.
501
502 If you want a restricted SUPPORT, you must add manualy information
503 about what do you want~: 
504
505 \begin{itemize}
506 \item is not on all elements~: \verb+mySupport.setAll(false);+
507 \item on how many geometric type~:\\
508  \verb+mySupport.setNumberOfGeometricType(myNumberOfGeometricType);+
509 \item on which geometric type~:\\
510  \verb+mySupport.setGeometricType(myGeometricType);+
511 \item Temporary : the Gauss point number for each geometric type~:\\
512  \verb+mySupport.setNumberOfGaussPoint(myNumberOfGaussPoint);+
513 \item the number of elements for each geometric type~:\\
514  \verb+mySupport.setNumberOfEntities(myNumberOfEntities);+
515 \item the total number of elements~:\\
516  \verb+mySupport.setTotalNumberOfEntities(myTotalNumberOfEntities);+
517 \item the array which contains elements for each geometric type~:\\
518  \verb+mySupport.setNumber(myNumber);+
519 \end{itemize}
520 You could also use \method{setpartial} which set all you need.
521
522
523 \section{Use a SUPPORT object}
524
525 You could get all basic information (as you set them in \myref{CreateSupport})~: 
526
527 \begin{itemize}
528 \item \verb+getName()+
529 \item \verb+getDescription()+
530 \item \verb+getMesh()+
531 \item \verb+getEntity()+
532 \item \verb+isOnAllElements()+
533 \item \verb+getNumberOfTypes()+
534 \item \verb+getTypes()+
535 %\item \verb+getNumberOfGaussPoint()+
536 %\item \verb+getNumberOfGaussPoint(myGeometricType)+
537 \item \verb+getGeometricTypeNumber()+
538 \item \verb+getNumberOfElements(myGeometricType)+
539 \item \verb+getNumber(myGeometricType)+
540 \item \verb+getNumberIndex()+
541 \end{itemize}
542 For details about this methods, see the reference manual \cite{RefManualMedFile}.
543
544 The use of \method{getNumber} and \method{getNumberIndex} are the
545 same as \method{getConnectivity} and \method{getConnectivityIndex}
546 (see item \myref{getConnectivity}
547
548 There is another particular method to blend another SUPPORT object
549 into it.
550
551 For example in C++ : 
552 \begin{verbatim}
553 SUPPORT mySupport ;
554 SUPPORT myOtherSupport ;
555 ...
556 mySupport.blending(myOtherSupport) ;
557 \end{verbatim}
558
559 \verb+mySupport+ contain now all elements defined originally in it,
560 more those defined in \verb+myOtherSupport+.
561
562
563 \section{Case of FAMILY object}
564
565 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) :
566 \begin{itemize}
567 \item \method{getIdentifier} return the family identifier (an integer)
568
569 \item \method{getNumberOfAttributes} return the number of attributes of this family
570 \item \method{getAttributesIdentifiers} and \method{getAttributeIdentifier} return an integer array or an integer that represent attribut identifier.
571 \item \method{getAttributesValues} and \method{getAttributeValue} return an integer array or an integer that represent attribut value.
572 \item \method{getAttributesDescriptions} and \method{getAttributeDescription} return a string array or a string that represent attribut description.
573
574 \item \method{getNumberOfGroups} return the number of groups which it belog to.
575 \item \method{getGroupsNames} and \method{getGroupName} return a string array or a string that represent the group name which it belog to.
576
577 \end{itemize}
578
579 \section{Case of GROUP object}
580
581 A GROUP is a SUPPORT with some additionnal methods to find FAMILY that make up it :
582 \begin{itemize}
583 \item \method{getNumberOfFamilies} return the number of FAMILY that make up the GROUP ;
584 \item \method{getFamilies} and \method{getFamily} return a FAMILY  array or a FAMILY that  make up the GROUP.
585 \end{itemize}
586
587 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
588 \chapter{How to use Field}
589 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
590
591 \section{Introduction}
592
593 A field is characterized by its name (\method{getName}) and an optional description (\method{getDescription}).
594
595 It is also characterized by this calculating moment : 
596 \begin{itemize}
597 \item an iteration number (time step number)
598 \item an order number (use if there are internal iteration in a time step)
599 \item the time that correspond to this iteration number.
600 \end{itemize}
601
602 By default, there are no iteration and order number defined (value 
603 MED\_NOPDT and MED\_NONOR).
604
605 A field contain values which apply on some nodes or elements (cell, face or edge).
606
607 We find these informations from a SUPPORT object (see \method{getSupport}).
608
609 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}). 
610
611 To get values of a FIELD, you could use \method{getValue}, \method{getValueI} 
612 and \method{getValueIJ}~: 
613
614 \begin{itemize}
615 \item First return a reference to all values in the given mode (full or no 
616 interlace).
617 \item Second return a reference to $i^{th}$ element values or component values (in accordance with the given mode).
618 \item Third return the $j^{th}$ component of $i^{th}$ element.
619 \end{itemize}
620
621 Here is a small C++ example program which the Python version may be found in
622 \ref{FIELDgeneral.py}.
623
624 \fileCxx{FIELDgeneral.cxx}
625
626 \section{Create a Field}
627
628 It is simple to create a field object. You must know its SUPPORT and the number of components.
629
630 \textbf{Example :} 
631 \verb+FILED<double> myField(mySupport,NumberOfComponents) ;+
632
633 You must now set a name (\method{setName}) and optionaly a description 
634 (\method{setDescription}).
635
636 By default there are no iteration and order number (negative values) and 
637 time is null. You could change this by using \method{setIterationNumber},
638 \method{setOrderNumber} and \method{setTime}.
639
640 You \textbf{SHOULD} also set unit of your components with \method{setMEDComponentUnit}
641
642 To set value, use \method{setValueIJ} to put new value of field.
643
644 Here is a small C++ example program which the Python version may be found in
645 \ref{FIELDcreate.py}.
646
647 \fileCxx{FIELDcreate.cxx}
648
649 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
650 \chapter{How to use MESHING object}
651 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
652
653 This class is a derivated class of MESH class to build a MESH object from 
654 scratch (use of set methods).
655
656 All verifications are under user responsability : If arrays values or arrays 
657 dimensions are wrongs, results are impredicable.
658
659 All arrays in arguments in set methods are duplicated in MESHING object.
660
661 \section{Build a MESHING}
662
663 \label{BuildMeshing}
664
665 \subsection{Coordinates}
666
667 First we must defined points coordinates of the mesh. We use 
668 \method{setCoordinates}.
669
670 \textbf{C++ Example~:}
671 \begin{verbatim}
672 MESHING myMeshing ;
673 const int SpaceDimension=2;
674 const int NumberOfNodes=6;
675 int * Coordinates = new int[SpaceDimension*NumberOfNodes] ;
676 string System="CARTESIAN";
677 medModeSwitch MED_FULL_INTERLACE ;
678 myMeshing.setCoordinates(SpaceDimension,NumberOfNodes,Coordinates,System,Mode);
679 \end{verbatim}
680
681 Then you could set the coordinates names and units (with 
682 \method{setCoordinatesNames} and \method{setCoordinatesUnits}).
683
684 \subsection{Connectivities}
685
686 When coordinates are defined, we could defined connectivities.
687
688 First we must defined connectivity of MED\_CELL elements. 
689 After, we could defined constituent connectivity if necesary 
690 (MED\_FACE and/or MED\_EDGE).
691
692 For each connectivities, you could use some methods in the following order :
693 \begin{itemize}
694 \item \method{setNumberOfTypes} to set the number of differents geometrics 
695 types (3 for example). This method allocates all arrays which size is this 
696 number ;
697 \item \method{setTypes} to set the differents geometrics types 
698 ({MED\_TETRA4,MED\_PYRA5,MED\_HEXA8} for example). Types should be given 
699 in increasing order of number of nodes for this type ;
700 \item \method{setNumberOfElements} to set the number of elements for 
701 each geometric type. This method allocates connectivities array ;
702 \item \method{setConnectivity} to set the connectivity in MED\_FULL\_INTERLACE
703 mode for each geometric type (use \method{setPolygonsConnectivity} and
704 \method{setPolyhedraConnectivity} for poly elements);
705 \end{itemize}
706
707 \textbf{C++ Example~:}
708 \begin{verbatim}
709 MESHING myMeshing ;
710 myMeshing.setCoordinates(SpaceDimension,NumberOfNodes,Coordinates,System,Mode);
711
712 myMeshing.setNumberOfTypes(2,MED_CELL);
713 myMeshing.setTypes({MED_TRIA3,MED_QUAD4},MED_CELL);
714 myMeshing.setNumberOfElements({3,2},MED_CELL); // 3 MED_TRIA3 and 2 MED_QUAD4
715 myMeshing.setConnectivity({1,2,3,6,8,9,4,5,6},MED_CELL,MED_TRIA3);
716 myMeshing.setConnectivity({1,3,4,5,4,5,7,8},MED_CELL,MED_QUAD4);
717 \end{verbatim}
718
719
720 \section{Defined a GROUP object}
721
722 To add a group in a MESHING object, use \method{addGroup}.
723
724 This method duplicate the GROUP object in the MESH object.
725
726 To build this GROUP object, use SUPPORT methods \ref{CreateSupport} to set all attributes.
727
728 \subsection{WARNING}
729
730 For instance, translation from GROUP objects to FAMILY objects are not completed !
731
732 You MUST set GROUP objects as if they are FAMILY objects.
733
734 This feature will be fully implemented in next release of med memory. 
735
736 Here is a small C++ example program which the Python version may be found in
737 \ref{MESHINGexample.py}.
738
739 \fileCxx{MESHINGexample.cxx}
740
741 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
742 \chapter{Using drivers}
743 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
744
745 The generic driver mecanism gives users the possibility to write/read
746 the content of an object according to a specified file format. The
747 semantic remains the same whatever the object is (MESH, FIELD, MED).
748 By the way it allows using several file formats for writting an object.
749
750
751 \section{Invoking a driver}
752
753
754 \subsection{Invoking a driver at creation object time}
755
756 This is the simplest way of invoking a driver. The driver parameters
757 are given to the constructor of the object.  Except for the MED object,
758 this way of invoking a driver assume you know exactly the name of
759 the MESH/FIELD you want read from a file <fileName> of type <driverType>.
760
761 ex 1.1 : For a FIELD object, invoking FIELD<double> myField(MED\_DRIVER,fileName,fieldName)
762 create a FIELD object and a driver which loads the mesh <fieldName>
763 from the MED file <fileName> (Not implemented yet !).
764
765 ex 1.2 : To remove the default driver previously created myField->rmDriver();
766
767 ex 2 : For a MESH object, invoking MESH myMesh(MED\_DRIVER,fileName,meshName)
768 create a MESH object and a driver which loads the mesh <meshName>
769 from the MED file <fileName>.
770
771 ex 3 : For a MED object, invoking MED myMed(MED\_DRIVER,fileName)
772 create a MED object to explore the MED file <fileName>.
773
774 rem 1 : ex1 is equivalent to \ref{sec:invoking_a_driver_from_the_std_drv_method}
775 ex1.
776
777 rem 2 : Since the driver has read the object, the associated file
778 is closed. You can reread the object with the default driver by calling
779 the read() method : myObject.read().
780
781 Here is a small C++ example program which the Python version may be found in
782 \ref{MEDMEM_InvokingDriverAtObjectCreationTime.py}.
783
784 \fileCxx{MEDMEM_InvokingDriverAtObjectCreationTime.cxx}
785
786 \subsection{Invoking a driver from the standard driver method of an object\label{sec:invoking_a_driver_from_the_std_drv_method}}
787
788 This way of invoking a driver give the possiblility to add several
789 drivers to an exiting object.
790
791 ex1 : First we create a FIELD without any driver FIELD<double>~{*}~myField1~=~new~FIELD<double>;
792 then we add a driver with int myDriver1 = myField1->addDriver(driverType1,
793 fileName1, fieldName1); for reading <fieldName1> from file <fileName1>
794 with myField1->read(myDriver1);
795
796 ex2 : We add a new driver of type <driverType2> int myDriver2 = myField1->addDriver(driverType2,
797 fileName2,fieldName2); in order to write myField1 in file <fileName2>
798 with <fieldName2> name using command myField1->write(myDriver2);
799
800 rem 1 : Files are openned then closed each time you call read() or
801 write() methods.
802
803 rem 2 : If you use more than a driver you need to keep the driver
804 handlers (myDriverI ).
805
806 Here is a small C++ example program which the Python version may be found in
807 \ref{MEDMEM_InvokingDriverFromStandardObjectMethod.py}.
808
809 \fileCxx{MEDMEM_InvokingDriverFromStandardObjectMethod.cxx}
810
811 \subsection{Invoking a driver and attaching it to an existing object}
812
813 The methods exposed in the two previous sections always create drivers
814 in read/write access mode. Another way of creating a driver is to
815 create a driver with a specific access mode.
816
817 ex1 : First we create a FIELD without any driver FIELD<double>~{*}~myField1~=~new
818 FIELD<double>(); then we create a read-only driver MED\_FIELD\_RDONLY\_DRIVER<double>~myRdOnlyDriver(fileName1,myField1);
819 and attached it to myField1. Finally you must set the fieldName1 you
820 want to acess in fileName1 with myRdOnlyDriver->setFieldName(fieldName1);
821 in order to read the field with myRdOnlyDriver->open(); myRdOnlyDriver->read();
822
823 Don't forget to close the file with myRdOnlyDriver->close().
824
825 ToDo : By now when you create such specific drivers, the object doesn't
826 know anything about it. 
827
828 Here is a small C++ example program which the Python version may be found in
829 \ref{MEDMEM_InvokingDriverByAttachingItToAnObject.py}.
830
831 \fileCxx{MEDMEM_InvokingDriverByAttachingItToAnObject.cxx}
832
833 \section{Using the MED driver}
834
835 The MED object provides the ability of :
836
837 \begin{enumerate}
838 \item \noindent Obtainning a reference on the whole structure contained
839 in a file.
840 \item Obtainning the list of all the Meshes/Fields names contained in a
841 file.
842 \item Obtainning a Mesh/Field reference using a name.
843 \item Writting a whole set of independent objects with a simple command. 
844 \end{enumerate}
845
846 \subsection{Exploring files}
847
848 In this first use case the user wants to explore the meshes \& fields
849 containned within a file <filename> of type given by the <drivertype>
850 parameter.
851
852 ex 1 : Calling MED {*} myMed = new MED(driverType1, fileName1); create
853 a MED object which open fileName1, read all MESHes/FIELDs relations
854 then close the file. 
855
856 This is equivalent to MED~{*}~myMed~=~new~MED(); myDriver~=~myMed->addDriver(driverType1,fileName1);
857 myMed->readFileStruct(myDriver); 
858
859 ex 2 : To get the list of meshNames from a MED object, first ask the
860 object how many meshes it had by calling int numberOfMeshes~=~myMed->getNumberOfMeshes();
861 then get the list with myMeshNames~=~new string{[}getMeshNames{]};
862 myMed->getMeshNames(myMeshNames). 
863
864 Note you can also use the deque<string> getMeshNames() method. 
865
866 ex 3 : To get a list of fieldNames from a MED object, first ask the
867 object how many fields it had by calling int numberOfFields~=~myMed->getNumberOfFields();
868 then get the list with myFieldNames~=~new string{[}getFieldNames{]};
869 myMed->getFieldNames(myFieldNames).
870
871 ex 4 :To get a particular MESH use MESH {*} myMesh1 = myMED->getMesh(myMeshNames{[}0{]}) 
872
873 ex 5 :To get a particular FIELD you first need to know what (time
874 step, iteration number) list is used by calling deque<DT\_IT\_>~myField1DtIt~=~myMed->getFieldIteration(FieldName{[}0{]})
875 ; then you can ask for getting a specific FIELD with FIELD~{*}~myField1~=~myMED->getField(myFieldNames{[}0{]},myField1DtIt{[}0{]}.dt,myField1DtIt{[}0{]}.it).
876
877 ex2 : To write the whole content of a MED object first add a driver
878 myDriver2~=~myMed.addDriver(driverType2,~fileName2); then ask for
879 writing the object myMed->write(myDriver2); (not implemented yet !) 
880
881 You can remove the driver with myMed->rmDriver(myDriver2);
882
883 rem 1 : It is possible to use multiple drivers to read a set of FIELDs
884 / MESHes from various file formats and writing the whole set through
885 a specific write.(not implemented yet !) 
886
887
888 \subsubsection{Adding existing MESHes/FIELDs objects}
889
890 Not yet implemented.
891
892 \section{Using the VTK driver}
893
894 This driver allow to save all MESH and FIELD objects in an ASCII file in 
895 VTK format \cite{vtk}.
896
897 You could use this driver only from a MED object, because VTK file format 
898 impose to write objects in particular order.
899
900 \textbf{C++ Example~:}
901 \begin{verbatim}
902 MED myMed(MED_DRIVER,"file.med");
903 myMed.read();
904 int id = myMed.addDriver(VTK_DRIVER,"file.vtk");
905 myMed.write(id) ;
906 \end{verbatim}
907
908 \section{Using the GIBI driver}
909
910 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.
911
912 \textbf{C++ Example~:}
913 \begin{verbatim}
914 MESH * myMesh= new MESH() ;     
915 GIBI_MESH_RDONLY_DRIVER myGibiMeshDriver("file.sauve", myMesh) ;
916 myGibiMeshDriver.open() ;
917 myGibiMeshDriver.read() ;
918 myGibiMeshDriver.close() ;
919 \end{verbatim}
920
921 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
922 \chapter{Appendix: Python example scripts.}\label{sec:python}
923 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
924
925 \section{Full Python example for \ref{MESHgeneral.cxx}~:}
926 \label{MESHgeneral.py}
927 \verbatiminput{@srcdir@/MESHgeneral.py}
928
929 \section{Full Python example for \ref{MESHcoordinates.cxx}~:}
930 \label{MESHcoordinates.py}
931 \verbatiminput{@srcdir@/MESHcoordinates.py}
932
933 \section{Full Python example for \ref{MESHconnectivities.cxx}~:}
934 \label{MESHconnectivities.py}
935 \verbatiminput{@srcdir@/MESHconnectivities.py}
936
937 \section{Full Python example for \ref{FIELDgeneral.cxx}~:}
938 \label{FIELDgeneral.py}
939 \verbatiminput{@srcdir@/FIELDgeneral.py}
940
941 \section{Full Python example for \ref{FIELDcreate.cxx}~:}
942 \label{FIELDcreate.py}
943 \verbatiminput{@srcdir@/FIELDcreate.py}
944
945 \section{Full Python example for \ref{MESHINGexample.cxx}~:}
946 \label{MESHINGexample.py}
947 \verbatiminput{@srcdir@/MESHINGexample.py}
948
949 \section{Full Python example for \ref{MEDMEM_InvokingDriverAtObjectCreationTime.cxx}~:}
950 \label{MEDMEM_InvokingDriverAtObjectCreationTime.py}
951 \verbatiminput{@srcdir@/MEDMEM_InvokingDriverAtObjectCreationTime.py}
952
953 \section{Full Python example for \ref{MEDMEM_InvokingDriverFromStandardObjectMethod.cxx}~:}
954 \label{MEDMEM_InvokingDriverFromStandardObjectMethod.py}
955 \verbatiminput{@srcdir@/MEDMEM_InvokingDriverFromStandardObjectMethod.py}
956
957 \section{Full Python example for \ref{MEDMEM_InvokingDriverByAttachingItToAnObject.cxx}~:}
958 \label{MEDMEM_InvokingDriverByAttachingItToAnObject.py}
959 \verbatiminput{@srcdir@/MEDMEM_InvokingDriverByAttachingItToAnObject.py}