Open timofeymukha opened 6 months ago
My only concern is if we need to traverse the json object each time wee ned to retrieve e.g. $\lambda$, otherwise it's nice if it describes the case, even at runtime
Should happen when "communication" between simcomps is necessary, I guess, e.g. for the scalar to get the fluid's density. Afterwards it is stored in the scheme
. Then again this whole thing totally breaks if density e.g. becomes variable, so a field :-). Maybe we don't need this broker material_properties type at all. One needs to give some thought on how simcomps "communicate" with each other.
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
scheme
s. 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
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?