Meta data for well-tracer-alias-table

[ingunnr]

DynaGeo would like compare real tracer observations with simulated tracer response between wells. To be able to do that, we need information on eclipse well names and trancer names and link them to UID well name and tracer name.

This could for instance be achieved by exporting a table from FMU listing well names, tracer names, eclipse well names and eclipse tracer names and upload this file to Sumo.

As previously discussed (@perolavsvendsen and @jcrivenaes), we are open for other solutions for identifying and storing this information in Sumo, e.g. having the information in global variables . The main goal is to be able to find this information via Sumo.

[perolavsvendsen]

#339 attempts to enable transfer of metadata from global_variables.yml into case metadata. However I suspect that the data you are referring to are not part of global_variables.yml (?) - or that they are generated during the FMU-run (in that case, we cannot put them into case metadata).

If this is a standardized part of global_variables.yml it will perhaps be easier.

[ingunnr]

@perolavsvendsen, you are correct. The information on well names and tracer names is not part of global variable today. It is being generated as part of the FMU workflow. However, if it is better to move it into global variables, please let us know, so that we can agree upon a solution.

[perolavsvendsen]

For (meta)data produced during the run itself, it cannot be placed in the case metadata (the case metadata are made before any of the realizations start). But is it safe to assume that they are static through all the realizations? (They don't differ between individual realizations)

Where are the data existing today?

[kjerh]

Currently the data is stored as a .csv-file under <revision>/rms/input/well_modelling/well_info/Tracer_well_conversion_table.csv
And it is uploaded using:
<revision>/ert/bin/jobs/FM_EXPORT_TRACER_ALIASES
and
<revision>/ert/bin/scripts/export_tracer_alias.py

[perolavsvendsen]

OK, does the forward job alter the data in any way? Or is it just transporting the data to the runpath/scratch?

[kjerh]

No, the data is not altered, just transferred to scratch/ and uploaded to sumo, so that we can use the conversion table to link historical data to simulated data in Dynageo.

[perolavsvendsen]

OK but in that case, it should be possible to fetch the original data and include it somehow into case metadata when running an FMU case. There is a proposal for a first step of this in #339, which introduces functionality for getting specific elements from global_variables.yml into case metadata.

Either, these data can be placed into global_variables.yml if that makes sense, and then we can relatively easily fetch them from there - or we have to expand fmu-dataio to also read other files from the template, parse them, and include their contents in case metadata. The latter may be a slightly longer way, as it requires much more coordination and discussions so that we avoid doing something that becomes unmanageable or unstable.