CASE

Version history

PRIMER 11	Support for the *CASE keyword was added but with some limitations, notably that it could not be used in conjunction with *INCLUDE_TRANSFORM or *DEFINE_TRANSFORMATION if encountered inside *CASE . In addition the generic keyword editor did not show, or permit changes to, the current case membership of an item.
PRIMER 12	These limitations have been removed. *CASE can be used with any keyword type, and there is now a "Case" column in the keyword editor if cases are present in the model.

Maximum numbers of *CASE definitions in PRIMER:

• There is no limit to the number of Master *CASE cards.
  
  
• The following limits apply to child cases:
  
  - The maximum number of child cases in a model is 4095 (but their labels can have any value)
  - The maximum number of unique combinations of child cases is 1023
  - The maximum number of child cases in a combination is 1023
  
  (The concept of a " combination " of child cases is explained below )
  
  

Using *CASE inside include files

When the *CASE keyword first appeared in Ansys LS-DYNA no mention was made in the keyword manual about limitations upon where it could be used, and in particular no restriction upon its use in include files was mentioned. Therefore PRIMER 11 permitted its use in both master deck and any include files.

However the Ansys LS-DYNA 971 R7 manual (2013) states that the *CASE keyword cannot be used inside include files. This date coincides with the development of PRIMER 12, so rules forbidding its use inside include files have been added to that version, and using *CASE in any file other than the master deck will generate an error. This is a "soft" restriction, so if Ansys LS-DYNA ever lifts this limit in the future a simple switch in PRIMER will also permit it.

Mini-tutorial on *CASE

This section gives a summary of how the *CASE keyword is used in Ansys LS-DYNA, and how it is implemented in PRIMER . It also describes the terminology and colour scheme used in this section and in the online help texts inside PRIMER .

Please read this before using *CASE in PRIMER as it explains some important concepts that you will need to understand.

This can be thought of as a "collector" keyword which owns one or more sub-cases (or " Child cases " in PRIMER )

• It is a free-standing keyword, just like any other in the deck.
• It has label which must be unique to this master *CASE
• It contains one or more child cases
• It may not itself be contained inside a *CASE keyword
• It may only be used in the master keyword deck, and not in include files.

These keywords define what is contained within child (sub-) cases. They always come in "begin ... end" pairs that surround other keywords, suffix _ nnn giving their child case number nnn .

• These are not free-standing keywords, and they have no autonomous existence in the input deck.
• The label nnn defines this child case uniquely.
• Child case labels are totally independent of Master *CASE labels, thus it is legal to have Master *CASE 1 and also child case 1.
• The child case begin ... end pair of keywords may occur any number of times within a deck
• Child cases keywords may be disjoint or nested.
• They may only be used in the master keyword deck, and not in include files.

When PRIMER is dealing with models that contain one or more *CASE cards it requires that a Master *CASE is current at all times, and only items in this master *CASE and in the main model are visible and available for editing. In order to work with items in backing store you must first make the master *CASE containing them current.

This organisation is expressed in the diagram on the right.

The user may make a new master *CASE current at any time, but this is quite an expensive process since it requires a lot of internal processing (see " Changing the current Master *CASE " below) so it is best done only when necessary.

In this left hand example we have two separate definitions of node 1 (here with different coordinates): one in child case 1 and one in child case 2. It is clear that changing one definition, for example in child case 1, should not have any effect on the definition in the other child case.

In PRIMER the two definitions are referred to as being " aliases " of one another.

In this right hand example we have a single definition of node 1 that is common to child cases 1 and 2. It is clear that editing the definition, say changing a coordinate, should result in a change in both child case 1 and child case 2.

In PRIMER the two definitions of Node 1 are referred to as being " in combination " with one another.

Creating and editing a child case

Using the right-click popup from an entry in the master *CASE panel above you can invoke the Child Case editing panel.

This allows you to Add... and Remove.. . items of any type in the current child case.

If the child case is not active in the current master *CASE this will be stated, and the Add... and Remove... buttons will be greyed out.

However you will still be able to sketch and list contents. The reason for this limitation is that child cases that are not current are on backing store, where their content is effectively "read only".

This panel is designed to provide a fast and simple way of moving items between the current child case and the main model, and it has the advantage that multiple items can be added / removed in a single operation. However this process has limitations when a labelled item in the current child case is also in combination with one or more other child cases that are currently on backing store and you attempt to move such an item from the child case to the main model. This would cause a clash if the other case(s) in the combination were made current because this would mean duplicate definitions in both the other case(s) and the main model.

