Jump to general information, preprocessing, postprocessing, and manipulation codes, and libraries.
|
|
|
|---|---|
| Overview | The Sandia National Laboratories (SNL) Engineering Analysis Code Access System (SEACAS) is a collection of structural and thermal codes and utilities used by analysts at SNL. The system includes pre- and post-processing codes, analysis codes, database translation codes, support libraries, UNIX shell scripts, and an installation system. |
| Recent Changes | Documents changes to the SEACAS applications and libraries that may not yet be covered in the documentation. |
| Using SEACAS on Parallel Computers |
Out-of-date, but some information is still useful. Instructions to run the SEACAS/ACCESS system on Parallel computers. Currently specific to Sandia National Laboratories systems. |
|
|
|
| Algebra | The ALGEBRA program allows the user to manipulate data from a finite element analysis before it is plotted. The finite element output data is in the form of variable values (e.g., stress, strain, and velocity components) in an EXODUS database. The ALGEBRA program evaluates user-supplied functions of the data and writes the results to an output EXODUS database which can be read by plot programs. |
| Aprepro | Aprepro is an algebraic preprocessor that reads a file containing both general text and algebraic, string, or conditional expressions. It interprets the expressions and outputs them to the output file along with the general text. Aprepro contains several mathematical functions, string functions, and flow control constructs. In addition, functions are included that, with some additional files, implement a units conversion system and a material database lookup system. |
| Blot | BLOT is a graphics program for post-processing of finite element analyses output in the EXODUS database format. BLOT produces mesh plots with various representations of the analysis output variables. The major mesh plot capabilities are deformed mesh plots, line contours, filled (painted) contours, vector plots of two/three variables (e.g., velocity vectors), and symbol plots of scalar variables (e.g., discrete cracks). Pathlines of analysis variables can also be drawn on the mesh. BLOT's features include element selection by material, element birth and death, multiple views for combining several displays on each plot, symmetry mirroring, and node and element numbering. BLOT can also produce X-Y curve plots of the analysis variables. BLOT generates time-versus-variable plots or variable-versus-variable plots. It also generates distance-versus-variable plots at selected time steps where the distance is the accumulated distance between pairs of nodes or element centers. |
| conjoin | Conjoin joins two or more Exodus databases into a single
database. The input databases should represent the same
model geometry with similar variables. The output database
will contain the model geometry and all of the
non-temporally-overlapping results data. If two databases
have overlapping timestep ranges, the timesteps from the
later database will be used. For example, if the first
database contains time data from 0 to 5 seconds, and the
second database contains time data from 4 to 10 seconds; the
output database will contain time data from 0 to 4 seconds
from the first database and time data from 4 to 10 seconds
from the second database. If two nodes have the same global
id and are also colocated, then they are combined to a
single node in the output. Similarly, elements with the same
global id and the same nodal connectivity are combined into
a single element in the output file. The output database will contain the union of the meta and bulk data entities (i.e., nodes, elements, element blocks, sidesets, and nodesets) from each input database. The existence of an entity at a particular timestep is indicated via a status variable. Replaces conex |
| ejoin | EJoin is used to join two or more Exodus databases into
a single Exodus database. The input databases must have
disjoint meta and bulk data. That is:
|
| epu | Combines multiple Exodus databases produced by a
parallel application into a single Exodus database. Replaces
nem_join. One of the typical processes for performing parallel analyses with Exodus databases is to decompose the finite element model into multiple pieces such that each processor can read and write its own portion of the finite element model and results data. For example, if a parallel analysis is to be run on the mesh file mesh.g using 8 processors, then mesh.g will be decomposed into 8 pieces or submeshes: mesh.g.8.0, mesh.g.8.1, . . ., mesh.g.8.7. Each submesh will contain a subset of the nodes and elements of the entire mesh and some communication data indicating which nodes and elements are on the boundary of this submesh and the submesh of one or more other processors. The analysis code is then executed in parallel and each processor reads its portion of the mesh from its respective submesh; when it outputs results and/or restart data, it creates a new file containing its portion of the submesh and the results that are calculated on that submesh. An "N" processor run will create "N" separate files for each results and/or restart "dataset" that it creates. The analyst may want to visualize or postprocess the data in the submeshes as a single mesh, so each submesh needs to be joined together to create a single "global" file containing all of the data.1 This joining together of parallel submeshes is the purpose of EPU. It will read the data from each submesh and map it into the correct location in the "global" file; discarding duplicate data as required. |
| Exo2Mat | See mat2exo documentation. |
| exodiff | Exodiff compares the results data from two Exodus databases. The databases should represent the same model, that is, the Exodus meta data should be identical as should be the genesis portion of the bulk data. The only differences should be in the values of the transient bulk data. Exodiffs main purpose is to detect and report these differences. Exodiff will compare global, nodal, element, nodeset, and sideset transient variables at each selected timestep; it will also compare element attribute variables on each element block containing attributes. |
| exomatlab | Outputs selected global data to a text matlab file. |
| exotxt | Convert an exodus file into a text file which can be edited or used as input to other processing codes that need a text format. Can be converted back to exodus using txtexo. (The netcdf utilities ncdump/ncgen can also be used to convert an exodus files to/from text.) |
| Fastq | The FASTQ code is an interactive two-dimensional finite element mesh generation program, It is designed to provide a powerful and efficient tool to both reduce the time required of an analyst to generate a mesh, and to improve the capacity to generate good meshes in arbitrary geometries. It is based on a mapping technique and employs a set of "higher-order" primitives which have been developed for automatic meshing of commonly encountered shapes (i.e. the triangle, semi-circle, etc.) and conditions (i.e. mesh transitioning from coarse to fine mesh size. ) FASTQ has been designed to allow user flexibility and control. The user interface is built on a layered . command level structure. Multiple utilities rue provided for input, manipulation, and display of the geometric information, as well as for direct control, adjustment, and display of the generated mesh. Enhanced boundary flagging has been incorporated and multiple element types and output formats are supported. Memos documenting features (such as paving) not discussed in the sand report are available here |
| Gen3D | GEN3D is a three-dimensional mesh generation program. The three-dimensional mesh is generated by mapping a two-dimensional mesh into three-dimensions according to one of four types of transformations: translating, rotating, mapping onto a spherical surface, and mapping onto a cylindrical surface. The generated three-dimensional mesh can then be reoriented by offsetting, reflecting about an axis, and revolving about an axis. GEN3D can be used to mesh geometries that are axisymmetric or planar, but, due to three-dimensional loading or boundary conditions, require a three-dimensional finite element mesh and analysis. More importantly, it can be used to mesh complex three-dimensional geometries composed of several sections when the sections can be defined in terms of transformations of two-dimensional geometries. Additional commands not documented in the main report are available here |
| GenShell | GENSHELL is a three-dimensional shell mesh generation program. The three-dimensional shell mesh is generated by mapping a two-dimensional quadrilateral mesh into three dimensions according to one of several types of transformations: translation, mapping onto a spherical, ellipsoidal, or cylindrical surface, and mapping onto a user-defined spline surface. The generated three-dimensional mesh can then be reoriented by offsetting, reflecting about an axis, revolving about an axis, and scaling the coordinates. GENSHELL can be used to mesh complex three-dimensional geometries composed of several sections when the sections can be defined in terms of transformations of two-dimensional geometries. |
| GJoin | GJOIN is a two- or three-dimensional mesh combination program. GJOIN combines two or more meshes written in the GENESIS mesh database format into a single GENESIS mesh. Selected nodes in the two meshes that are closer than a specified distance can be combined The geometry of the mesh databases can be modified by scaling, offsetting, revolving, and mirroring. The combined meshes can be further modified by deleting, renaming, or combining material blocks, sideset identifications, or nodeset identifications. |
| Grepos | GREPOS is a mesh utility program that repositions or modifies the configuration of a two-dimensional or three-dimensional mesh. GREPOS can be used to change the orientation and size of a two-dimensional or three-dimensional mesh; change the material block, nodeset, and sideset IDs; or "explode" the mesh to facilitate viewing of the various parts of the model. |
| Grope | GROPE is a program that examines the input to a finite element analysis or the output from an analysis in the EXODUS database format. GROPE allows the user to examine any value in the database. The display can be directed to the user's terminal or to a print file. |
| Mapvar | MAPVAR is designed to transfer solution results from one finite element mesh to another. MAPVAR draws heavily from the structure and coding of MERLIN II, but it employs a new finite element data base, EXODUS II [3], and offers enhanced speed and new capabilities not available in MERLIN II. In keeping with the MERLIN II documentation, the computational algorithms used in MAPVAR are described. User instructions are presented. Example problems are included to demonstrate the operation of the code and the effects of various input options. |
| Mapvar-kd | mapvar-kd is almost exactly the same as mapvar except that it uses a KD algorithm for the internal search. It is much faster than mapvar in certain situations, and should never be slower. |
| Mat2Exo | MAT2EXO is a program which translates mesh data from Matlab mat-file format to Exodus II format. This tool is the inverse of the commonly used tool exo2mat which translates Exodus II data to the Matlab mat-file format. These tools provide a means for preprocessing an Exodus II model file or post-processing an Exodus II results file using Matlab. |
| nem_join | Deprecated. Use epu instead. |
| nem_slice | nem_slice reads in a FEM description of the geometry of a problem from an ExodusII file and generates either a nodal or elemental graph of the problem, calls Chaco to load balance the graph, and outputs a NemesisI load-balance file which can be read by |
| nem_spread | nem_spread reads it's input command file (default name nem_spread.inp), takes the named ExodusII and spreads out the geometry (and optionally results) contained in that file out to a parallel disk system. The decomposition is taken from a scalar Nemesis load balance file generated by the companion utility nem_slice. Here is an example nem_spread input file. |
| Numbers | NUMBERS is a program which reads and stores data from a finite element model described in the EXODUS database format. Within this program are several utility routines which calculate information about the finite element model. It is limited to models with hexahedral elements only. |
| txtexo | Convert a text file written by exotxt back to an exodus file. (The netcdf utilities ncdump/ncgen can also be used to convert an exodus files to/from text.) |
|
|
|
| ExodusII Doxygen API Documentation Original Doc (not current) |
EXODUS II is a model developed to store and retrieve
data for finite element analyses. It is used for
preprocessing (problem definition), postprocessing (results
visualization), as well as code to code data transfer. An
EXODUS II data file is a random access, machine independent,
binary file that is written and read via C, C++, or Fortran
library routines which comprise the Application Programming
Interface. (exodusII is based on netcdf) Draft documentation of the "new" API is found here. The new version includes support for names, nodeset variables, sideset variables, named attributes, coordinate frames, concatenated element block definition, optional multiple named node and element maps, and other cleanups. Documentation of the modifications needed to use the "large-file" modifications which permit storage of models with more than ~30 million elements is found here. In addition to the above API extensions, the API has also been modified to store the full model topology nodes->edges->faces->elements including blocks and sets of all entities. The API extensions are documented in Chapter 4 of SAND2007-0525, A data storage model for novel partial differential equation discretizations. The API was modified in 2012 to permit the storage of more than 2.1 Billion nodes and/or elements. The changes are documented in 64-bit integers The API now supports names longer (or shorter) than 32 characters. The names include variable names and entity names. The changes are documented in Long Names Polyhedral elements can be stored in exodus. The documentation for this is in Polyhedral Element Storage All nemesis functions have been added to the exodus api. In most cases, the name of the exodus function is the same as the original nemesis function except that the leading ne_ has been replaced with ex_. There are a few exceptions. See Nemesis-To-Exodus-API-Mapping for a complete list of functions.
|
| Exodus Python Interface | A python interface to the EXODUS II library. |
| Chaco | Graph partitioning is a fundamental problem in many
scientific contexts This document describes the capabilities
and operation of Chaco 2.0, a software package designed to
partition graphs. Chaco 2.0 allows for recursive application
of several methods for finding small edge separators in
weighted graphs These methods include inertial, spectral,
Kernighan-Lin, and multilevel methods in addition to several
simpler strategies Each of these approaches can be used to
partition the graph into two, four, or eight pieces at each
level of recursion In addition, the Kernighan-Lin method can
be used to improve partitions generated by any of the other
algorithms. Brief descriptions of these methods are provided
along with references to relevant literature. Chaco 2.0 can
also be used to address various graph sequencing problems,
and this capability is briefly described. The user interface
input/output formats and appropriate settings for a variety
of code parameters are discussed in detail and some
suggestions on algorithm selection are offered. NOTE: The short *assignment argument to the interface function has been changed to int *assignment to permit decompositions with more than 32,768 processors. There are also now a CHACO_VERSION_MAJOR, CHACO_VERSION_MINOR, CHACO_VERSION_PATCH defines in chaco.h. |
| Netcdf | The NetCDF software functions as an I/O library,
callable from C or FORTRAN, which stores and retrieves data
in self-describing, machine-independent files. Each NetCDF
file can contain an unlimited number of multi-dimensional,
named variables (with differing types that include integers,
reals, characters, bytes, etc.), and each variable may be
accompanied by ancillary data, such as units of measure or
descriptive text. The interface includes a method for
appending data to existing NetCDF files in prescribed ways,
functionality that is not unlike a (fixed length) record
structure. However, the NetCDF library also allows
direct-access storage and retrieval of data by variable name
and index and therefore is useful only for disk-resident (or
memory-resident) files. Netcdf information is available from Unidata. Man pages for the ncgen and ncdump utilities are also available. (These can be used to convert an exodusII file from/to a text representation.) |
| Nemesis | NEMESIS I is an enhancement to the EXODUS II finite
element database model used to store and retrieve data for
unstructured parallel finite element analyses. NEMESIS I
adds data structures which facilitate the partitioning of a
scalar (standard serial) EXODUS II file onto parallel disk
systems found on many parallel computers. Since the NEMESIS
I application programming interface (API) can be used to
append information to an existing EXODUS II database, any
existing software that reads EXODUS II files can be used on
files which contain NEMESIS I information. The NEMESIS I
information is written and read via C or C++ callable
functions which compromise the NEMESIS I API. Fortran to C Function Mapping All nemesis functions have been added to the exodus api. In most cases, the name of the exodus function is the same as the original nemesis function except that the leading ne_ has been replaced with ex_. There are a few exceptions. See Nemesis-To-Exodus-API-Mapping for a complete list of functions.
|
| IO System (IOSS) | The documentation below is a medium- to low-level view of the IO system (IOSS) targeted at developers who will be adding or modifying the database IO portion of the system. It should give enough detail that a new database type could be added by reading this document and looking at an existing database class. It is also helpful to have the doxygen-generated documentation for the Ioss class hierarchy available. The IO Subsystem has been designed to support multiple database formats simultaneously. It is possible to have the finite element model read from an ExodusII database; two results files being written to an ExodusII file with a third results file being written to an XDMF file; and the restart file being written to yet another ExodusII file. Each of these output databases can have a different schedule for when to write and what data is to be written. The document Ioss-exodus-mapping.pdf describes how an Exodus model is mapped into the IOSS representation. |
| SUPES | SUPES is a collection of subprograms which perform frequently used non-numerical services for the engineering applications programmer using FORTRAN-77. The three functional categories of SUPES are: (1) input command parsing, (2) dynamic memory management, and (3) system dependent utilities. The subprograms in categories one and two are written in standard FORTRAN-77, while the subprograms in category three are written to provide a standardized FORTRAN interface to several system dependent features. |


