PhysicalProperty definition (11.04.2024 discussion)

[JosePizarro3]

@JFRudzinski @lauri-codes @ndaelman-hu @Bernadette-Mohr

I am opening a new discussion on PhysicalProperty compiling comments, questions, and potential issues raised by Nathan and Lauri in #43. You see it is a bullet list, so we need to cross each item when solutions or discussions are agreed upon.

• We are not sure on how to instantiate value in the generic PhysicalProperty class, as of right now, it is an empty property(), which might give problems when using custom properties. We have to explore this Area D+C.
• @ndaelman-hu raised the point on why source does not include 'synthesis' and 'ml_methods'.
  @JosePizarro3 commented that 'ml_methods' could be encoded in 'analysis' and that 'synthesis' is within 'measurement'. We have to discuss this with Area A (Andrea, Sarthak).
• @ndaelman-hu raised the point on why we are defining strings like type and label. We need to add more examples and use-cases to see whether these are useful or not.
• @ndaelman-hu raised the issue of having variables that are also physical_properties. @JosePizarro3 doubted whether this is for functionals or some other situations. We need some examples where the current schema might be broken.
• @lauri-codes said: We don't currently have a concept for what you are doing here with rank: section definitions only consist of fields for quantities and subsections, whereas rank here is some kind of a default value for all instances of this section. This may cause all kinds of problems in the current code and in the YAML schemas.
  @JosePizarro3 replied: Not sure if I understand this part. rank must be defined by default for any physical property defined in the schema. This is just the rank of the tensor that we are refering to, so I don't know why any YAML schema should touch on this. Or do you mean that, defining by default like in here is not possible in a YAML?
• @lauri-codes said: Are the functions needed here? Remember also that if someone uses PhysicalProperty as a base section in YAML schemas, they cannot define functions.
  @JosePizarro3 replied: Yes! This is so important, we also want to normalize the physical properties to maintain interoperability. This is a drawback of using YAML instead of Python schemas imo, not of what we defined here.
• @lauri-codes said: value is also kind of an interesting case: you need to re-refine it for each subclass (because the units or data type change) and should get an error if you don't define it, as it is part of the interface that all PhysicalProperties should follow.
  @JosePizarro3 replied: Yes, this would be a bit better if value could take Any generic type, shape, unit at the PhysicalProperty level as well. But yes, once someone defines a new inherited PhysicalProperty, they need to overwrite value with the specific type and units (and shape via rank).
• @lauri-codes said: As of now, PhysicalProperty has many Area C specific fields that don't need to be a part of the underlying base class. I would say that if we want to add such a base class to the core package, it should only contain value, rank and variables in the first version. This will simplify the discussions a lot, but also does not stop you from extending the base class to fit your needs.
  @JosePizarro3 replied: I very much disagree with this. Would you mind elaborating? Maybe the only one being specific is the self_consistency_ref and is_scf_converged quantities. Anything else is pretty general.

---

you are welcome to include further thoughts and specifically comment in one of the points if you need further clarification