Prior to the Update (to make the scratch definition permanent) PRIMER checks all items selected for addition to or removal from this child case to detect any such clashes, and gives you the following options if anty such clashes are found:

Editing the child case membership of an item using the [C] button:

Another, and much more flexible, way of editing the child case membership of an item is via the [C] case membership editing button in the item's editing panel.

This will only appear if the model contains *CASE data, and it will always be to the right of the file filter button for include files. This maps the child case membership editing panel for the item in question (here node 1531218):

In this example the node is currently in the main model, and there are three child cases currently defined.

Master *CASE 1, the current master case, contains child cases 1 and 2.
Master *CASE 2, not currently active, contains child case 3.

At present the node is eligible for moving to any of the child cases, which can be done by ticking the relevant box in the Sel(ect) column.

The user has now ticked the Sel box for child case 1, and the following has happened:

• The node is shown as "Selected" in child case one.
  
  
• Selection in child case 2 has been prohibited.
  
  Remember that the current master *CASE contains child cases 1 and 2, so if the node is present in child case 1 it cannot also be present in child case 2, since this would constitute an illegal duplicate definition of the same label.
  
  
• Selection in child case 3 is still available if the user wants to choose it, as there is no potential clash.

The user has now chosen to place this node in child case 3 as well.

This means that there will be a single combination definition of this node in child cases 1 and 3. If the keyword deck were written out at this point it would contain the lines:

*CASE_BEGIN_1
*CASE_BEGIN_3
*NODE
  1531218      1.0      2.0   (coordinates etc made up here)
*CASE_END_1
*CASE_END_3

Separate child cases : changing the definition from a combination to an alias .

Let us suppose that the user does not want to have a single common definition, but rather two wholly separate definitions of this node in cases 1 and 3 - perhaps so that they can have different coordinates. The "separate child cases" button tells the editing panel that on update it should separate the single common definition into two.

At this point it should be made clear that all edits to a definition's child case membership made in this panel are "pending", as with all changes made in an editing panel, and will only become permanent when the parent editing panel is updated and closed. So if we go through the update cycle for this node, then reopen it for editing and use the [C] button again the following will be shown:

This is telling us that:

• The current definition of this node is in child case 1 only, which is current in this model.
• It is not selectable in child case 2 because that would cause a crash for the reasons given above
• There is a separate alias definition of this node in child case 3, currently on backing store (BS).

If this deck were written to a keyword output file the lines for this node would now be written out twice as two separate definitions:

*CASE_BEGIN_1
*NODE
  1531218 1.0    2.0 (coordinates etc made up here) 
*CASE_END_1

*CASE_BEGIN_3
*NODE
  1531218 1.0    2.0 (coordinates etc made up here
*CASE_END_3

If we wished to merge these two alias definition back into a single combination definition, then ticking the Sel box on the row for child case 3 would result in that change being made when the node editing panel was updated.

To make this point clear we now:

• Abort this node editing panel, leaving the definitions as aliases .
• Change the current master *CASE from 1 to 2 (which contains child case 3)
• Reopen the node editing panel
• Click on the [C] case editing button again

Move to main model: moving this definition out of the child case and back into the main model.

If we select this option then the panel (still in child case 3) above becomes:

Upon update from the parent node editing panel the following will happen:

• This definition (in child case 3) will be moved to the main model.
• All other definitions of this node currently on backing store will be deleted .

Reset to original: resets case membership to its original state before editing.

As explained above all changes made in the case membership editing panel are "Pending", and will only be made permanent when the parent editing panel (a node editing panel in the example above) is updated. Resetting case membership to its original state removes any edits and restores case membership to its state when the editing panel was first opened.

If an item is in a child case this fact is appended to the menu listing.

In the example here loadcurves 31 and 32 are both in child case 10

Filtering by child case is available

This can make it easy to "drill down" to the items of interest in a child case.

Note that "Main Model only" is available as an option here, which is the same as saying "not in any child case".

In addition the cross-reference editor will show that a reference is from an item in a child case that is in the current model.

PART 1 in this example is referred to by shells 3 and 4 in the main model, and shells 1 and 2 in child case 1.

This example shows how this appears in the cross-reference editor as a reference from a CHILD_CASE :

Here PART 1 "knows" that items in child case 2 currently on backing store refer to it, and this locks it against deletion.

Only a single cross-reference from the child case is made, regardless of how many items within it reference the item in the main model.