Responses&observation handling could be more flexible

[yngve-sk]

Responses&observation handling could be more flexible

[dafeda]

"This opens up for adding custom response & observation types to ert, which can make it easier for users to specify responses/observations into ert, potentially (very likely) also with a lot less associations between multiple files."

Mind elaborating a bit here? What do you mean by custom response and observation types?

[yngve-sk]

Sure, most obvious example would be a specifying some observations as a CSV, either giving the name of the response explicitly in the ert config, or giving just the file and expecting it to contain a column with the response name/key for each observation. So one kind of custom observation type would be something that reads in from that CSV and matches it up to the correct responses so that they show up in the observations_and_responses matrix.

Each response has a "lifecycle" that you can hook into as a "response developer"
0. The "response developer" specifies which keywords it should add to the ert config grammar, so that they show up in the next step of the lifecycle: from_config_list

1. It is entered into the ert config by the user, the "response developer" writes the logic of how that line is turned into a response config, the ert config line is sent to .from_config_list
2. User runs ert forward model, ert puts stuff in runpath, for each realization we call .parse_response_from_config, which basically moves/transforms the data from the runpath to storage.

Beyond that, for each response/observation we specify a primary_key / join key / whatever it should be called, and this key is the only thing storage needs to know.