From: ageay Date: Thu, 21 Oct 2010 06:40:04 +0000 (+0000) Subject: *** empty log message *** X-Git-Tag: Step0_WithoutSPLITTER~1 X-Git-Url: http://git.salome-platform.org/gitweb/?a=commitdiff_plain;h=72426f254d00bda42a0122b6d1d54edb606f0d06;p=tools%2Fmedcoupling.git *** empty log message *** --- diff --git a/doc/doxygen/Doxyfile_med_user.in b/doc/doxygen/Doxyfile_med_user.in index 95bbc0d62..86ca90e89 100644 --- a/doc/doxygen/Doxyfile_med_user.in +++ b/doc/doxygen/Doxyfile_med_user.in @@ -73,14 +73,16 @@ INPUT = @srcdir@ \ @srcdir@/../../src/INTERP_KERNEL \ @srcdir@/../../src/INTERP_KERNEL/Geometric2D \ @srcdir@/../../src/MEDCoupling \ + @srcdir@/../../src/MEDLoader \ @srcdir@/../../src/MEDMEM -FILE_PATTERNS = MEDMEM_Mesh.* \ +FILE_PATTERNS = MEDMEM_GMesh.* \ + MEDMEM_Mesh.* \ MEDMEM_Grid.* \ MEDMEM_Meshing.* \ MEDMEM_Support.* \ MEDMEM_Field.* \ - MEDMEM_Med.* \ + MEDMEM_MedFileBrowser.* \ InterpKernelDEC.* \ DEC.* \ MPIProcessorGroup.* \ @@ -95,6 +97,7 @@ FILE_PATTERNS = MEDMEM_Mesh.* \ PlanarIntersector.* \ TargetIntersector.* \ Interpolation.* \ + InterpolationOptions.* \ InterpKernelGeo2DAbstractEdge.* \ InterpKernelGeo2DEdge.* \ InterpKernelGeo2DEdgeArcCircle.* \ @@ -111,14 +114,21 @@ FILE_PATTERNS = MEDMEM_Mesh.* \ MEDCouplingCMesh.* \ MEDCouplingExtrudedMesh.* \ MEDCouplingFieldDouble.* \ + MEDCouplingField.* \ MEDCouplingFieldDiscretization.* \ MEDCouplingTimeDiscretization.* \ + MEDCouplingTimeLabel.* \ + MEDCouplingRefCountObject.* \ + MEDCouplingMemArray.* \ + MEDCouplingRemapper.* \ + MEDLoader.* \ *.dox RECURSIVE = NO EXCLUDE = CVS EXCLUDE_PATTERNS = *~ EXAMPLE_PATH = @srcdir@/../../src/ParaMEDMEM/ \ @srcdir@/../../doc/MEDMEM \ + @srcdir@/../../src/MEDMEMBinTest \ @srcdir@/../../src/MEDMEM EXAMPLE_PATTERNS = *.cxx *.py EXAMPLE_RECURSIVE = NO diff --git a/doc/doxygen/MED_class.dox b/doc/doxygen/MED_class.dox deleted file mode 100644 index fa348a573..000000000 --- a/doc/doxygen/MED_class.dox +++ /dev/null @@ -1,24 +0,0 @@ - -/*! -\page MED_class MED object - -\section MED_general General Information - -This object is used to give information about the different -meshes/supports/fields that are contained in a file. -This enables the user to know about the file content without -loading the meshes in memory. Also, it can be useful for -memory management since meshes, supports and fields accessed through a MED -object are destroyed when the MED object is destroyed. - -\section MED_object_outline -The methods are described in the following sections : -- constructors : \ref MED_constructors -- query methods : \ref MED_query - -For an example using these methods, one may see the Python scripts in the -directory \c $MED_ROOT_DIR/bin/salome/,\c testMedObj.py, or C++ -example program in the directory \c $MED_SRC_DIR/src/MEDMEM, -\c duplicateMED.cxx. - -*/ \ No newline at end of file diff --git a/doc/doxygen/dualmesh.dox b/doc/doxygen/dualmesh.dox deleted file mode 100644 index f4d462b30..000000000 --- a/doc/doxygen/dualmesh.dox +++ /dev/null @@ -1,42 +0,0 @@ -/*! -\page dualmesh DualMESH - -The \ref INTERP_KERNEL::DualMESH "DualMESH" class is an auxiliary class used to perform P0->P1 -interpolation in \ref interpkernel. It takes place of target mesh in -interpolation process and is initialized by the target mesh. - -DualMESH inherits from MEDMEM::MESH. It's API consists of only a -constructor with one argument of the input target MEDMEM::MESH. - -The dual mesh is a polygonal mesh in 2D space or polyhedral mesh in 3D space -consisting of dual cells built around each node of input target mesh. - -In 2D the dual cell is bound by edges connecting barycentres of cells -sharing the input node with middles of cell edges ending at the input node. - -In 3D the dual polyhedron is bound by triangle faces. Each triangle is built -on three following points: -- barycentre of a cell sharing the input node; -- barycentre of a face bounding the cell and sharing the input node; -- middle of an edge bounding the face and ending at the input node. - -\section DualMESHUsage DualMESH usage - -An exemple of DualMESH usage to perform P0->P1 interpolation with INTERP_KERNEL::Remapper : - -\code -... -std::string sourceFileName("source.med"); -MEDMEM::MESH med_source_mesh(MED_DRIVER,sourceFileName,"Source_Mesh"); -std::string targetFileName("target.med"); -MEDMEM::MESH med_target_mesh(MED_DRIVER,targetFileName,"Target_Mesh"); -FIELD sourceField(MED_DRIVER,sourceFileName,"Density",0,0); -FIELD targetField; -Remapper mapper; -mapper.prepare(med_source_mesh, DualMESH(med_target_mesh), "P0P1"); //<--- DualMESH -mapper.transfer(sourceField,targetField); -//use targetField -... -\endcode - -*/ diff --git a/doc/doxygen/interpkernel.dox b/doc/doxygen/interpkernel.dox index afe4b70c3..bfed9661f 100644 --- a/doc/doxygen/interpkernel.dox +++ b/doc/doxygen/interpkernel.dox @@ -214,10 +214,33 @@ interpolation. To be able to be filled by the interpolator the \c MatrixType cla \subsection InterpKerHighLevUsage high-level usage -This the simplest mode of usage of interpolator. This way is strongly -linked with MED data-structure. All interpolators is completely hidden -to you. Even sparse interpolation matrix is hidden. An exemple of -usage : +The simplest mode of usage of interpolator in sequential mode is to use REMAPPER classes. These classes fulfill HXX2SALOME rules to allow the user to use it +in coupling graphs. 2 REMAPPERS exist, ParaMEDMEM::MEDCouplingRemapper and Remapper. These classes are strongly linked to their corresponding data structure, respectively +MEDCoupling and MEDMEM. In return, all interpolation request and spare interpolation matrix are hidden from you. Here two examples of REMAPPER classes : + +- If you intend to use MEDCoupling data struture, ParaMEDMEM::MEDCouplingRemapper class should be used : + +\code +... +const char sourceFileName[]="source.med"; +MEDCouplingFieldDouble *sourceField=MEDLoader::ReadFieldCell(sourceFileName,"Source_Mesh",0,"Density",/*iteration*/0,/*order*/0); +const char targetFileName[]="target.med"; +MEDCouplingUMesh *med_target_mesh=MEDLoader::ReadUMeshFromFile(targetFileName,"Target_Mesh",0); +// +sourceField->setNature(ConservativeVolumic);//Specify nature is needed to allow remapper object to apply correct policy for denominator computation ! +MEDCouplingRemapper remapper; +remapper.setPrecision(1e-12); +remapper.setIntersectionType(INTERP_KERNEL::Triangulation); +remapper.prepare(sourceField->getMesh(),med_target_mesh,"P0P0"); +MEDCouplingFieldDouble *targetField=remapper.transferField(sourceField,/*default_value*/4.57);//Any target cell not intercepted by any source cell will have value set to 4.57. +... +// clean-up +targetField->decrRef(); +sourceField->decrRef(); +med_target_mesh->decrRef(); +\endcode + +- If you intend to use MEDMEM data structure, Remapper class should be used : \code ... @@ -244,7 +267,29 @@ As consequence of genericity of interpolators, they are usable only by instanciating an underneath mesh data structure. The two following examples show how to use interpolator at this level. -- The simplest way to use the interpolator with MED datastructure is : +- The simplest way to use interpolator with MEDCoupling datastruture is put in the following example. Note that this code is close to those used by ParaMEDMEM +to perform synchronization of meshes between processes of a MPI communicator : + +\code +... +MEDCouplingUMesh *med_source_mesh=MEDLoader::ReadUMeshFromFile("source.med","Source_mesh",0); +MEDCouplingUMesh *med_target_mesh=MEDLoader::ReadUMeshFromFile("target.med","Target_mesh",0); +MEDCouplingNormalizedUnstructuredMesh<2,2> wrap_source_mesh(med_source_mesh); +MEDCouplingNormalizedUnstructuredMesh<2,2> wrap_target_mesh(med_target_mesh); +// Go for interpolation... +INTERP_KERNEL::Interpolation2D myInterpolator; +myInterpolator.setPrecision(1e-7); +myInterpolator.setIntersectionType(INTERP_KERNEL::Geometric2D); +std::vector > resultMatrix; +INTERP_KERNEL::Matrix resultMatrix2; +// here the interpolation is performed twice for this code to show the capability of storing data of out matrix in 2 different data structures. +myInterpolator.interpolateMeshes(wrap_source_mesh,wrap_target_mesh,resultMatrix,"P0P0"); +myInterpolator.interpolateMeshes(wrap_source_mesh,wrap_target_mesh,resultMatrix2,"P0P0"); +//Ok resultMatrix and resultMatrix2 contain matrix now +... +\endcode + +- An another way to use the interpolator with MEDMEM datastructure is : \code ... diff --git a/doc/doxygen/main.dox b/doc/doxygen/main.dox index 69d054975..d7e4c3893 100644 --- a/doc/doxygen/main.dox +++ b/doc/doxygen/main.dox @@ -19,6 +19,8 @@ localization library. - Chapter \ref medcoupling describes DataStructures used for cross process exchange of meshes and fields. - Chapter \ref paramedmem describes its MPI implementation, which is called %ParaMEDMEM. +- Chapter \ref medloader describes API for I/O from or to a MED file +coming from a \ref medcoupling data structure. - Chapter \ref tools describes various tools based on MEDMEM that can be helpful for handling MED files (conversion tools and splitting tools). diff --git a/doc/doxygen/medfilebrowser.dox b/doc/doxygen/medfilebrowser.dox new file mode 100644 index 000000000..622f00666 --- /dev/null +++ b/doc/doxygen/medfilebrowser.dox @@ -0,0 +1,22 @@ + +/*! +\page MEDFILEBROWSER_class MEDFILEBROWSER + +\section MED_general General Information + +This object is used to get information about the different +meshes/fields that are contained in a file. +This enables the user to know about the file content without +loading med objects in memory. + +\section MEDFILEBROWSER_object_outline Outline +The methods are described in the following sections : +- \ref MEDFILEBROWSER_constructors +- \ref MEDFILEBROWSER_query + +For an example using these methods, one may see the Python scripts in the +directory \c $MED_ROOT_DIR/bin/salome/,\c med_test1.py, or C++ +example program in the directory \c $MED_SRC_DIR/src/MEDMEMBinTest, +\c duplicateMED.cxx. + +*/ diff --git a/doc/doxygen/medloader.dox b/doc/doxygen/medloader.dox new file mode 100644 index 000000000..9cb490e52 --- /dev/null +++ b/doc/doxygen/medloader.dox @@ -0,0 +1,357 @@ +/*! +\page medloader MEDLoader + +\section MEDLoaderIntro Introduction + +MEDLoader is a package in charge of loading from a file or write to a file +in MED format a \ref medcoupling data structure. The fact that these +functionalities are not merged in \ref medcoupling is explained by a +willingness of reducing as much as possible the dependancies of \ref medcoupling libraries. + +As a MED file can combine several \ref medcoupling aspects in one (for exemple meshes in +MED file on different mesh dimension with families and groups) the API of MEDLoader is much more rich than simply read and write. + +MEDLoader offers \b static methods whose method names have the first +character in capital. You are intended to use these methods. The following +chapters will try to describe in details some of important ones. + +The basic idea of MEDLoader is to exploite as much as possible MED +file capabilities to store MEDCoupling data file in a MED file and +reversely to load from a MED file into a MEDCoupling data structure. +Basically, the info on components of ParaMEDMEM::DataArrayDouble +instances are stores into components and units into MED files. The +name of meshes and fields are used by MEDLoader to use it as this into +MED file. A field f with \ref ParaMEDMEM::MEDCouplingTimeDiscretization +"time discretization" set to ONE_TIME, the value of +\c f->getTime(time,iteration,order) are used by MEDLoader to store +identifies the field into MED file. All strings used by MEDLoader to +use it into MED file should fulfill the rules of MED file where length +are limited. +That's why the user should be aware of these constaints when trying to read/write a MED file using MEDLoader. +MEDLoader tries to manage that by protecting the user by throwing exceptions when the rules are not followed. + +\section MEDLoaderMainC Main concepts of MED files + +Here we will describes some of basic concepts of MED files in order to +use the best methods proposed by MEDLoader API. + +\subsection MEDLoaderMEDFileGen Basics in MED files + +First of all MEDLoader \b will \b not read MED files whose version is +\b lower \b than \b 2.2. The MEDLoader::CheckFileForRead will perform +the check of that before any attempt of read. + + +For new comers in MED file world some of basics principles are +recalled here. Let's recall basic principles that explains some of the aspect of MEDLoade API. +\anchor MEDLoaderMeshNameConstraint MED file can contain several meshes. These meshes are +discriminated by their names (two meshes could not have the same +names). By the same way a MED file can contain several fields in MED. +So MEDLoader propose to you the MEDLoader::GetMeshNames method to +discover all the mesh names contained in your file. + +A field is also discriminated by its name. The method MEDLoader::GetCellFieldNamesOnMesh and MEDLoader::GetNodeFieldNamesOnMesh are available to know all fields +respectively on cells and on nodes lying on a specified mesh. + + A field is defined by several time steps discriminated by a pair of int +(iteration,order). It is \b not possible to store 2 time steps of a same +field having the same iteration and order +number. The floatting point value attached on this couple of ids (iteration,order) is only present for information. +Static methods MEDLoader::GetCellFieldIterations and +MEDLoader::GetNodeFieldIterations return a vector of pair containing +each respectively iteration and order. + +A time step of a field lyies on one \b or \b more mesh(es) specified by its \b or \b their name. A time step of a field in +MED file could be defined on point \b and on cell \b and, \b or on gauss points \b and, \b or on point per element. + +This recalled specificities of MED file explains that it is necessary to specify +each time, at field-read time, the type of field, the iteration and order +number the mesh you are interested in. + +\subsection MEDLoaderMEDFileMesh Meshes in MED files + +In MED file meshes could combine in one unstructured mesh cells that +have different dimension. For example it is possible to mix +MED_TETRA4, MED_TRIA6, MED_SEG2, MED_POINT0, MED_POLYGON, +MED_POLYHEDRA in a same mesh. In MEDCouplingUMesh such a mix is not +allowed as described \ref MEDCouplingUMeshes "here". So to \b read such mesh it +is important to know which meshdimension you are interested to. In API +the parameter \b meshDimRelToMax discreminates the meshdim you are +interested to relatively to the maximal dimension of cells contained +in the mesh in file. + +Let's take 2 examples : + +- If you have a mesh called "MyMesh" in file "file1.med" with +MED_POLYGON, MED_TRI3, MED_SEG2 and MED_SEG3 : The max dimension of +cells is 2 (for MED_POLYGON and MED_TRI3). So if you want exclusively +cells with type MED_POLYGON and MED_TRI3 you should use : + +\code +MEDCouplingUMesh *m2D=MEDLoader::ReadUMeshFromFile("file1.med","MyMesh",0); +\endcode + +If you are interested in MED_SEG2 and MED_SEG3 you should use : + +\code +MEDCouplingUMesh *m1D=MEDLoader::ReadUMeshFromFile("file1.med","MyMesh",-1); +\endcode + +The method MEDLoader::ReadUMeshDimFromFile could +help you to have this mesh dimension. +\anchor MEDLoaderExample2 +- Consider an another mesh called "Example2" in file "file2.med" +containing MED_POLYHEDRA, MED_TETRA4, MED_QUAD8, MED_TRI6, MED_SEG2 +and MED_POINT0. In this case you will have : + +\code +assert(3==MEDLoader::ReadUMeshDimFromFile("file2.med","Example2")); +\endcode + +To get 3D cells (MED_POLYHEDRA and MED_TETRA4) you should type : +\code +MEDCouplingUMesh *m3D=MEDLoader::ReadUMeshFromFile("file2.med","Example2",0); +\endcode + +To get 2D cells (MED_TRI6 and MED_QUAD8) you should type : + +\code +MEDCouplingUMesh *m2D=MEDLoader::ReadUMeshFromFile("file2.med","Example2",-1); +\endcode + +To get 1D cells (MED_SEG2) you should type : + +\code +MEDCouplingUMesh *m1D=MEDLoader::ReadUMeshFromFile("file2.med","Example2",-2); +\endcode + +And finally for 0D cells (MED_POINT0) you will write : + +\code +MEDCouplingUMesh *m0D=MEDLoader::ReadUMeshFromFile("file2.med","Example2",-3); +\endcode + +To finish this subsection, it is important to know that MEDLoader +takes into account of the cell numbers stored in a mesh of a med +file. This renumbering allows MEDLoader to conserve the order of +MEDCoupling cells into the file. So if the renumbering of cells in MED +file is not correct an exception will be thrown. + +\subsection MEDLoaderMEDFilePoMesh Part of meshes in MED files + +A mesh contains one or more families on nodes and/or on cells. A family is a partition +(mathematical sense) of the mesh it lies to. A family can be described +by an integer field on \b all nodes and on \b all cells of a same mesh. +All cells and nodes having the same ids defines this family. This id +is called the familyId. A family is discriminated by its id. MED file +attach a name to its id to be more userfriendly. So by construction, 2 different +families could not share anything. The user can retrieve all the +families names available on a mesh with the static method MEDLoader::GetMeshFamiliesNames. + +A group is a set of families. So groups can overlap each other, +contrary to families. Groups are also discriminated by a name. As for +families the static method to retrieves the groups of a specified mesh is MEDLoader::GetMeshGroupsNames. + +MEDLoader allows you to retrieve the +corresponding "part of meshes" thanks to static methods +MEDLoader::ReadUMeshFromFamilies and MEDLoader::ReadUMeshFromGroups. +This method allows you to combine several families and groups in the +same returned mesh. + +\subsection MEDLoaderMEDFileField Reading a field at one time step in MED files + +A field at one time step on one mesh, with one entity (cell, node) +lies on all mesh on on a part of it. In this last case a definition of +a profile is needed. Even if the notions of profile on mesh and group +on mesh could appear close, these two concepts are totally +disconnected in MED file. +The aspect of profile is managed by MEDLoader, thats why this +aspect does not appear in the MEDLoader API. +So to retrieve a field on 3D cell called "F1Cell" in example file +\ref MEDLoaderExample2 "file2.med (seen in meshes section)" on a mesh "Example2" on time +step defined by iteration number 2 and iteration 3 the request will be : + +\code +MEDCouplingFieldDouble *f1Cell_3D=MEDLoader::ReadFieldCell("file2.med","Example2",0,"F1Cell",2,3); +\endcode + +To retrive the same field (same iteration) on 2D cells only the call will be : + +\code +MEDCouplingFieldDouble *f1Cell_2D=MEDLoader::ReadFieldCell("file2.med","Example2",-1,"F1Cell",2,3); +\endcode + +\subsection MEDLoaderMEDFieldsRead Reading several field time steps at a time in MED files + +It is possible with MEDLoader to read several time steps of a field at +a time. +The advantage with this approach is to avoid to read and load several +time a same mesh. This is typically recommanded to use the following +code when you desire to load all time steps of a field on cell "myField" lying on +same mesh "mesh1" in one shot : + +\code + +std::vector > timeStepsIds=MEDLoader::GetCellFieldIterations("file4.med"); +std::vector fs=MEDLoader::ReadFieldsCellOnSameMesh("file4.med","mesh1",0,"myField",timeStepsIds); + +\endcode + +\section MEDLoaderWriteMain Writing a MED file with MEDLoader + +As MEDMEM and MED file do, MEDLoader write process separates clearly +meshes from fields. The reason is that a common use case in write mode +is to write in a first time a mesh and then writes several time steps +of a same field in appended mode. + +The fact that the write process is rarely in a one shot put a +constraint on API (as MEDMEM does) to precise to MEDLoader if you intend +to append data to an existing file, or if you want to create a new +file from scratch. This explains the presence of boolean parameter \b +writeFromScratch in API of MEDLoader starting with \b +MEDLoader::Write* . + +If \b writeFromScratch parameter is set to \b true and if the file +already exists the file will be crashed and replaced by the new +corresponding data. If \b writeFromScratch parameter is set to \b false and if the +file does \b not \b exist the new file is created, but if the file +exists MEDLoader will enter in appended mode. + +Two classes of MEDLoader write methods exists when \b writeFromScratch +is set to \b false : + +- Methods \b MEDLoader::Write*Dep : The behaviour is as MEDMEM, that + is to say, the write is done without any question in file. The + responsability is let to the user because the MED file could be + corrupted. The advantage of this method is that it is faster + because no check is done. +- Methods \b MEDLoader::Write* : MEDLoader will not corrupt your file + by always trying to append data. The consequence of that is that a + read of part (and data processing) of MED file could be needed before any attempt of + writing. So these methods could be in some cases much time and memory consuming. + +The behaviour of MEDLoader when \b writeFromScratch is set to false will be precised +for each \b MEDLoader::Write* methods is the next subsections. + +\subsection MEDLoaderWriteMesh Writing one mesh in a MED file with MEDLoader + +The first think to know is that MEDLoader is using the \b meshName in +ParaMEDMEM::MEDCouplingMesh instance to put it in MED file. + +As explained in previous section \ref MEDLoaderMeshNameConstraint "here", +a mesh in MED file is discriminated by a name, so the \b meshName +\b should \b be \b non \b empty. If it is the case an +INTERP_KERNEL::Exception will be thrown. + +To write one mesh \b myMesh with name \b "myMeshName" in a MED file \b "wfile1.med" the following code should be typed : + +\code + +MEDCouplingUMesh *myMesh=...; +myMesh->setName("myMeshName"); +MEDLoader::WriteUMesh("wFile1.med",myMesh,true); + +\endcode + +With the previous code, if "wFile1.med" file existed the file is +crashed and will contain after the call only the content of myMesh +instance. + +If you desire to append a mesh in "wFile1.med" you should type : + +\code + +MEDCouplingUMesh *myMesh=...; +myMesh->setName("myMeshName"); +MEDLoader::WriteUMesh("wFile1.med",myMesh,false); + +\endcode + +With the previous code, if the "wFile1.med" had already a mesh called "myMeshName" an +INTERP_KERNEL::Exception will be thrown. + +\subsection MEDLoaderWriteMeshes Writing several meshes in a MED file with MEDLoader + +It could be interesting to write several meshes in one shot. Two +possiblities are possible : + +- Write several instances of ParaMEDMEM::MEDCouplingUMesh + lying \b on \b same \b coords \b with \b different \b mesh \b dimension. In this case the + use of MEDLoader::WriteUMeshes is the method you should + use. Typically this method should be used to write such of file + defined \ref MEDLoaderExample2 "here". + This method first checks that all instances share the same + ParaMEDMEM::DataArrayDouble instance as coords. If not an + INTERP_KERNEL::Exception will be thrown and an invocation on + ParaMEDMEM::MEDCouplingPointSet::tryToShareSameCoords will be necessary. + +- Write a partition of meshes having \b same \b mesh \b dimension, that is to say a set of + groups and families from given meshes. As in the previous case the + check of same coords will be done (if not an INTERP_KERNEL::Exception is + thrown). After this step this method will + merge (by concerving the order in input) and will simplify the + merged mesh. After this operation, the groups will be constituted by + assigning the groups names with the conresponding names of + instance. That's why all meshes have to have a not empty name and + different each other. The method to use in this case is + MEDLoader::WriteUMeshesPartition. + +For these 2 described methods the semantic of \b writeFromScratch when +\b false is the same, that is to say : no writing +(INTERP_KERNEL::Exception thrown) will be done if the +file already exists and contains already a mesh with name 'meshName' +for MEDLoader::WriteUMeshesPartition method and the name of the first +of the vector of unstructured meshes passed as first parameter of +MEDLoader::WriteUMeshes. + +\subsection MEDLoaderWriteField Writing one time step of a field in a MED file with MEDLoader + +To write \b one \b time \b step of a field from scratch with MEDLoader is to +use MEDLoader::WriteField method. The behviour of this method depends +on the value of the \b writeFromScratch paramter : + +- When \b writeFromScratch equals to \b true, this method performs two things, it +writes the underlying mesh and write the specified time step on it. + +- When \b writeFromScatch equals to \b false, this method looks that + the underlying mesh exists (by looking the content of \c field->getMesh()->getName() ) in file. If not, the behaviour is the + same that previous case with \b writeFromScratch parameter set to + \b true. If the mesh already exists, MEDLoader reads the field and + tries to apply field on it. This operation could be rather time + consuming because a read operation is performed and a reorder + operation too. If the file already contains the same field at the + same time step (iteration and order ids) the corresponding time step + will be replaced by the field passed in parameter. + +\subsection MEDLoaderWriteFields Writing several time steps of a field in a MED file with MEDLoader + +To write a serie of time steps in a "file3.med" file lying on the same +unstructured mesh the typical code +to write is the following : + +\code + +MEDCouplingFieldDouble *f=...; +MEDLoader::WriteUMesh("file3.med",static_castf->getMesh(),true); +f->setTime(1.2,1,0); +//Writing first time step with iteration==1 and order==0 +MEDLoader::WriteFieldUsingAlreadyWrittenMesh("file3.med",f); +f->setTime(1.3,2,0); +f->applyFunc("sqrt(x)"); +//Writing second time step with iteration==2 and order==0 +MEDLoader::WriteFieldUsingAlreadyWrittenMesh("file3.med",f); + +\endcode + +In the previous code, it is important to note that the values of pair +(iteration,order) should be different between two calls to avoid that +a call to MEDLoader::WriteFieldUsingAlreadyWrittenMesh overwrites a +previous call. +An another important thing is the fact that \c f->getMesh() does not be +modified. +This method of writing presents the big advantage to be fast, because +no check neither read is performed by this method. That's why contrary +to other MEDLoader::Write* method the parameter of \b writeFromScratch +is not needed here. + +*/ diff --git a/doc/doxygen/medmem.dox b/doc/doxygen/medmem.dox index 8cc256ec4..95b9d72e1 100644 --- a/doc/doxygen/medmem.dox +++ b/doc/doxygen/medmem.dox @@ -13,10 +13,9 @@ The Med libraries are oganized in multiple layers: - CORBA API to simplify distributed computation inside SALOME (Server Side). - MED Client classes to simplify and optimize interaction of distant objects within the local solver. -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 +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). @@ -26,13 +25,14 @@ In this document, we describe the API of the Med Memory library (available in C+ As will be seen in section \ref medmem_api, the API consists of very few classes: -- a general MED container : \ref MED_class, +- a MED-file browser : \ref MEDFILEBROWSER_class, - meshes : \ref mesh , - structured meshes : \ref grid , - supports and derived classes : \ref support , - mesh generation tool : \ref meshing , - fields : \ref field , -- \ref medmem_drivers "drivers for reading and writing" in MED, GIBI and VTK files. +- \ref medmem_drivers "drivers for reading and writing" in MED, GIBI, +VTK, EnSight and Porflow files. All these are detailed in the following sections. The C++ formalism will be used for the description in these sections. @@ -85,7 +85,7 @@ a temperature at times \a t=0.0 s, \a t=1.0 s, \a t=2.0 s will be considered as MEDMEM supports data exchange in following formats: - \b GIBI - reading and writing the mesh and the fields in ASCII format. - \b VTK - writing the mesh and the fields in ASCII and binary formats. -- \b EnSight - reading and writing the mesh and the fields in ASCII and binary formats. +- \b EnSight - reading and writing the mesh and the fields in EnSigth6 and EnSigth GOLD formats (ASCII and binary). - \b PORFLOW - reading the mesh in ASCII format. Limitation of length of names in GIBI format is overcome by storing names in the specific string pile of GIBI file. @@ -124,7 +124,7 @@ At a basic usage level, the API consists in few classes which are located in the \c MEDMEM C++ namespace (consult figure \ref fig_UML_light which gives an UML diagram view of the main Med Memory classes): -- \b MED the global container; +- \b MEDFILEBROWSER the class provinding information on meshes and fields conatained in a MED file; - \b MESH the class containing 2D or 3D mesh objects; - \b SUPPORT the class containing mainly a list of mesh elements; - \b FIELD the class template containing list of values lying on a particular support. @@ -146,8 +146,7 @@ of the mesh; - read/write such fields. Note that on the figure \ref fig_UML_light as well as on figure -\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 field) will have no effect on the mesh (resp. support) which refers to it. But the user has to maintain the link: a mesh aggregates a support which aggregates 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. +\ref fig_UML the life cycle of mesh and field objects are independent. Destroying a field will have no effect on the mesh. But the user has to maintain the link: a mesh aggregates a support which aggregates 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 : diff --git a/doc/doxygen/mesh.dox b/doc/doxygen/mesh.dox index 9a82793da..93a51d30f 100644 --- a/doc/doxygen/mesh.dox +++ b/doc/doxygen/mesh.dox @@ -3,7 +3,8 @@ \section mesh_general General information -The MESH class is dedicated to the handling of unstructured meshes. Two classes derive from it : MESHING supplies functions for creating meshes from scratch (c.f. \ref meshing), while GRID gives specific constructors for creating structured meshes. +The MESH class is dedicated to the handling of unstructured +meshes. Class MESHING deriving from it supplies functions for creating meshes from scratch (c.f. \ref meshing). \section mesh_connectivity Content of the connectivity array Underlying the unstructured meshes is the notion of connectivity. This section only covers meshes made out of standard elements, the \c MED_POLYGON and \c MED_POLYHEDRA case being detailed in section \ref polygon . @@ -12,12 +13,13 @@ Underlying the unstructured meshes is the notion of connectivity. This section o \image html connectivity_arrays_small.png "Nodal connectivity storage scheme" \image latex connectivity_arrays_small.eps "Nodal connectivity storage scheme" -In MEDMEM, an unstructured mesh nodal connectivity is defined with these arrays (if the mesh has no MED_POLYGON and MED_POLYHEDRA element) : -- the type array, which contains the number of cells for each present type -- the nodal connectivity array containing the connectivity of each cell, all cells being sorted by type, -- the connectivity index array, which indicates the beginning of each cell in the connectivity array, +In MEDMEM, an unstructured mesh nodal connectivity is defined with these arrays: +- the type array, which contains the number of cells for each present type; +- the nodal connectivity array containing the connectivity of each cell, all cells being sorted by type; +- the connectivity index array, which indicates the beginning of each cell in the connectivity array. -The cell types are ordered by their number of nodes. +The cell types are ordered by their number of nodes; MED_POLYGON and +MED_POLYHEDRA is always the last type, if present. As an example, let us consider a mesh made out of a linear triangle, two linear quadrangles and a quadratic triangle (c.f. figure \ref fig_connectivity_example ). \image html connectivity_example_small.png "Example for mesh connectivity" @@ -56,6 +58,7 @@ The description of MESH methods is given by the following sections : - Connectivity information methods are described in \ref MESH_connectivity. - The methods retrieving family information are given in \ref MESH_families. - The IO methods are given in \ref MESH_io. -- The methods for an advanced usage (applying algorithms to meshes) are given in \ref MESH_advanced. +- The methods for an advanced usage (applying algorithms to meshes) +are given in \ref MESH_advanced. */ diff --git a/doc/doxygen/meshing.dox b/doc/doxygen/meshing.dox index de2565a2c..0b97eb4db 100644 --- a/doc/doxygen/meshing.dox +++ b/doc/doxygen/meshing.dox @@ -12,7 +12,7 @@ dimensions are wrong, results are impredictable. All the arrays passed as arguments in the set methods are duplicated in MESHING object. The creation of a mesh should respect the following sequence : -- setting general information (name, description, dimensions, coordinate system, ...), +- setting general information (name, description, coordinate system, ...), - setting the nodes (number and coordinates), - setting the connectivity (types, connectivity arrays,...), - group creations. @@ -37,4 +37,4 @@ An example of mesh creation via MESHING is given in : - Python: \include MESHINGexample.py -*/ \ No newline at end of file +*/ diff --git a/doc/doxygen/polygon.dox b/doc/doxygen/polygon.dox index 75054cd7a..45d4cb5a7 100644 --- a/doc/doxygen/polygon.dox +++ b/doc/doxygen/polygon.dox @@ -4,12 +4,12 @@ The methods described in section \ref mesh do not take into account information about \c polygonal and \c polyhedral cells contained in a MESH object. -Indeed, in the MEDMEM library, the connectivity data -for these elements are stored separately . Therefore, -the methods that give access to this data are slightly different from -those of section \ref mesh. +Indeed, in the MEDMEM library, the connectivity data for these +elements are stored the same way as connectivity of standard +elements. Therefore, the methods that give access to this data are +same as those of section \ref mesh. -Also, the polygon and the polyhedra case differ in nature, +The polygon and the polyhedra case differ in nature, because in 3D, the list of nodes is not sufficient to described the shape of an element. A descending cell>face>nodes connectivity has to be established @@ -24,18 +24,16 @@ Let us consider the case illustrated in figure \ref fig_polygon_connectivity . \image latex polygon_connectivity_small.eps "Example for polygon connectivity" -- The standard element connectivity table writes : {2, 6, 7, 3, 3, 7, 8, 4 } -- The standard element connectivity index table writes : {1, 5, 9 } -- The polygon element connectivity table writes : {1, 2, 3, 4, 5 } -- The polygon element connectivity index table writes : {1, 6 } +- The connectivity table writes : {2, 6, 7, 3, 3, 7, 8, 4, 1, 2, 3, 4, 5 } +- The connectivity index table writes : {1, 5, 9, 14 } \section polyhedron_conn Polyhedron connectivity For polyhedra, in the nodal connectivity case, -one more array is required, because a -list of nodes does not suffice to describe a general polyhedron. -A general polyhedron is therefore described by a list of faces, -each of those being described by a list of nodes. +list of nodes does not suffice to describe a general polyhedron; +information of connectivity of each face is needed. +A general polyhedron is therefore described by a list of nodes of +all faces with -1 as separator between faces. Let us consider an example with the two tetrahedra represented on figure \ref fig_polyhedron_connectivity , the left one @@ -46,27 +44,15 @@ as a \c MED_POLYHEDRA element. \image html polyhedron_connectivity_small.png "Example for polyhedron connectivity. Node numbers are written with a normal font, while face numbers are written in italic font." \image latex polyhedron_connectivity_small.eps "Example for polyhedron connectivity. Node numbers are written with a normal font, while face numbers are written in italic font." -- The standard element index connectivity table writes : {1, 5 } -- The standard element connectivity table writes : {1, 2, 3, 4 } -- The polyhedra connectivity index table writes :{1, 5} -- The polyhedra connectivity face index table writes : {1, 4, 7, 10, 13} -- The polyhedra connectivity (face/node connectivity) table writes : {2, 3, 5, 2, 4, 5, 4, 5, 3, 2, 3, 4} - -Note that as they are not needed as such, the face numberings are not stored -in any array. Only the number of nodes per face is implicitly stored -in the polyhedra face connectivity index table. +- The connectivity table writes : {1, 2, 3, 4, 2, 5, 3, -1, 2, 4, 5, -1, 4, 3, 5, -1, 2, 3, 4} +- The index connectivity table writes : {1, 5, 20 } If there are two \c MED_POLYHEDRA elements that share a common face, the list of nodes is repeated twice in the polyhedron connectivity -array. - -\section poly_outline Outline -The methods associated to polygons/polyhedra are located in the following classes : -- access methods are stored in MESH : \ref MESH_poly -- creation methods are in MESHING : \ref MESHING_poly +array but with reversed order. \section poly_example Example The following example illustrates the creation method for a mesh that contains polygons and/or polyhedra : \include test_MEDMEM_MeshingPoly.cxx -*/ \ No newline at end of file +*/