Options: Controls Many Aspects of Reading Ansys LS-DYNA Files
Options: Controls Many Aspects of Reading Ansys LS-DYNA Files
The defaults for reading Ansys LS-DYNA files are chosen to give behaviour that should be appropriate for the vast majority of input decks, and in most cases you will not need to visit this panel. However problem decks that contain errors, or keywords that contain undocumented extra data fields, may become readable if the relevant options are used.
It is also possible to tune the hardware settings used for file reading and writing. This sometimes helps with access speed when files are on a remote network disk.
Options: Force large keyword format Force I10 keyword format |
|
||||||||||||
|
By default Ansys LS-DYNA input format is "small", however there are two options: (see "Getting started", "General card format" in Volume I of the Ansys LS-DYNA manual for more information.)
Both formats permit larger labels to be used, but "I10" is often preferred since file size is not much greater than "small" format, and the increase of label size from 99,999,999 to 9,999,999,999 is usually sufficient. Normally the format of an Ansys LS-DYNA input deck is determined as follows:
However it is possible to omit these yet to force Ansys LS-DYNA to read a file in i10 or long keyword format by adding " i10=y " or " long=y " to the execution line, therefore PRIMER also permits the format to be stipulated in this way using this option. Combining "i10=y" with "long=s"The Ansys LS-DYNA keyword reader converts the incoming keyword format file to an intermediate structured file for input to the Ansys LS-DYNA analysis code itself. For historical reasons this file also has small and long formats and it is sometimes the case that a keyword deck read in i10 format may contain labels which are too long for some small structured file fields. In these situations adding "long=s" (documented as "read small keyword, write long structured") solves the problem. The nomenclature "read small..." is misleading, it actually means "read small or i10" so this combination of directives is legal, for example the line may become: *KEYWORD i10=y long=s PRIMER adds "long=s" to the *KEYWORD line of a file in the following situations:
It is possible to turn this off completely by setting preference primer*long_structured_deck to NEVER. The default value of this preference is AUTO giving the behaviour defined above. |
|||||||||||||
Options: Include files inherit formatAnsys LS-DYNA treats the format of the master file of a keyword deck as being the default for any subsequent include files. It ignores any "long=y", "i10=y" or "long=s" suffices on *KEYWORD lines in child include files, so if an include file is to have a format that is different to that of the master file it is necessary to add a suffix to the *INCLUDE statement as follows:
PRIMER obeys the same convention by default, however unlike Ansys LS-DYNA it does inspect any *KEYWORD line in child include files, and if it finds any of "long=y", "i10=y" or "long=s" suffices on *KEYWORD lines it uses those to determine the format of the file, regardless of the format of the parent file or any suffices on *INCLUDE. Turning the Include files inherits format option off will suppress the default behaviour, treating each include file independently of its parent. However any suffices on the parent *INCLUDE card or on a *KEYWORD line in the file will still be read and taken as determining the format of the child include file. This setting can be made permanent via the following preferemce: primer*inherit_file_format:true |false (default true ) |
|||||||||||||
Options: Wrap Large format at 80 colsThe syntax of "long" format in LS_DYNA changed in Ansys LS-DYNA 7.1, November 2013.
The newer (7.1) format is now definitive, and the older format is obsolete. Since large format was not really used prior to early 2014 all large decks are expected to use the later syntax, however there may be a limited need to convert "old" decks to the "new" format, and the option to permits this by making the PRIMER keyword reader obey the old rules. (Note that when writing large format PRIMER uses the "new" syntax by default, but it is possible to write decks using the older syntax.) |
|||||||||||||
Options: Pre-read *PARAMETER cards |
 |
