Download sort.notice

Back to the list

Display this manual page in
$$$$ SORT     NOTICE  JC220346  13/12/16    21:16:08     7884           
                                             DATE     13/12/16

    Directive SORTIR                         Voir aussi : LIRE
    ----------------                                      REST  SAUV   



    SORT (|'AVS' |) [object(s)] [options]
          |'EXCE'|
          |'ABAQ'|
          |'MED' |
          |'VTK' |
          |'MAT' |



    Description :
    _____________

    Writes GIBI objects to disk in a file previouly defined by the
    following instruction :

    OPTI 'SORT' FICNAM ;

    The file extension does not need to be appended to FICNAM.


    Remark : One can also use OPTI 'SORT' N1 ; where N1 is the logical
             unit number (N1 = 7 by default). The output file will be
             named fort.N1 . However, this is NOT recommended.



    +------------------------+
    | Standard output        |
    +------------------------+

    SORT MAIL1 ('NOOP') ;
    __________

    Without keyword, the SORTir instruction prints the geometry
    contained in the MAIL1 object (MAILLAGE type). All the sub-objects
    inside MAIL1 will be output as well.

    The mesh can be loaded back into memory with the LIRE instruction.

    The numbering of the output mesh nodes is optimized for solvers
    based on the CROUT method. If the optimization is not required,
    enter the keyword 'NOOP'.

    Remark : This instruction exists for the compatibility with CASTEM
             older versions and it is not likely to be improved. The
             output level is thus restrained at 2.

             In the event of an exclusive use with CASTEM, it is
             advisable to use SAUVer (and RESTituer) instead.



    +------------------------+
    | AVS output             |
    +------------------------+

    SORT 'AVS' (MAIL1) (CHPO1) (CHML1) ('SUIT') ('TEMP' FLOT1) ;
    __________

    When the 'AVS' keyword is provided, the SORTir instruction writes
    MAIL1 (MAILLAGE type), CHPO1 (CHPOINT type) and CHML1 (MCHAML type)
    in AVS UCD ASCII format (.inp extension).

    The use of any of the three arguments is optional but at least one
    of them must be present.

    The geometry to be output is specified (in decreasing priority) by :
       - the mesh MAIL1
       - the support of the element field CHML1
       - the support of the nodal field CHPO1

    Only the nodes that belong to the geometry defined hereabove are
    output. The criterion for a node to belong to a mesh is its number
    and NOT its position.

    When both the mesh MAIL1 and the element field CHML1 are specified,
    we check whether MAIL1 is entirely contained in the support of
    CHML1. If this is not the case, an error message is generated.

    When a nodal field CHPO1 is given and the geometry is specified (by
    MAIL1 or by CHML1) we check whether the intersection of the field
    support and that geometry is not empty. If it is empty, the nodal
    field CHPO1 is not output. When the nodal field support does not
    cover entirely the geometry, the field CHPO1 is extended to the
    whole geometry with zero values.

    The element field CHML1 must contain only one value (of every
    component) per element. This limitation is due to AVS. Thus it is
    usually necessary to transform the support nodes into the centers
    of gravity of the elements (refer to the CHANger operator).

    The 'SUIT' keyword may be used to append the data to the existing
    file rather than create a new one. In that only case, you must not
    use OPTI "SORT" before calling SORT "AVS". The file might then not
    be available for external applications until you close it (by using
    OPTI "SORT" again or by exiting CASTEM).

    The 'TEMP' keyword followed by a real number causes a global field
    variable named 'time' to be included in the AVS file.



    +------------------------+
    | EXCEL (TM) output      |
    +------------------------+

    SORT 'EXCE' OBJ1 (... OBJn) ('NCOL' ENTI1) ('SEPA' |'PVIR'|)
                                                       |'VIRG'|
                                                       |'ESPA'|
                                                       |'TABU'|
                                                       |'OBLI'|

    with OBJi = [ LENTIi | LREELi | LMOTSi | EVOLi | TABi ]
    __________

    When the 'EXCE' keyword is provided, the SORTir instruction writes
    tabular data in a .csv file (Comma-Separated Values), which can be
    imported into programs like Microsoft EXCEL or MATLAB for example.

    It is possible to export lists of integer or real numbers as well
    as lists of 4-character words. These lists may be contained in
    objects of the LISTENTI, LISTREEL, LISTMOTS, EVOLUTION or TABLE
    type.

    The columns titles (12 characters max.) can be specified in the
    case of EVOLUTION (X and Y axis titles) or TABLE (MOT-type indexes)
    objects.

    The length of the array to be output in the .csv file is determined
    as the length of the longest provided list.

    The 'NCOL' keyword allows to limit the .csv width to ENTI1 columns.
    If provided data exceeds this number, 3 blank lines are inserted
    between each successive sets of ENTI1 columns.

    The character which is used to separate adjacent columns can be
    chosen by specifying the 'SEPA' keyword, followed by the name of
    the separator :

          - 'PVIR' for a semicolon (;) => default value
          - 'VIRG' for a colon (,)
          - 'ESPA' for a space ( )
          - 'TABU' for a tabulation ([tab])
          - 'OBLI' for a backslash (/)



    +------------------------+
    | ABAQUS (TM) output     |
    +------------------------+

    SORT 'ABAQ' MAIL1 ;
    __________

    When the 'ABAQ' keyword is provided, the SORTir instruction writes
    the mesh MAIL1 (MAILLAGE type) according to the input file syntax
    for ABAQUS(TM) (.inp extension).

    Only meshes with massive finite element types can be saved in
    that ABAQUS(TM) format.



    +------------------------+
    | MED output             |
    +------------------------+

    SORT 'MED' GEO1 (OBJi) ;

    with OBJi = [ MAILi | CHPOi | TABi ]
    __________

    When the 'MED' keyword is provided, the SORTir instruction writes
    the mesh GEO1 and the Nth OBJi objects in MED format, which can be
    imported in SALOME or EUROPLEXUS for instance.

    Valid types for objects OBJi are MAILLAGE, CHPOINT and TABLE. The
    table must have a structure similar to the output table of the
    PASAPAS procedure, which is: an index of TIME, which contains time
    step, and an index of DEPLACEMENTS or TEMPERATURES, containing
    CHPOINT type objects for these time steps.

    /!\ The MED output might fail on some systems.



    +------------------------+
    | PARAVIEW output        |
    +------------------------+

    SORT 'VTK' OBJ1 (MOT1) ... (OBJn) (MOTn)
               (|'FORM'|) (|'AUTO'|) ('TEMP' FLOT1) ('DOUBLE_PRECISION')
                |'BINA'|   |'NOUV'|
                |'ZIP' |   |'SUIT'|
                           |'NPVD'|

    with OBJi = [ MAILi | CHPOi | CHMLi | TABi ]

    __________


    Objects and names
    -----------------

    When the 'VTK' keyword is provided, the SORTir instruction writes
    OBJi objects of MAILLAGE, CHPOINT and/or MCHAML types in VTK format,
    which can be imported in PARAVIEW for instance.

    The MOTi objects (MOT type) are optional names given to the OBJi
    objects. They are made of 4 characters max. for MAILLAGE objects
    ('0001', '0002', etc... by default), and 8 characters max. for
    CHPOINT or MCHAML objects (by default : OBJi name if it exists,
    'CHPO1', 'CHPO2', etc... otherwise).

    In the above syntax, OBJi can be a TABLE object, containing several
    MAILLAGE, CHPOINT and/or MCHAML sub-objects whose name is created
    from the table indexes (ENTIER, FLOTTANT or MOT converted into
    4 or 8-character strings). As a consequence, there is no need to
    provide MOTi when OBJi is a TABLE.

    At least one OBJi must be a MAILLAGE. If more than one MAILLAGE
    if given, each one is associated with a different .vtu file.


    Options
    -------

    a) OBJi objects can be written to formatted text files ('FORM'
       option) or to (partially) binary files ('BINA' option).
       The 'ZIP' option (compressed binary) is not implemented yet.

    b) The 'TEMP' keyword allows to indicate which instant of the
       simulation the data is output at, via FLOT1 (FLOTTANT type).
       Each timestep is written in a separate .vtu file.

    c) When several meshes are provided, or when several timesteps of
       the same simulation are written to disk, data is splitted into
       separate files named as indicated below :

                        FICNAM.xxxx.yyyy.vtu

         where : xxxx refers to the timestep index
                 yyyy is the name of the geometry partition MAIL1

       In both cases, it is strongly recommended to create a .pvd file
       which acts as a header for .vtu files coming from the same
       calculation. The following keywords control the .pvd creation :

         - 'AUTO' : attempt to complete a compatible .pvd, otherwise
                    create a new one (default behavior)
         - 'NOUV' : force creating a new .pvd file
         - 'SUIT' : force completing an already existing .pvd
         - 'NPVD' : do not create a .pvd file

       In order to complete an already existing .pvd file, it has to be
       "compatible" : the last recorded timestep must be anterior to the
       value of FLOT1, and its mesh partition must be identical to the
       one specified during current call (same number and names of
       MAILLAGE-typed OBJi).

    d) Greater precision can be obtained when the 'DOUBLE_PRECISION'
       keyword is specified :
       - in ASCII mode, the format is E24.15E3 instead of E14.6E2
       - in binary mode, real numbers are stored using 8 bytes rather
         than 4
       The 'time' attribute (.pvd file) format is also affected by
       this keyword.



    +------------------------+
    | MAT output             |
    +------------------------+

    SORT 'MAT' MOT1 MOT2 RIG1
        ('TITR' MOT3)
        ('INCO')
        ('GEOM')
        ('FORC' CHP1)
        ('CONN' CHP2)
        ('RESU' CHP3)
        ('SOLU' CHP4) ;

        
    MOT1 = | 'MM' or 'MATRIX_MARKET'
           | 'RB' or 'RUTHERFORD_BOEING'

    MOT2 = | 'ASSE' for 'ASSEMBLED'
           | 'ELEM' for 'ELEMENTARY'
           
    __________

    When the 'MAT' keyword is provided, the SORTir instruction writes
    the RIG1 object (RIGIDITE type) in a standardized exchange format
    for matrix data. These are ASCII files which can be parsed easily
    with scripts written in Matlab, fortran, python, etc...
    
    Two formats are available :
    
    MatrixMarket (.mm)
    ------------------
    This is a data representation which favors simplicity and
    readability : it can be parsed with the naked eye or with a script
    programmed in less than 3 minutes.  
    
    Rutherford-Boeing (.rb)
    -----------------------
    This format takes advantage of CSC (Compressed Sparse Column) to
    minimize the file size. However, the matrix cannot be read without
    a more sophisticated parser .
    
    
    In both cases, the object RIG1 can be written as stored internally
    in CAST3M (elementary form, keyword 'ELEM') or after assembly (the
    way it is done by calling RESO, keyword 'ASSE').
    
   
    A short description (128 characters maximum) of the problem can be
    written into the file header by selecting the 'TITR' keyword
    followed by the appropriate MOT3 object (MOT type).
    

    When the 'INCO' keyword is present, a supplementary file with
    extension .inco relates every primal (unknowns) and then dual
    (equations) degree of freedom to a node number (first column) and a
    component number (second column) :
    
    - Node numbers are specific to the matrix RIG1, and can be written
      to another supplementary file (.geom) by specifying the keyword
      'GEOM' (the i-th line in this file gives the coordinates of the
      node n°i in the matrix).
      
    - Component numbers are traced back to the names (4-letter words
      max.) thanks to lists written at the end of the .inco file.
      
      
    Keywords FORC, CONN, RESU and SOLU, which allow to output the
    right-hand side, the mesh connectivity, result fields or an
    analytical solution, in both format, are not available yet.
    
    
    REMARK 1 : The SORT instruction does not allow to export directly
               a submatrix of RIG1. To restrict the output to some
               given nodes or components, one must call REDU and/or
               EXTR prior to SORT.
    
    REMARK 2 : When RIG1 is output after assembly, the value specified
               for the 'NORM' option will influence the operation :
               
               - OPTI 'NORM' 'ANNU'
                 => writes a "raw" matrix, equivalent (mathematically
                    speaking) to the one obtained with MOT2='ELEM'
                    (this applies only for SORT, since RESO will
                     ALWAYS renormalize Lagrange multipliers during
                     assembly).
                    
               - OPTI 'NORM' 'AUTO'
                 => writes a matrix in which only Lagrange multipliers
                    are renormalized if present.
                    
               - OPTI 'NORM' LMOT1 LREE1 LMOT2 LREE2
                 => writes a matrix manually renormalized.
                 
    REMARK 3 : Please refer to the following sources if you need more
               information :
                 
               - The Matrix Market Exchange Formats: Initial Design,
                 Boisvert R. F., Pozo R., Remington K. A. (Dec 1996)
               - The Rutherford-Boeing Sparse Matrix Collection,
                 Duff I. S., Grimes R. G., Lewis G. L. (Sep 1997)

$$$$




 

© Cast3M 2003 - All rights reserved.
Disclaimer