Read LS-Dyna databases (d3plot) in parallel. More...
#include <vtkPLSDynaReader.h>
Public Types | |
| typedef vtkLSDynaReader | Superclass |
Public Member Functions | |
| virtual int | IsA (const char *type) |
| vtkPLSDynaReader * | NewInstance () const |
| virtual void | PrintSelf (ostream &os, vtkIndent indent) |
| virtual int | CanReadFile (const char *fname) |
| void | SetController (vtkMultiProcessController *c) |
| virtual vtkMultiProcessController * | GetController () |
Static Public Member Functions | |
| static int | IsTypeOf (const char *type) |
| static vtkPLSDynaReader * | SafeDownCast (vtkObjectBase *o) |
| static vtkPLSDynaReader * | New () |
Protected Member Functions | |
| virtual vtkObjectBase * | NewInstanceInternal () const |
| vtkPLSDynaReader () | |
| virtual | ~vtkPLSDynaReader () |
| virtual int | RequestInformation (vtkInformation *, vtkInformationVector **, vtkInformationVector *) |
| virtual int | RequestData (vtkInformation *, vtkInformationVector **, vtkInformationVector *) |
| virtual int | ReadTopology () |
Detailed Description
Read LS-Dyna databases (d3plot) in parallel.
This filter reads LS-Dyna databases in parallel.
The Set/GetFileName() routines are actually wrappers around the Set/GetDatabaseDirectory() members; the actual filename you choose is irrelevant -- only the directory name is used. This is done in order to accommodate ParaView.
- Attention:
- LSDyna files contain 3 different types of sections: control, data, and state. Control sections contain constants that describe the type of simulation data in a file or group of files. Data sections contain simulation information that is invariant across individual time steps (but can vary when a mesh adaptation occurs). This information includes material, connectivity, and undeformed geometry. Finally, state data is information that varies with each time step. Unless a mesh adaptation occurs, there will be a single control and data section, and they will be located at the start of the database (the first file).
- In their infinite wisdom, LSDyna developers decided to split simulation data into multiple files, each no larger than some predetermined limit. Each file can contain one section, a partial section (if it would not fit into a single file), or multiple sections. Files are padded with zeros so that their lengths will be multiples of 512*512. The size of each section is determined by constants in the control and data sections, which means that these must be parsed carefully in order to correctly locate desired information. Unfortunately, the constants are not terribly well-documented and in some cases the documentation is in error.
- Open Issues
- : The LS-Dyna file format document leaves a good bit open to interpretation. In addition to the "documentation vs. files in the wild" issues there are also implementation problems.
- Open Issues
- :
- Where exactly may breaks to a new file occur in the pre-state information? At each section?
- Will state data sections (node/cell data, element deletion, sph data, rigid body motion) be moved to the beginning of a new file if their data will be too large for a given file, or are all the sections counted together as a single state (makes more sense for keeping time word at start of every file). The questions above arise because the docs (p. 3) state "There are 3 sections in this database." but then call many smaller pieces of data "sections". Should they be subsections? The docs are quiet about whether the second section (of 3) is ever split across multiple files and, if so, whether it is done at (sub)section boundaries when possible or just wherever it needs to occur.
- How many components does Eddy Viscosity have? It's shown as 7 bits in NCFDV1 which makes no sense at all.
- Why is NARBS larger than 10+NUMNP+NEL8+NEL2+NEL4+NELT (which is the value specified by the documentation)? Obviously, NARBS is definitive, but what are the extra numbers at the end?
- Is there a difference between rigid body elements NUMRBE and rigid road surfaces? It appears that the nodes and connectivity of the road surface are given separately (p.13) while on p.7 the Material Type Data subsection says that shells in a rigid body will just have a certain material ID but be interspersed among deformable shell elements.
- Word 37 of the control section serves two possible purposes... it can mean NMSPH or EDLOPT. I assume that different versions of the code use that word differently. How do we know the difference?
- It's unclear how much state isn't stored when a shell element is marked as rigid. Specifically, is element deletion data stored for rigid shells? Page 21 of the spec is mute on this.
- The loop to read cell User IDs won't work if Rigid Body and Shell elements are interleaved (which I now believe they are).
- Open Issues
- : On the VTK side of things:
- The reader doesn't handle crack files (d3crck)
- The reader doesn't handle interface force files (no default name)
- The reader doesn't handle time history (abbreviated output) files (d3thdt)
- The reader doesn't handle dynamic relaxation files (d3drfl)
- The reader doesn't handle reduced parts (state for a subset of parts) files (d3part)
- The reader doesn't handle mode shape files (d3eigv)
- The reader doesn't handle equilibrium iteration files (d3iter)
- The reader doesn't handle extra time data files (d3xtf)
- The reader doesn't handle printer files (d3hsp)
- The reader doesn't handle modal neutral files (d3mnf)
- The reader doesn't handle packed connectivity.
- The reader doesn't handle adapted element parent lists (but the 2002 specification says LSDyna doesn't implement it).
- All the sample datasets have MATTYP = 0. Need something to test MATTYP = 1.
- I have no test datasets with rigid body and/or road surfaces, so the implementation is half-baked.
- It's unclear how some of the data should be presented. Although blindly tacking the numbers into a large chuck of cell data is better than nothing, some attributes (e.g., forces & moments) lend themselves to more elaborate presentation. Also, shell and thick shell elements have stresses that belong to a particular side of an element or have a finite thickness that could be rendered. Finally, beam elements have cross sections that could be rendered. Some of these operations require numerical processing of the results and so we shouldn't eliminate the ability to get at the raw simulation data. Perhaps a filter could be applied to "fancify" the geometry.
- Tests:
- vtkPLSDynaReader (Tests)
Definition at line 132 of file vtkPLSDynaReader.h.
Member Typedef Documentation
Reimplemented from vtkLSDynaReader.
Definition at line 135 of file vtkPLSDynaReader.h.
Constructor & Destructor Documentation
| vtkPLSDynaReader::vtkPLSDynaReader | ( | ) | [protected] |
| virtual vtkPLSDynaReader::~vtkPLSDynaReader | ( | ) | [protected, virtual] |
Member Function Documentation
| static int vtkPLSDynaReader::IsTypeOf | ( | const char * | name | ) | [static] |
Return 1 if this class type is the same type of (or a subclass of) the named class. Returns 0 otherwise. This method works in combination with vtkTypeMacro found in vtkSetGet.h.
Reimplemented from vtkLSDynaReader.
| virtual int vtkPLSDynaReader::IsA | ( | const char * | name | ) | [virtual] |
Return 1 if this class is the same type of (or a subclass of) the named class. Returns 0 otherwise. This method works in combination with vtkTypeMacro found in vtkSetGet.h.
Reimplemented from vtkLSDynaReader.
| static vtkPLSDynaReader* vtkPLSDynaReader::SafeDownCast | ( | vtkObjectBase * | o | ) | [static] |
Reimplemented from vtkLSDynaReader.
| virtual vtkObjectBase* vtkPLSDynaReader::NewInstanceInternal | ( | ) | const [protected, virtual] |
Reimplemented from vtkLSDynaReader.
| vtkPLSDynaReader* vtkPLSDynaReader::NewInstance | ( | ) | const |
Reimplemented from vtkLSDynaReader.
| virtual void vtkPLSDynaReader::PrintSelf | ( | ostream & | os, |
| vtkIndent | indent | ||
| ) | [virtual] |
Methods invoked by print to print information about the object including superclasses. Typically not called by the user (use Print() instead) but used in the hierarchical print process to combine the output of several classes.
Reimplemented from vtkLSDynaReader.
| static vtkPLSDynaReader* vtkPLSDynaReader::New | ( | ) | [static] |
Create an object with Debug turned off, modified time initialized to zero, and reference counting on.
Reimplemented from vtkLSDynaReader.
| virtual int vtkPLSDynaReader::CanReadFile | ( | const char * | fname | ) | [virtual] |
Determine if the file can be readed with this reader.
Reimplemented from vtkLSDynaReader.
Set/Get the communicator object. By default we use the world controller
| virtual vtkMultiProcessController* vtkPLSDynaReader::GetController | ( | ) | [virtual] |
Set/Get the communicator object. By default we use the world controller
| virtual int vtkPLSDynaReader::RequestInformation | ( | vtkInformation * | , |
| vtkInformationVector ** | , | ||
| vtkInformationVector * | |||
| ) | [protected, virtual] |
This is called by the superclass. This is the method you should override.
Reimplemented from vtkLSDynaReader.
| virtual int vtkPLSDynaReader::RequestData | ( | vtkInformation * | , |
| vtkInformationVector ** | , | ||
| vtkInformationVector * | |||
| ) | [protected, virtual] |
This is called by the superclass. This is the method you should override.
Reimplemented from vtkLSDynaReader.
| virtual int vtkPLSDynaReader::ReadTopology | ( | ) | [protected, virtual] |
These functions read various parts of the database. The functions that take a vtkIdType argument must be passed the current timestep. Functions that do not take a timestep must have the read head positioned to the start of their data sections. These functions should only be called from within RequestData() since they require the various output meshes to exist.
Reimplemented from vtkLSDynaReader.
The documentation for this class was generated from the following file:
- dox/IO/ParallelLSDyna/vtkPLSDynaReader.h
