Problems Reading Files
Problems reading files
The files are read but seem to be corrupt on initialisation
If the node and element numbering is reported as being scrambled it is likely that the analysis job crashed on initialisation or, if the job is still running, it may not yet have initialised. Check to see if it crashed (see the .LOG file). If it is still running try reading it again later when it has got a bit further (this is because the node and element arbitrary numbering tables are the last items to be written at job initialisation).
Alternatively the automatic file format detection may have mis-diagnosed the file's data format. Check that the FILE_TYPE_32 or _64 environment variables are set correctly ( Disk format of binary database files ). This is particularly the case when reading older 64 bit files.
D3PLOT crashes when reading in a file
This generally means that the .PTF file is corrupt. For a job that is still running wait for it to be initialised, for a job that has finished this means that it crashed during initialisation leaving an incomplete file. The D3PLOT crash is due to trying to work out coordinate limits from nonsensical values.
The crash can also be caused by trying to read 64 bit files in IEEE rather than Cray format, or vice-versa. See Disk format of binary database files
The last state(s) in the file seem to have nonsensical times and/or corrupt results
This usually means that a complete state has been only partially written. If the analysis job is still running it usually means that the computer system buffers are still holding data waiting to be written to disk. Wait to see what happens when the next state is written as this will probably sort out its predecessor. You can force a dump of a plot state by using the STATUS command in the command shell.
If the job has finished then it probably crashed or ran out of disk space. Check the messag or .otf files for error messages, check the .log file for evidence of crashes or disk space exhaustion.
D3PLOT reports that the .XTF or .CTF files are incompatible with the .PTF file
This means that the control parameters in the various files suggest that they have come from different analyses. The most common cause of this is that files from an old analysis of the same name have not been deleted when the new one is run: check the creation dates on the files.
D3PLOT will ignore the incompatible .ctf / .xtf file(s) and continue running.
D3PLOT issues warning that >1000 element meet at a node
This invariably means that the file is either corrupt (ie completed analysis job crashed on initialisation), or is still waiting to initialise (job still running). Take action as described for when D3PLOT crashes reading a file.
D3PLOT issues warning that solid or thick shell elements have crossed facesThis may not be an error: it is possible (but unusual) for this situation to arise legitimately. If this is the only message issued and D3PLOT initialises normally have a look at the offending elements and check their topology. If this is blatantly wrong it means that the file is corrupt. |
D3PLOT warns that 6-noded thick shells have mis-numbered faces
It is a common error to create triangular thick shells using the solid "wedge" numbering sequence (1,2,3,4,5,5,6,6) instead of the "extruded triangle" sequence (1,2,3,3,4,5,6,6). Ansys LS-DYNA will still run, but the results for these elements will be dodgy. D3PLOT will also run, but the face numbering for these elements will be wrong leading to mis-diagnosis of external faces, free edges and data averaging at nodes.
D3PLOT issues warning that duplicate solids or thick shells exist
Again this may indeed be the case. Check as described above, and take heed that coincident solids may not be displayed unless the , switch is turned on . (Since all their faces will be marked internal.)
Problems with missing .PTF file family members: last <n> states not read
If the final <n> states from your analysis are not read, and these appear to be in the last family member(s), check for gaps in family member numbering. If one or more family members appear to be missing check the reason. However you can skip gaps in the family member sequence using the , command: see The FILE > popup menu options .
D3PLOT fails to read some states from a file, with a regular pattern
This can occur if the family member size has been set to a value smaller than that used when writing the files, as states in the tail end of family members are not read.
In D3PLOT 8.0 onwards family member size detection should be automatic, but you can over-ride it using the , command, or by setting the FAM_SIZE environment variable as described in The FILE > popup menu options .
File protection problems
D3PLOT does not require "write" access to database files, so you can process results to which you only have "read-only" access.
However operations that create files: laser plotting, view storage and session file generation, all require "write" access to the relevant directories. If a file open fails due to protection errors you will be warned and the operation will be aborted.