This assessment request costs
#{cc.attrs.bean.userAssessmentTokenData.numberOfTokensSpentPerRequest}
Assessment #{cc.attrs.bean.userAssessmentTokenData.numberOfTokensSpentPerRequest eq 1 ? 'Token' : 'Tokens'}.
You don't have enough Assessment Tokens to send the assessment request
.
to
.
for more info.
You need to select the assessor. Please use the search box or the Assign me assessor button to find one.
There are no available assessors at the moment. You can still submit an unassigned assessment request that will be assigned to the first available assessor when one appears.
By submitting this request you will still spend #{cc.attrs.bean.userAssessmentTokenData.numberOfTokensSpentPerRequest} #{cc.attrs.bean.userAssessmentTokenData.numberOfTokensSpentPerRequest eq 1 ? 'token' : 'tokens'}.
You cannot submit the assessment request. There are no available assessors at the moment, and you have already submitted an unassigned assessment request that will be assigned to the first available assessor when one appears. After this request is assigned to an assessor, you can make a new assessment request.
You cannot send a notification to the assessor since the assessment has already been submitted.
All peer assessments are blinded (peer assessor identity is hidden to you).
Are you sure you want to notify your #{msg['label.instructor'].toLowerCase()} to assess your #{msg['label.'.concat(cc.attrs.resource.toLowerCase())].toLowerCase()}?
You have already sent an assessment request to
and the request is pending. Clicking the Submit button will send a notification to
that you want the assessment to be completed.
You don't have a #{msg['label.instructor'].toLowerCase()} assigned yet.
Go to the
and choose your #{msg['label.instructor'].toLowerCase()}.
Make sure you have added an appropriate summary of your evidence on the
that will be visible to the assessor during the assessment.
Make sure you have added an appropriate summary of your evidence for all #{msg['label.competence.plural'].toLowerCase()} that will be visible to the assessor during the assessment.


Write a script that selects all the div nodes that are directly inside other div elements
- Create a function using querySelectorAll()
- Create a function using getElementsByTagName()
Write a script that selects all the div nodes that are directly inside other div elements
Some text
Some text
Some text