Physical_oM : Creation of a IPhysicalMaterialFragment (or Properties) interface

[al-fisher]

The idea here would be able to provide a common interface among "Physical Materials" at the exclusion of say "Graphical Materials". The IPhysicalMaterialFragment or IPhysicalMaterialProperties would impose that a Property called Density would be required. This would mean that Disciplines (Environment and Structure etc.) can define their own Density but the existence of the property it will be guaranteed. We obviously moved Density away from the parent Material object for good reason. I wonder if through an interface this might work though. Thoughts? @IsakNaslundBh @FraserGreenroyd @rwemay

Naturally conscious of avoiding interface explosion - so interested in opinions. There are also the subtleties of different values of density even within a single fragment (timber being one). An interface enforced Physical Density would constitute the default density for that material.

[rwemay]

This sounds like a good direction, and would be really good to get sorted so we can have more powerful/convenient get methods - weight of a collection of elements etc. Would be good to map out a couple of scenarios (at least) to make sure its fit for purpose.

[IsakNaslundBh]

Had missed this fairly old issue. Think this could be a good idea. Would also greatly simplify some of the work in the Matter_Engine when trying to extract density from a physical material. @kThorsager

@FraserGreenroyd does this make sense to you as well?

Also, could potentially be done as a coordinated exercise with

https://github.com/BHoM/BHoM/issues/750 and https://github.com/BHoM/BHoM/issues/749 (does not have to though, might be simpler to make this change separately, and make sure Structures and Env follow suit to start with)

[kThorsager]

Had missed this fairly old issue. Think this could be a good idea. Would also greatly simplify some of the work in the Matter_Engine when trying to extract density from a physical material. @kThorsager

Depends, will Material only store IPhyiscalMaterials? But in either case, more structure on the naming and getting of the density will help.

And while a physical material obviously will have a density, does all materials which calls them self Physical need to store its density? Have vague memories that Materials used to have a YoungsModulus on them as all materials surely have them, but turned out to be positively pointless for Environment to drag around with. Feels like this might run into similar problems down the line.

But having a interface for physical materials as opposed to other things yes, but perhaps have a sub-Interface which enforces the density part?

[IsakNaslundBh]

Depends, will Material only store IPhyiscalMaterials? But in either case, more structure on the naming and getting of the density will help.

No would store all types. But this could help filter out material properties that could/should be used to get the density of the physical material.

And while a physical material obviously will have a density, does all materials which calls them self Physical need to store its density?

Think that would be the idea behinds this interface.

Have vague memories that Materials used to have a YoungsModulus on them as all materials surely have them, but turned out to be positively pointless for Environment to drag around with. Feels like this might run into similar problems down the line.

Should be very limited in scope to things that basically are cross discipline, always, like the density. Same kind of reason that is the only property you can extract in the matter engine. This should never be expanded to structural properties such as YoungsModulus, think this is basically just puts another filter on some of the material fragments.

But having a interface for physical materials as opposed to other things yes, but perhaps have a sub-Interface which enforces the density part?

Think that is basically the idea behind this interface :)

[FraserGreenroyd]

Makes sense to me, as long as Environment materials have a density they'll be happy, so moving to a higher level to ensure the property exists on all material fragment/options sounds like a good idea to me :smile:

[IsakNaslundBh]

@al-fisher think we can close this as of https://github.com/BHoM/BHoM/pull/1443 ? :)

That PR has essentially formalised the Management of densities in the IDensityProvider interface.

Could ofc change the name of the IDensityProvider to IPhysicalMaterialProperty if we think that is a better name, if so, can keep this issue open and close with a PR updating the name.

Kind of happy with either of the names myself. Thoughts from the group? :)

[al-fisher]

Thanks @IsakNaslundBh

If I had to pick I might be tempted to go with IPhysicalMaterialProperty as the name - but equally not strongly opinionated. What we should do however is list/map the various interfaces in the foundational space to ensure we are being consistent and have a strategy for naming conventions - for this interface and going forward. Perhaps we quickly sketch that out as a means of closing this issue?