neko icon indicating copy to clipboard operation
neko copied to clipboard

More flexible material property storage

Open timofeymukha opened this issue 1 year ago • 2 comments

We have a very simple type for material properties now, that basically stores the rho, mu, cp and lambda. Once we have more than one scalar, this does not really work out. Furthermore, right now the material_properties type parses the material properties in the case file and then we pass this object to the schemes. However, if we adopt a "everything is a simcomp" it will probably be a reversed relationship, as currently seen in PR #1129 . So we basically need a way for a simcomp to add the properties to the material_properties type, which will then act as a database.

One way could be using a json_file object. Each scheme could then add a subobject with the appropriate subcomponents giving something like

{
"fluid" : {"rho": 1, "mu": 1e-6},
"temperature" : {"cp": 1, "lambda": 1e-2},
}

However, we don't really use json_file for anything but the parameter file and its bits. Are we fine with further extending its use to store runtime generated data?

timofeymukha avatar Feb 08 '24 13:02 timofeymukha