CUBA keywords need probably to be grouped`

[itziakos]

It looks that some CUBA keywords can only have meaning as part of a specific component (e.g.
keywords BOND_LABEL and BOND_TYPE probably only make sense for a Particle).

Having one DataContainer type might be convenient now but having all the keywords supported when they are not necessary is performance-wise inefficient and makes bad use of memory and hard-disk space. We should also consider that it can lead to confusions (e.g. a mesh cell with SIMULATION_DOMAIN_DIMENSIONS does sound a little weird).

We should probably use a subtype of the DataContainer for the different components where such an object is used. The implementation could be as simple as binding each DataContainer subtype into a specific CUBA keyword group.

Nevertheless, I believe that this avenue needs to be discussed after the current first phase of the api implementation is delivered.

[itziakos]

The plan for this feature is to do the following:

• Each entry of the cuba.yml will be augmented with data attribute that will have value true/false based on the fact that needs to be supported by a DataContainer
• Other containers e.g. configuration containers will have their own attribute e.g. config that will also be true/false with similar meaning. A keyword can belong to more than one enum description
• The cuba-generate then will be able to produce a cuba.py containing two separate enum classes containing the desired keywords.
• For each enum class we can create a specialized dictionary like container that will support only the keywords provided by the associated enum.

Please note that since the int associated with each keyword is going to has the same value for both enums coping common key,value pairs between the different containers will be supported without any problem.

[ahashibon]

The most straightforward way is to add to which SimPhoNy component(s) (SD, CM, SP, BC) each CUDS keyword may be used in. This is in addition to the information we have now. Any additional grouping would not be very useful at the moment, we can reconsider this later on when we consolidate a more complete list at the end of Y2.

[itziakos]

It sounds reasonable, thanks @ahashibon.

[stefanoborini]

Closing as it was for discussion and is no longer relevant.