Open perolavsvendsen opened 3 years ago
Also potentially challenging wrt to relative_file_path
and absolute_file_path
, depending on how these are made under the hood.
Should perhaps be seen in relations to #136. Very different data, but possibly similar implementation.
Refinement 13 jan 2022 @jsorb @jcrivenaes
Requirements
Assumptions
Currently (in x installations):
Proposed input to fmu-dataio:
Initial tests:
Notes from discussion 2022-02-28:
At least two situations to be covered:
1) Metadata exists and is available for a set of input data objects. 1 a) fmu-dataio shall use existing metadata as template for new metadata 1 b) fmu-dataio shall not use existing metadata, build metadata from nothing (through input args as in .export())
2) Metadata does not exist/is not available for a set of input objects.
--> Use existing metadata as input, OR leave it to the aggregation service to handle existing metadata, and provide only key arguments in. From the perspective of fmu-dataio, it will be like generating metadata from nothing.
Is each post-process/pre-process "special" enough to justify separate functionality? Or are "most" generic, with a few special? Or is none special?
Use of existing metadata: Risk of handling metadata logic outside fmu-dataio is that updates to metadata becomes very difficult.
Possibly smart to mitigate conceptual discussion by having context-specific (public) classes in fmu-dataio.
Try to rebuild existing ExportData
to handle also aggregations (and other pre/post-processed data). Under the hood call other methods? Start with writing examples.
When installing in live example, the need for handling aggregated data quickly becomes evident. This is slightly different compared to realizations.
fmu.realization
replaced byfmu.aggregation
which would need input.element_id
must be includedCurrent method is to use existing realization as a template for creating aggregated metadata.
Consider this a placeholder. Needs to be refined and properly described.