PRIMER 22.1

Deletion Rules

Deletion Rules

There are some strict rules governing how deletion is applied which are intended to prevent you accidentally leaving something "hanging" by deleting an item upon which it depends. These rules are:

  • No entity may be deleted if it is "locked" because it is referenced by another entity which is not itself being deleted. For example a part definition cannot be deleted if it is referenced by an element which is to remain. The entity hierarchy is described in Operational Hierarchy .

    However if "Forced deletion", added in PRIMER 10.0, is used then items which are "locked" can be deleted. However they will be replaced with Latent definitions, so this is not a good general solution to the "why can't I delete this?" problem. Forced deletion is described in more detail below.
  • Switching Delete recursive on or off (see figure above) before pressing Apply affects the selection of entities to be deleted. For example if parts are selected for deletion and recursive deletion is switched on then all entities (constraints, elements and nodes etc.) associated with that part will also be deleted. Without recursion only the chosen parts are selected for deletion, and only those which are not referenced by any entities will in fact be deleted. (see rule 1).
  • If the REMOVE from sets button is selected then PRIMER removes deleted entities from sets. With this option any deleted part (or node etc) will also have its reference removed from any part sets (or node sets etc.).Without this option a part (or node etc.) referenced by a part set (or node set etc.) will not be deleted when it is referenced by another entity (ie the set) which is to remain.

    From V11 onwards set contents can be "locked" against deletion on a per-set basis. This was introduced in order to protect against accidental deletion of set contents where doing so would invalidate the item using the set. This topic is described more fully under Locking Sets against Deletion in SET .

Connections may need some special treatment during deletion. The CONX_ACTION popup allows you to set what action to do when PRIMER needs to consider connections that are attached/tied to parts or layer elements that you select for deletion or connection contents themselves are being deleted. Note for adhesive connections, selected solids can be removed from the connection using "No action" or "Empty conx" without emptying it. The options are:

  • No Action . PRIMER will not take any special action. This could cause problems if the connection uses *ELEMENT_BEAM_PID as the element refers to the part which will stop the part being deleted.
  • Empty conx . PRIMER will delete the entities (e.g. nodes and solids) that make up the connection and leave the connection latent.
  • Remove conx . PRIMER will delete the connection and it's entities.
  • Remove layer(s) . PRIMER will delete the entities (e.g. nodes and solids) that make up the connection and then remove the layer containing the part from the connection. If the connection then only has one layer the connection will be deleted.

Include files also get special treatment.

If you have selected category Include File for deletion then the contents of the include file will be selected for deletion, but historically PRIMER behaviour is that the include file itself will not be deleted, even if it is totally empty. This can be a nuisance since if it is an *INCLUDE_TRANSFORM then any *DEFINE_TRANSFORMATION that it references will also be locked against deletion, as will any parameters used on either of these cards.

From release 12 onwards there is now an " Empty Include file action " option:

  • By default " No action " is taken, meaning that behaviour is exactly the same as before and deletion of an include file will remove its contents but leave the empty file and its associated *INCLUDE cards in the model.

  • Choosing " Remove file " will, if the include file itself has been selected for deletion, also delete the *INCLUDE entry and associated cards if the file is empty.

Notes :

  1. An Include file will only be deleted in Remove File mode if the file itself has been selected for deletion, either explicitly via category Include File or by selecting Model . Just deleting the contents of an include file will not delete the file itself, even if this switch is set.

  2. If " forcible deletion " is used this will leave latent entries behind. The most common reason for using this option is to replace the contents of an include file, so deleting the include file as well would rather defeat the purpose of the exercise! Therefore in this context the fact that the include file has no explicit contents, only latent ones, does not qualify it as "empty" and it will not be deleted.