Variable data structure - suggestions

[mkovari]

Now that the variable declarations and initializations are in Python, we could create an all-singing, all-dancing data structure. Here are some suggested fields.

• Variable name
  Max 16 characters?

• Short description - for output files
  Max 100 characters?

• Long description - for the documentation
  Free text. Markdown, rich text or html might be permitted.
  Unlimited length
  May also be used for any future rich text outputs

• Mathematical symbol
  Markdown, rich text or html

• Initial value

• Format to be used for output (by default)
  Exponential or decimal format

• Units

• Available as an input?
  Yes/No

• Typical maximum value
  Above this value warnings may be issued.

• Typical minimum value
  Below this value warnings may be issued

• Available as an iteration variable?
  Yes/No

• Active as an iteration variable in this run?
  Yes/No

• Available as a scan variable?
  Yes/No

• Active as a scan variable in this run?
  Yes/No

• Included in OUT.DAT and MFILE.DAT?
  Yes/No

@timothy-nunn @chris-ashe @jonmaddock @clmould @ajpearcey

[grmtrkngtn]

Are there any technical downsides or limitations to having a data structure with many fields?

[grmtrkngtn]

I’d like to see a more systematic, hierarchical data structure for PROCESS to because I think it would be much more useable, particularly for new users. The improved variable names have helped, but I think we could go further.

For example, if I'm looking for CS coil variables, we have something like:

build_variables -> cs_thickness

cs_stress_variables -> cs_crack_length

A clearer systematic hierarchy could be:

cs_coil -> cs_build -> cs_thickness

cs_coil -> cs_stress -> cs_crack_length

I think this also reflects the way engineers view the plant in other domains (product breakdown structure)