Assumptions regarding ERT environment variables are wrong

[tnatt]

Our assumptions regarding when ERT environment variables are present are wrong

	This is our current assumption	This is the actual implementation by ERT #4904
On client	_ERT_EXPERIMENT_ID _ERT_ENSEMBLE_ID _ERT_SIMULATION_MODE	_ERT_EXPERIMENT_ID _ERT_ENSEMBLE_ID _ERT_SIMULATION_MODE
On compute node forward model	_ERT_EXPERIMENT_ID _ERT_ENSEMBLE_ID _ERT_SIMULATION_MODE _ERT_RUNPATH _ERT_ITERATION_NUMBER _ERT_REALIZATION_NUMBER	_ERT_RUNPATH _ERT_ITERATION_NUMBER _ERT_REALIZATION_NUMBER

Hence these lines in the FmuProvider will leave the fmu metadata empty when running a forward model (Note: except for ERT test_run):

fmu-dataio/src/fmu/dataio/providers/_fmu.py

Lines 122 to 126 in 6ba4b49

	if not FmuEnv.ENSEMBLE_ID.value:
	logger.debug(
	"No ERT environment variables detected, provider will be empty"
	)
	return # not an FMU run

This has gone a bit undetected because:

• This change was introduced in version 2.1.0 which has not been released
• an older version of dataio is used inside RMS when running bleeding
• data exported in fmu_context="case" are ok
• we recently started validating our metadata with pydantic which made it easier to detect.. before it would just be rejected by Sumo
• In ERT test_run (single realization run) all six environment variables are present. The fmu-sumo-uploader was tested nightly on a drogon run, but it did not fail since it was run as a test_run
• Drogon data only includes metadata export as fmu_context="case" or from RMS. Hence nothing fails.. except the automatic upload of parameters from the SUMO_UPLOADER, but since it is wrapped in a try/except it was not very visible.

Good thing is! This will be fixed by the changes introduced in the PR #599, as the logic was refactored there 👍
But we need to:

• Go through our tests to see that we are mocking the environment correctly
• Add ERT integration tests to detect these things. As mentioned in Include context in integration test #588
• Update Drogon dataset to include export jobs from forward models outside RMS

[perolavsvendsen]

Very nicely debugged. I guess this was a trap we had to fall in eventually. Key learning here is that it causes some problems when the test-run option is used (Single Realization test-run in GUI), as it is running on the (RGS) client, not the compute node. So, in that particular context, you have both:

ERT mode	On client	On Compute node
workflow	_ERT_EXPERIMENT_ID _ERT_ENSEMBLE_ID _ERT_SIMULATION_MODE	N/A
test-run (forward model)	_ERT_EXPERIMENT_ID _ERT_ENSEMBLE_ID _ERT_SIMULATION_MODE _ERT_RUNPATH _ERT_ITERATION_NUMBER _ERT_REALIZATION_NUMBER	N/A
ensemble experiment (forward model)	N/A	_ERT_RUNPATH _ERT_ITERATION_NUMBER _ERT_REALIZATION_NUMBER

So logic has to be on the absence AND presence of something, I guess, rather than just on the presence of something.

[perolavsvendsen]

@tnatt this can be closed?

[tnatt]

Yes, should be fine to close this now.
I don't know if ert yet has fixed it so that all ERT variables are available in the compute node.. but the logic we have implemented is not dependent on it.

We have yet to set up an ERT integration tests to detect these things, but we have a separate issue for it #588.
Also I made an issue in fmu-drogon enable dataio on grid3d-maps to have export jobs outside of RMS https://github.com/equinor/fmu-drogon/issues/242