2. Item catalogs#

2.1. phenomenons_modelisations.py catalog#

  • The names of phenomena and models must be validated by EDA/RTA because they appear to the user.

2.2. physical_quantities.py catalog#

  • Give a name to quantities in the form XXXX_S where S can be:

  • R: real

  • C: complex

  • F: function (K8)

  • When you don’t want to create a new quantity that is too particular, use « neutral » quantities: NEUT_R or NEUT_K24.

  • When editing the GRANDEURS catalog, remember to update the « size description » document [D4.04.02] and sort the size names in alphabetical order.

  • Do not define quantities such as: L, K32, K80

  • Do not destroy CMPS components in an existing quantity without verifying that no type_element uses it.

  • Do not change the CMPS order of an existing quantity without changing the element_types that use it.

  • When introducing a new component into a quantity, put it after the existing CMPS. This avoids « breaking » programming that is too « hard »; for example, a programmer may have done:

  • checking that “DX” and “DY” are the first two CMPS of the quantity “DEPL_R”,

  • then use DEPL_R (I), I = 1.2.

2.3. OPTIONS Catalogs (Options/*.py)#

  • Option names must be validated by EDA/RTA if they appear to the user.

  • Before adding a new parameter to an option, you must check if it does not already exist in the shared settings catalog (Commons/parameters.py)

  • Do not reinvent the parameter names for each option; be inspired by those already chosen. The usual form is as follows: name_par = “P”//name_gd.

Examples: PMATERF, PGEOMER

  • Comment parameter field: example:

PCAGEPO = inputParameter (… comment= » RAYON AND EPAISSEUR POUR LES TUYAUX »

  • If the field associated with the parameter always has the same « origin ». You can indicate its « container », that is to say the data structure where this field is located.

For example:

PCAGNBA = inputParameter (…, container=” CARA!. CARGENBA “,

  • When adding a new option, you must fill in the « CondCalcul » block. This task is not an easy one, as it requires knowledge of all the elements. When in doubt, you should always prefer to declare a list of items that is larger than necessary. When a user is faced with a block due to this excess of caution, there will always be time to remove the restriction by adding a « - » line in the block.

2.4. Type_element catalogs (elements/*.py)#

  • Before adding a new local mode to an element catalog, you must check if it does not already exist in the local shared mode catalog (Commons/located_components.py)

  • For local mode names, take inspiration from the names chosen by the neighboring type_elements. Respect the use:

  • Cxxxx: card-like mode

  • Nxxxx: cham_no type mode

  • Exxxx: cham_elem type mode

  • Ask questions about the consistency of the type_element that you modify with the other type_element:

  • why would the new type_element have a local mode « at the nodes » when all the others have it « at the points of GAUSS »?

  • why doesn’t the new type_element use this parameter field, this component?