-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify implementation of fmu.context #592
Comments
I did a bit of digging to see how we treat the The option can only be used in ERT forward model setting.
In order to get this behaviour we run extraction of filepaths twice in the
Then after the export to case/share we check if Main problems I see with this option is:
I highly recommend to remove this as a valid option to the Any objections to removing this option @perolavsvendsen @jcrivenaes ? |
Surely the intention could never have been that multiple processes inside realizations should write to something under Anyways, yes, sounds like it should definitely be removed as a valid option for |
No probably not 🙂 and if we were to continue with the option we could change to only export if it is not already present when running with this fmu_context. and we could change the fmu.context.stage in the metadata so that it is valid. |
Based on discussions 10/4-2024 @tnatt @jcrivenaes @HansKallekleiv
Current implementation/handling of
context
is cumbersome, and somewhat complicated (for many reasons).Related issues/tasks:
The FMU block of the metadata
These are the principles
There is implicit logic embedded in this, e.g. "if
iteration
and notrealization
then data is on iteration level". However, embedding such logic in all consumers would be cumbersome. Therefore, we mirror this logic infmu.context
:Suggested tasks
The text was updated successfully, but these errors were encountered: