Providing Alternative Definitions for Wholly Encrypted *MAT, *DEFINE_CURVE and *PAREMETER Definitions

Providing Alternative Definitions for Wholly Encrypted *MAT, *DEFINE_CURVE and *PARAMETER Definitions

It is sometimes the case the proprietary input decks will contain material and loadcurve definitions that are totally encrypted, missing even the keyword headers and title lines. In this case PRIMER cannot "know" that these definitions exist, and their absence can generate all sorts of problems and error messages during model check. To deal with this problem from V11 onwards PRIMER allows you to provide alternative definitions for the missing items in a special "encrypted" section after *END.

We have also encountered situations where parameters have been defined within an encrypted block, but referred to elsewhere (in clear), so from V13 onwards it is also possible to add parameter definitions to this post *END encrypted block.

The assumption is that these definitions will be simplified non-proprietary variations of the encrypted data that provide enough information for PRIMER to work normally.

The syntax of this block is:

Here is an example of such a block:

   *END
   $
   $ ===============
   $ ENCRYPTED cards (simplistic info for encrypted items in main deck) 
   $ ===============
   $
   *ENCRYPTED_START
   $
   *MAT_ELASTIC_TITLE
   This is a fabricated material definition
           22     7.85e3
   $
   *MAT_RIGID
           23       10.0
   $
   $
   *DEFINE_CURVE_TITLE
   This is a fabricated curve
           99
   $
   *DEFINE_TABLE_TITLE
   This is a fabricated table
          199
   $
   $
   *PARAMETER
   R ENDTIM       750.0
   $
   *ENCRYPTED_END

The *MAT and *DEFINE_CURVE keywords are read in exactly the same way as they would be in the main part of the deck, and they are treated inside PRIMER in exactly the same way with the following exceptions:

• Material definitions are not checked during model check. This because populating them with zero values might be invalid, and it would be silly to generate errors because of this.
  
  
• Items defined in this way are "locked" against deletion. This is because they are presumed to be present inside opaque PGP encrypted blocks, and deleting them might lead to an inconsistent model, or alternatively lead to their labels being re-used resulting in a clash.
  
  
• Their labels are locked against being changed. Again, their labels are fixed inside opaque PGP encrypted blocks, so changing them could lead to conflicts. (This lock is not absolute: a determined user could change them by various means, for example by using Text Edit; however it is assumed that users will be sensible!)
  
  
• During keyword output they will not be written in the main deck, but rather after *END in this *ENCRYPTED section. If extra data fields beyond the minimum required were provided these will be written out, but otherwise only the bare minimum (as in the example above) will be written.

The *PARAMETER definition is read and processed in exactly the same way as *PARAMETER cards in the main body of the deck. However bear in mind that if a *PARAMETER_EXPRESSION refers to a parameter in an encrypted block, and you define the missing parameter after *END in the same file, then you will get an "out of sequence" error during keyin since the expression will not initially be able to be resolved. PRIMER will sort this out later when the deck is complete, but to avoid this problem you should consider carefully the order in which files are read.

Alternative syntax with each card inside its own *ENCRYPTED_START ... *ENCRYPTED_END pair

Some workflows require each of these definitions to be within its own start...end pair, for example

The preference primer*keyout_post_end_encrypted can be used to modify this output as follows. 

The example above uses "individual" output.