Supported File Formats

Scope has built-in support for many file formats.

Mesh Data

Mesh files in the following formats can be imported into scope:

  • Native .zml files (see below)
  • CGNS version 2.53 based on ADF (not HDF)
  • SU2 mesh files (.su2)
  • NASTRAN bulk data files (most, but not all, element types)
  • TAU mesh files (tetrahedral and hybrid, .taumesh)
  • Legacy VTK format files (.vtk)
  • TetGen meshes (.node/.element/.faces)
  • EDGE mesh files (.bmesh)
  • STL mesh files, both binary and plain text format
  • Limited support for Abaqus input files (.inp)

Computational Results

Mesh files in the following formats can be imported into scope:

  • Native .zml files (see below)
  • CGNS version 2.53 based on ADF (not HDF)
  • SU2 mesh files (.su2)
  • NASTRAN punch files (.pch)
  • Legacy VTK format files (.vtk)
  • EDGE fluid data and boundary deformation data (.bout, .bdis)
  • AEREL results from AERELPLOT format files
  • Data can be written to the Ensight Gold file format which is most convenient for importing data into Paraview.

Mass import

There are many situations where a certain mesh file is used for a large number of simulations (or ‘subcases’). Some simulation software directly supports writing a single output file containing these many subcases, while others (such as EDGE or SU2) write one output file for each case. With scope, it is possible to load arbitrarily many such result files, optionally reduce file size by eliminating volume elements, and store the merged mesh and results in a single native file.

In order to import multiple result runs into a single native file, load first the corresponding mesh geometry, e.g. a .bmsh file. Once the mesh is available, scope will permit the selection multiple files in the file selection dialog opened by the Load function.

When an automated approach is preferred for use in scripting, the small command-line utility program mergefields can be called upon to join multiple solution files into a single one. An example command-line call used to merge multiple SU2 solution files (for different angles of attack) in VTK format would look as follows:

mergefields run1.vtk="Alpha=+1" run3.vtk="Alpha=+3" run5.vtk="Alpha=+5"

This call would generate a new file named merged.zml that contains three subcases with all fields from the three separate solution files. Such a merged file is especially useful when structural loads are to be generated for all of these solutions.

Finally, note that merged CFD files can become very large indeed. Loading and saving such files can be rather slow when accessing mapped network drives on Windows 7, XP, 2008, 2012. This is an inherent limitation of the operating system functions which needs to be resolved by system administration.

Native Format

Scope also supports a fairly efficient native binary file format, for which the extension .zml is used. Binary files are compressed (currently using LZ4 or zlib, but that may change) and can be converted to a human-readable and editable plain text XML format, either from within scope (Menu File, option Export, select Plain XML) or using the command-line utility zml2xml. Another command-line utility named zmlprint can be used to inspect the data structure of a native format file. Typical output of this utility looks like this:

Recognized GBF file format; summary: 
Node: MxMesh
Block: 0
2 attributes: 
[0] gbf_format_generator = XmlElement
[1] gbf_format_payload_type = Empty
  Node: MxNote
  Block: 0
  2 attributes: 
  [0] gbf_format_generator = XmlElement
  [1] gbf_format_payload_type = Empty
    Node: NastranGID
    Block: 62872
    5 attributes: 
    [0] gbf_format_generator = XmlElement
    [1] bdata_bytes = 62872
    [2] bdata_type = Int32
    [3] count = 15718
    [4] gbf_format_payload_type = Int32
    End of Node: [NastranGID]
  End of Node: [MxNote]
  Node: MxSolutionTree
  Block: 0
  4 attributes: 
  [0] gbf_format_generator = XmlElement
  [1] children = 2
  [2] name = Results
  [3] gbf_format_payload_type = Empty
    Node: MxNote
    Block: 0
    2 attributes: 
    [0] gbf_format_generator = XmlElement
    [1] gbf_format_payload_type = Empty
    End of Node: [MxNote]
    Node: MxSolutionTree
    Block: 0
    4 attributes: 
    [0] gbf_format_generator = XmlElement
    [1] children = 0
    [2] name = Displacements
    [3] gbf_format_payload_type = Empty
      Node: MxNote
      Block: 0
      2 attributes: 
      [0] gbf_format_generator = XmlElement
      [1] gbf_format_payload_type = Empty
      End of Node: [MxNote]
      Node: Fields
      Block: 256
      5 attributes: 
      [0] gbf_format_generator = XmlElement
      [1] bdata_bytes = 256
      [2] bdata_type = Int32
      [3] count = 64
      [4] gbf_format_payload_type = Int32
      End of Node: [Fields]
    End of Node: [MxSolutionTree]
[...]
 Node: MxMeshField
  Block: 754464
  9 attributes: 
  [0] gbf_format_generator = XmlElement
  [1] bdata_bytes = 754464
  [2] bdata_type = Float64
  [3] class = displacement
  [4] dimension = 6
  [5] name = Displacement 11
  [6] nodal_field = true
  [7] solution_index = 0
  [8] gbf_format_payload_type = Float64
    Node: MxNote
    Block: 0
    2 attributes: 
    [0] gbf_format_generator = XmlElement
    [1] gbf_format_payload_type = Empty
    End of Node: [MxNote]
  End of Node: [MxMeshField]
  Node: MxMeshField
  Block: 754464
  9 attributes: 
  [0] gbf_format_generator = XmlElement
  [1] bdata_bytes = 754464
  [2] bdata_type = Float64
  [3] class = displacement
  [4] dimension = 6
  [5] name = Displacement 12
  [6] nodal_field = true
  [7] solution_index = 0
  [8] gbf_format_payload_type = Float64
    Node: MxNote
    Block: 0
    2 attributes: 
    [0] gbf_format_generator = XmlElement
    [1] gbf_format_payload_type = Empty
    End of Node: [MxNote]
  End of Node: [MxMeshField]
[...]