Make everest-models independent of the wells section

[verveerpj]

A number of forward models make use of the wells.json file that is generated by Everest. Long-term goal is to remove Everest creating this file. We need to make an inventory of all jobs to clarify if and how they use wells.json. Based on that we can decide how to change those jobs if necessary.

[verveerpj]

This table summarizes which forward models accept a json file in the format generated by the wells section, by using the add_wells_input_argument function. So they have something like -i flag to read wells.json.

Some models clearly need the information from the wells section, such as the drill planner jobs. These should gain an option to give that information in their config (i.e. drill_time). For now, they should probably just keep the argument, so they can still be used with input generated by other jobs.

Others are less clear, looking at the tutorials some are used as a first step in the tutorials, so these would need to get the info from their config, if we remove the wells section. However, if such a job is only used very occasionally in that way, it may also be acceptable to have the user generate and install a wells.json file to replace the wells section.

Forward model	Comments	Add to config?	Used as first job?
fm_add_templates	Uses add_wells_input_argument	No	Yes
fm_compute_economics
fm_drill_date_planner	Uses add_wells_input_argument, needs drill_time	Yes	Yes
fm_drill_planner	Uses add_wells_input_argument, needs drill_time	Yes	Yes
fm_extract_summary_data	-	-	-
fm_interpret_well_drill	-	-	Job to be deprecated
fm_npv	Uses add_wells_input_argument	No	No
fm_rf	-	-	-
fm_schmerge	Uses add_wells_input_argument	No	No
fm_select_wells	Uses add_wells_input_argument	No	No
fm_stea	-	-	-
fm_strip_dates	-	-	-
fm_well_constraints	Uses add_wells_input_argument, needs readydate	Yes	Yes
fm_well_filter	Uses add_wells_input_argument	No	Job to be deprecated
fm_well_swapping	Uses add_wells_input_argument	Check if only need well names, read those from controls JSON	Yes
fm_well_trajectory	-	-	-

[verveerpj]

@slawekszklarz : can you maybe have a look at the table above? It would be good to know which forward models should really have the wells info added to their config. It is clear that the two drill planner must be changed. well_swapping may need it if I understand the tutorial correctly, but maybe I am wrong. The others are unclear to me.

Maybe you can add some info to the table, especially the third column?

[verveerpj]

Another thought: if there are jobs that only need the names of the well as input, maybe they can be changed to just read the files with control values that Everest writes.

[verveerpj]

@slawekszklarz It seems that fm_well_constraints needs a readydate field in the wells.json it reads, so that must be produced by another forward model. Could that be?

[slawekszklarz]

Indeed, fm_well_constraints requires readydate. Currently, when fm_well_constriants is used as a first job then the JSON file with readydates is provided by a user with install_data. See tutorial.

I propose to add readydate to input config YAML (-c/--config) and use it in case there is no readydate for a well in JSON file (or no JSON file argument at all). This still allows to combine this job with earlier jobs optionally.