Closed timofeymukha closed 6 months ago
The reason for fluid_output
types was to avoid circular dependencies. With the new case and solver design, maybe this is not an issue anymore
fld_file_output_t
resolves this. But we should keep in mind that accessing the sampler is not very easy now, you need the case
. simcomps have it, but pretty much nothing else.
Our output works by adding additional
output_t
objects to thesampler_t
, which sits inside thecase
. Theoutput_t
type is abstract, so for a new output you actually need to create a descendent. Currently, we have afluid_output_t
type, which outputs the fluid and scalar stuff, and supports putting additional fields into the resulting .fld file. For example, the lambda2 simcomp uses that and adds its field to the output.The issue right now is that it is not easy to output some field to a seprate .fld file, because you will need to create another child type
output_t
for that purpose. What I propose is that we repurpose thefluid_output_t
type to be a generic .fld field output. Essentially, the only thing that needs to be changed is the automatic addition of the fluid and scalar fields. This bit in the constructor has to goInstead, fluid and scalar will add their fields "manually" to the sampled field list, just like lamdbda2 does right now. This way, to create a new .fld file one could use this output type and fill the field list with whatever one wants. This would incidentally also make it much more sensible that we have such an output object that sits inside the
case
, rather than thefluid
(as the namefluid_output
would hint). It will be a generic fld output bucket.