||||||||||||
|
Generally PRIMER does a good job of reading decks that use *PARAMETER cards, even when the definition of a parameter only appears after it has been used. In order to avoid the time delay involved in performing two read passes it handles this "used before defined" problem as follows:
However this approach can fail in some cases. In some situations the temporary substitution of zero in a data field causes an error in the keyword. Another example is where the format of a data card depends on the value of fields within it, and while substituting zero may be legal it means that the meanings of other data fields on the card are interpreted wrongly. Yet another situation that may cause problems is very complicated usage of *INCLUDE_TRANSFORM that depends on parameters. In these situations the solution is to make sure that the value and type of all parameters are known before their names are referenced, as in this way the correct values can be used ab initio with no need to go back and reformat a card. Selecting this pre-read option achieves this by making keyword reading a two phase operation:
|
|||||||||||||
|
Although the scan phase (1) is much faster than a normal keyword read (2) it will still take a significant amount of time, and it is recommended that you perform the following reorganisation of your input deck to avoid the problem in the first place. Your goal is to make sure that all parameter definitions are "known" before they are "used", and you can achieve this as follows:
|
|||||||||||||
Options: Convert <expression...> parameters to values |
|
||||||||||||
|
Ansys LS-DYNA permits "implicit" parameter expressions to be created in any data field by enclosing an expression in <...>. For example: *PARAMETER
R scale3.25
*NODE 10, <2.0*scale>, 2.0, 3.0 In this fragment SCALE is a conventional parameter of value 3.25 , and the X coordinate of node 10 will be 2.0 * scale = 6.50 (Using this syntax requires comma-separated format.) PRIMER handles this by creating an "implicit" *PARAMETER_EXPRESSION associated with that data field, allowing it to be edited and "remembered" for subsequent keyword output. However in a model with many < expression > definitions this results in many parameters being created, and this can make PRIMER very slow and unwieldy because parameters are expensive to store and process. Therefore an alternative of converting these < expressions > to their equivalent numeric values during keyword input is available, which works as follows:
Clearly this means that the < expression > is lost, the field cannot be edited as an expression and it no longer "knows" that its value depends on parameter scale . If the deck is written out this loss becomes permanent and the values are "frozen". So there are significant disadvantages to using this option and it needs to be used with some care and forethought, but it does solve the problem of processing files with a large number of distinct < expression > definitions. The default for this option is off, but this can be controlled by the preference primer*convert_implicit_parameter: true |false During keyword input PRIMER keeps track of how many <...> expressions have been encountered and issues a warning if this exceeds a threshold, offering to turn on this option for future expressions. By default this threshold is 100, but you can alter this by using the preference
primer*warn_num_implicit_parameters: <value>
Where
<value>
is a +ve integer, default 100, or zero to turn the warning off altogether.
|
|||||||||||||
Options: Read one entry per *keyword:Possible way of reading newer input decks in an format that is not yet understood by PRIMER . |
|
||||||||||||
|
When an input deck for a version of Ansys LS-DYNA newer than the current version of PRIMER "understands" is read, keywords sometimes gain extra lines of data. This confuses the keyword reader, making it think that the input deck is invalid, and it rejects the definition - even if there is only one definition per *keyword header. If this option is selected then PRIMER will read up to the number of lines it expects for the selected keywords ( *AIRBAG, *EOS , etc) and ignore any unexpected trailing ones by skipping to the next *keyword header, which usually makes these input decks readable. |
|||||||||||||
Options: Permit duplicate definitionsAnsys LS-DYNA permits some keywords to be read multiple times. This applies both to:
|
|
||||||||||||
|
*NODE is a special case. Duplicate definitions with the same label in different include files will be merged if:
Duplicate nodes not meeting these criteria for coincidence are treated as an error during keyword input. Coincident nodes are often used to "stitch together" models from include files, where multiple definitions of nodes are merged into a single entity. PRIMER emulates this by merging nodes using the same criteria so long as the *NODE entry in this panel is selected, which it is by default. |
|||||||||||||
|
*CONTACT is also a special case. Ansys LS-DYNA will permit duplicate labelled contact surface definitions, and from PRIMER 13.0 there is special logic to handle this. See Contact, Duplicates during input for details. |
|||||||||||||
|
The treatment of duplicate nodes (and other item types) has changed in PRIMER 12.0 with the introduction of "cloning":
|
|||||||||||||
|
A similar (and also undocumented) feature in Ansys LS-DYNA is that the following keywords may be multiply defined with the same label. In Ansys LS-DYNA it is likely, but not certain, that the last definition found will be used and the earlier ones discarded.
|
|||||||||||||
|
Therefore PRIMER contains similar logic that will permit these cards to be defined multiple times if selected here.
|
|||||||||||||
|
A further, and once again undocumented, feature of Ansys LS-DYNA is that "once only" keywords souch as *CONTROL cards will also be accepted if defined multiple times. As with the keywords above versions before PRIMER 12.0 would "lose" the 2nd and subsequent definitions; from PRIMER 12.0 onwards these too tested for differences, and then "cloned", and identical definitions will be written to every include file in which they were originally found. |
|||||||||||||
Options: Treatment of severe errorsPRIMER is quite strict about errors when reading input decks, since invalid data fields can result in a corrupt database. This can be a problem when it rejects what it believes is a corrupt deck when you, the user, know that it will in fact be OK to continue. |
|
||||||||||||
| If you choose these errors are downgraded to warnings, the offending data cards are skipped, and input continues. You do this at your own risk, and you must deal with the consequences of any resulting database inconsistencies. | |||||||||||||
Options: Special input exceptionsSometimes an input deck will contain a very large number of *BOUNDARY , *INITIAL or *LOAD cards, and this can be a nuisance if you only want to look at geometry as it makes the model slow to read and will also consume a lot of memory. You can choose to: |
|
||||||||||||
|
Clearly the option is only suitable for read-only inspection of the deck, and the option may give problems if nodes or elements are deleted or renumbered. |
|||||||||||||
Options: Save embedded comments |
|
||||||||||||
Comment lines are often placed among keywords,
and
PRIMER
can remember these and write them back out in the same locations.
PRIMER
regards comments as being "embedded" if they are between a *Keyword
header and data lines, or within data lines. Consider the following example:
$ This comment is "free standing" since it is not between a *keyword and data lines In the example above the comments in italics are "free standing" and will not be saved, whereas those in normal text are "embedded" and will be saved. A special exception is comment lines starting " $: ",. PRIMER does not save these lines, regardless of their location. Such lines are used when PRIMER writes things like data field headers, and it stops these lines being saved and rewritten multiple times. For example: *PART The "user defined comment" line starting with plain $ is embedded, and will be saved; but the field header line starting $: is not saved. It will be recreated on output if field header display is turned on. More details about the processing of embedded comments may be found in "Embedded" Keyword Comments. |
|||||||||||||
Options: Ignore LSPP comments |
|
||||||||||||
| LS-PrePost "tags" comments that don't need to be kept, such as card field headers, by starting these lines "$#" (similar to the way PRIMER uses "$:"). By default PRIMER ignores comments with this tag, untick this box to preserve them. | |||||||||||||
Options: Processing of *COMMENT cards |
|
||||||||||||
|
The Ansys LS-DYNA keyword format has a *COMMENT keyword which allows any number of lines of user text to be added to a deck, the comment being terminated by the next *keyword. This topic is covered in detail in *COMMENT , but a summary is provided here. "Anchoring" of *COMMENT cardsAnsys LS-DYNA ignores this keyword and its contents completely, but some users like to associate the *COMMENT with the following keyword(s) in order to store meta-data associated with that keyword. Therefore PRIMER stores the keyword(s) which follow the comment so that it can be re-inserted in the same place during keyout, maintaining the association between comment and keyword(s). The process is referred to as "anchoring" the comment in the deck and it can take place at two levels of complexity: |
|||||||||||||
|
|
||||||||||||
|
Both for backwards compatibility and to maintain speed during keyword output the default is "anchor single", but you can choose "anchor multiple" at any time. Swapping between modes has the following effects:
In other words changing modes here only affects future operations on comments, it has no retrospective effect and each comment "remembers" the mode used when it was created. The default setting can be changed by the preference primer*anchored_comment_handling: SINGLE | MULTIPLE |
|||||||||||||
Treatment of "$" comment lines within *COMMENTIt is sometimes the case that *COMMENT is used to remove a keyword temporarily from the input deck. In this example the user wishes to remove some user-defined loading from the model without losing the keywords, so the *USER keyword has been preceded by *COMMENT. *COMMENT *USER_LOADING_SETHowever how are the original comment lines starting with "$..." to be handled when PRIMER reads and stores the *COMMENT card? In this example it is fairly obvious that they should be remembered since they convey useful information. However what about the following examples? |
|||||||||||||
|
*COMMENT *CONTROL_TERMINATION |
|||||||||||||
|
*COMMENT *DATABASE_BINARY_D3THDT |
|||||||||||||
|
*COMMENT *MAT_PLASTIC_KINEMATIC_TITLE |
|||||||||||||
|
By default all are read and remembered, but you can set any permutation you wish and save this via preferences. |
|
||||||||||||
Truncation of trailing "$" comment lines*COMMENT cards are often padded with additional empty "$" comment lines, for example *COMMENT |
|
||||||||||||
|
If reading of "$" lines is included in the *COMMENT this could lead to a build up of an extra"$" line each time the deck passes through PRIMER , so by default processing of *COMMENT truncates trailing "empty" comment lines to a single one.
|
|||||||||||||
Options: *SET_COLLECT in *INCLUDE_TRANSFORMWhen *INCLUDE_TRANSFORM is used to read an include file it is possible to define label offsets for sets, variable IDSOFF, which is applied to all sets except _COLLECT ones. This means that if a self-contained file which contains *SET_xxx_COLLECT definitions and references to these is read with offsets it may "break" the logic of the file. This is because:
This option is designed to deal with this problem, its sub-menu looks like this:
By default PRIMER will behave like Ansys LS-DYNA, however if you have a file containing the situation above it may still be possible to read it using the option "Map unresolved references to set". This looks for the combination of SET_xxx_COLLECT N and undefined (latent) SET_xxx label (N + IDSOFF), if it finds this is maps the undefined set (N + IDSOFF) onto the _COLLECT set N. In addition PRIMER will check for combinations of set labels in such files which might suggest modelling errors. For example if you have *SET_xxx (N - IDSOFF) and *SET_xxx_COLLECT N this is likely to cause problems. These warnings can be turned off by un-ticking the "Issue warnings about possible errors" box. | |||||||||||||
Options: Drag & drop files are Ansys LS-DYNA |
|
||||||||||||
|
If you wish to drag and drop Ansys LS-DYNA files (*KEYWORD
format) that have a non-standard extension (*.inp,*.dat etc.) then tick
the checkbox. It will not check the extension of the file and read it as
a *KEYWORD file.
If it's unchecked, then file extension will be used to decide the file type and then read accordingly. |
|||||||||||||
Options: Remember skipped include files |  | ||||||||||||
Prior to PRIMER V22 any include files not found and skipped during keyword input were "lost" in the PRIMER session: they would be omitted from the Include tree and no *INCLUDE statement for them would appear in the keyword output file. From V22 onwards the default is now to "remember" these files. They will appear in the Include tree and can be read subsequently from there, their *INCLUDE statements will also appear in the keword output file (although the file itself is not written). By unticking this option you can revert to the pre-V22 behaviour and forget these files. | |||||||||||||
Options: Find data during scan |
|
||||||||||||
|
When using or to read a subset of include files from your model problems can arise if *PARAMETER or *DEFINE_TRNSFORMATION cards are referred to by the include files read, but are defined in other include files that have not been read. If this option is selected then PRIMER will search other include files for the missing definitions and read them in so that the files that have been read are correct. |
|||||||||||||
Options: Zero field spillover |
|
||||||||||||
|
PRIMER is strict about formatting and grammar errors when reading data, and this can result in an input deck being rejected due to minor editing errors. A particular example of this is when a data field has been hand-edited and given too many trailing zeros so that it spills over into the next data field. Consider the following example: $ FIELD1 FIELD2 FIELD3 FIELD4 FIELD5
200000 100.0000 1 30.00 1
In this example it is clear that the trailing zero on 30.00 (in red) is an accidental spill-over into the next data field, and can safely ignored. By default PRIMER will reject this line as being wrongly formatted, but permitting "Zero field spillover" will accept it instead. WARNING : permitting this can cause errors. The example above showed harmless trailing zeros on a floating point number, but consider the following: $ FIELD1 FIELD2 FIELD3 FIELD4 FIELD5
200000 100.0000 1 30000 1
Field #4 is now an integer, and by ignoring the trailing zero its value has been changed from 30000 to 3000, which would (probably) be an error. Use this facility with caution, and only after you have inspected the offending line to make sure that it is safe. |
|||||||||||||
Options: File input & output tuningWe have received reports of slow keyword file read and write behaviour on some platforms when the files in questions are on a remote networked disk. PRIMER uses standard ANSI C buffered i/o routines when reading and writing files and in most cases the default system settings are satisfactory. However users with "problem" remote files have reported improvements when changing the default settings, so the following may be altered: |
|
||||||||||||
| Input and output Buffer size |
These are the sizes in bytes of the memory buffers used by the system for reading and writing files. ANSI C documentation states that they must be a multiple of 2 bytes, although it does not stipulate a size; most systems default to 4096 bytes. Experimentation by Oasys Ltd suggests that:
However you may find that different values work better on your system: you can experiment by setting these values manually and measuring the time taken to read and write files. If you find values that work better than the defaults then you can set them in the "oa_pref" file using:
primer*input_buffer_size:
nnnnnn
Where nnnnnn is the size in bytes. For most users disk read/write speed is not a problem, and it is suggested that the default values are used unless they are demonstrably inefficient. |
| Echo frequency (lines) |
During file input and output PRIMER reports its progress via an "echo" of the current line to the dialogue box, by default every 1000 lines. It also checks the user interface at this frequency to see if the user has made any inputs, for example using the button to halt i/o. Users working on remote displays, where updates of the user interface have to travel over the network, may find that there is a speed advantage in reducing this echo frequency. You will need to experiment, but values of 10,000 or greater may help in these circumstances. To store revised settings in the "oa_pref" file use:
primer*input_echo_frequency:
nnnnnn
Where nnnnnn is the number of lines. Users working on a local display will almost certainly find no benefit is gained from increasing these values. |
Options: Comment reading options
|
|
|
- Turn ON/OFF
reading of HM comments in the keyword file.
- Turn ON/OFF reading of ANSA comments in the keyword file. - When ON, PRIMER will set a material or section title (if one is available from an HM comment), and if the item does not already have a title. If OFF, The title will not be set to any available HM comment title, but the comment will be retained for keyout. |
|
Options: Text box messages during Keyword readSome errors and warnings during Keyword input generate a "text box" panel that halts processing until the user clicks OK (or something else) to acknowledge the message. |
|
| If the "suppress" option is used then the messages will still be output, but only in the dialogue box, so the user does not have to acknowledge them and processing is not halted. | |
Options: Save Keyin log to fileDuring keyword input all messages written to the dialogue box are also saved to file, and can be viewed in an external editor using the button. However this log file is overwritten each time a new keyword file is read, and it is also lost at the end of the PRIMER session unless saved manually from an external edit session. |
|
It can be useful to save this information, especially when running PRIMER in batch mode (no graphical user interface), and this option permits all messages to the dialogue box to be saved in file primer_readlog.txt in the directory of your choice.
The directory may be specified in two ways:
-
By giving an explicit pathname, for example
C:\users\myself\readlogs
- By using the special name JOBDIR , which means "use the directory from which the master keyword file was read". It is legal to append relative paths to this, for example JOBDIR/../logs will select the directory above, then down into sub-directory logs. This can be useful if your system has read-only directories.
If the file primer_readlog.txt already exists its name will be amended to primer_readlog _n .txt where _n is the smallest integer required to make the filename unique. In this way existing files will not be overwritten.
Writing of this log file can also be turned on in two other ways:
- By using the command-line option ' -rlog_dir= pathname '
- By setting the preference ' primer*save_read_log_dir: pathname '
It doesn't matter which method is used, all create the same file. The order in which these are read are (1) preference, (2) command-line, (3) this options panel. The most recently read definition will control the pathname that is used.
If this facility is turned on then two extra blocks of information are written:
| (1) Merged *NODE data |
Ansys LS-DYNA permits multiple definitions of a
*NODE
with the same label to exist in an input deck so long as the bopundary
conditions (
TC
and
RC
)
of the two definitions are the same, and their coordinates are coincident
to within a small tolerance. This tolerance is defined by:
(xdist2 / xdist1) < 1.0e-8 where
In addition if a *NODE_MERGE_TOLERANCE card is defined then the nodes must be further apart than this tolerance to be considered "not coincident". PRIMER uses the same logic as Ansys LS-DYNA, and automatically merges coincident nodes that obey these rules. It "remembers" the duplicate definitions as "clones" - see above for more details about this process. Normally this merging process is carried out silently, but if this log file is being written then an extra report of all merged nodes is written to the file. An example of this output is:
Node 1 merge SUCCEEDED
It will be seen that the coordinates and also the include file containing each definition is reported. |
| (2) Duplicate *PARAMETER data |
Ansys LS-DYNA permits the
*PARAMETER
keyword
to use suffices
_LOCAL
and
_MUTABLE
,
which make it legal for a parameter name to be used more than once, possibly
with different values. In addition the
*PARAMETER_DUPLICATION
card controls how potentially illegal duplicate parameter definitions
will be processed, and controls which of multiple definitions will be
the true value.
These options may be flexible, but they can also lead to complexity if input decks with many include files contain multiple different definitions of a parameter, making it hard to tell which value is used in which context. PRIMER tolerates this, obeying the same rules as Ansys LS-DYNA to determine how multiple definitions should be processed. It also tolerates and "remembers" illegal duplicate definitions, both so that they can be written out again and also to cope with changes to the various keywords that could alter their legality. This processing is normally carried out silently, and it is necessary to go to the [keyword] panel to view the status, value and legality of all parameters. However if keyin logging is in force then the status of all duplicate parameter names is written to this file, giving a permanent record of their status when read. An example of this output is: Parameter name: X701
Instance 1: *PARAMETER (Real, value = 701.1) in
master file
Instance 2: *PARAMETER_LOCAL (Real, value = 801.1)
in incl_2.key
Instance 3: *PARAMETER (Real, value = 901.1) in
incl_3.key
In this example parameter X701 is defined three times:
Usages #1 and #2 above are legal, since #2 (being _LOCAL ) will only apply in include file incl_2.key. So both are marked as OK-USED Usage #3 is illegal since a plain *PARAMETER with no suffix is "global", and this conflicts with the original definition in the master file. So this is marked as ERROR-IGNORED . You can find out more about how PRIMER handles parameters under the PARAMETER keyword documentation. |