Open timofeymukha opened 6 months ago
Treat the review request mostly as request for attention :-).
By the way, one consequence of this is that one can of course have several simcomps of the "scalar" type, so it in its own way provides multiple scalar capability. Perhaps not computationally ideal, but for 2-3 scalars probably fine. Need a bit more flexibility for it to work though: the field name should be selectable and there needs to be better handling of checkpointing I suppose (not attached to fluid
)
I like this PR, especially since it in principle adds support for several scalars (while not computationally perfect). The same would be true if we extend to Fluid, e.g. neknek would become more or less trivial.
Dow we all agree that "everything as simcomp" is a good direction to go? If so I think we should perhaps just go for it, starting with the scalar.
@timofeymukha Should we keep this for the 0.8 release?
@timofeymukha Should we keep this for the 0.8 release?
Could be a bit ambitions for May, not sure. This is already in pretty deep merge hell :-).
@timofeymukha Should we keep this for the 0.8 release?
Could be a bit ambitions for May, not sure. This is already in pretty deep merge hell :-).
Fair enough, then we push it to 0.9
This PR currently has a working preview of a scalar simulation component. Feel free to play around :-).
Some points
case.material_properties
. This is not very pretty right now, as wrong output is given to the log in the beginning. Will be fixed.I guess it is still somewhat an open question if we want to go this way. I like it, but one does need to realize that the burden of getting the order of simcomps is on the user here. For example, the probes simcomp crashed for me because it tried to find the "s" field during init, and it was init before the scalar :-). We have an
order
parameter, to deal with this, but the crashes one gets are difficult to understand as a user. Perhaps, there can still be some guards implemented, but I don't think we can get all possible combos.Another question I have is regarding gs and coef. Scalar takes the from fluid, but I would like to separate the two. I guess creating and extra gs and coef is not a very good option? Should these be moved up to
case
, perhaps? Almost everything relies on coef in general, so if fluid will be non-obligatory, I feel like we need to have coef elsewhere.Lastly, I am pondering on whether scalar_scheme should deal with json parsing or that should all be done in the simcomp. If so, we will need to pass more stuff to the constructor. The main barrier is that some stuff has to be passed as json anyway, particularly, the
source_terms
object, which is then used to init thescalar_source_term
component of thescheme
. So maybe one just pass the whole json anyway...