National-Composites-Centre / CompoST

This repository serves as reference point for standard classes for composite definition.
MIT License
3 stars 2 forks source link

[Feature]: Material references #8

Open luke-ncc opened 1 month ago

luke-ncc commented 1 month ago

Describe the project you are working on

A simple CompoSt visualisation tool. This tool can be used to view surfaces, splines, and ply edges and cross-sections.

Describe what the format is lacking that you need in your project

Component materials are referenced by using a string:

"material": {
     "anyOf": [
         {
           "type": "string"
          },
          {
            "type": "null"
          }
      ],
      "default": null,
       "title": "Material"
}

This causes amiguity if there are multiple materials under the same name.

State what specific feature could be added for what you need to represent

The format could use define a unique way of referencing a material in the component. Then, information about the material of a component can be referenced directly from that component.

Suggest how the feature could be implemented to support this project as well as future projects that might need this feature

Materials defined here:

"Material": {
      "properties": {
         "materialID": {
            "anyOf": [
               {
                  "type": "int"
               },
               {
                  "type": "null"
               }
            ],
            "default": null,
            "title": "MaterialID"
         }
      }
   }

Can be referenced in a component with this property:

"materialID": {
     "anyOf": [
         {
           "type": "int"
          },
          {
            "type": "null"
          }
      ],
      "default": null,
       "title": "MaterialID"
}

Can this feature be represented already by combining other features?

Yes. But: Requires loading in all materials and using lookup by name

Version

v0.67

JKucera-NCC commented 1 month ago

For some current workflows it feels more natural to operate on name basis for reference. Also, this is likely going to be internal database, or materials specific for a project, in such cases ID management just adds requirement for all scripts operating with CompoST.

I see the benefits outlined, but decision needs to be made here, on the philosophy of approach. I would lean towards trusting Engineers not to name 2 materials the same on the same part, rather than trying to create mechanism that prevent this, even if these add minimal burden in most cases.