-
Notifications
You must be signed in to change notification settings - Fork 104
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
Remove enkf_obs instance from local_obsdata #3046
Conversation
Codecov Report
@@ Coverage Diff @@
## main #3046 +/- ##
==========================================
+ Coverage 65.37% 65.49% +0.12%
==========================================
Files 641 641
Lines 50733 50623 -110
Branches 4462 4440 -22
==========================================
- Hits 33167 33158 -9
+ Misses 16066 15971 -95
+ Partials 1500 1494 -6
Continue to review full report at Codecov.
|
aca0f16
to
0815af5
Compare
Cool if someone can take a peek on the failing Equinor tests. |
test ert please |
9db0864
to
fce4e73
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The C / C++ implementation of local_obs_data does not have any knowledge of the true set of observations in an enkf_obs instance; i.e. you can in principle add a local observation with an unknown key. This is probably a user error - which will go undetected, but not fatal as such - the unknown key will just be dangling and not used for anything.
Should be fine, we could do some validation up front, and probably make it fail if unknown keys are included when we run.
In the Python implementation LocalObsData we have attached a reference to the enkf_obs instance while constructing the LocalObsData - the purpose of this has been to be able to input check the keys provided by user.
Agree that this is not the best way to do it, did you check if the existing functionality is used in semeio
? Not a problem if it is, just need to update after this is merged.
The PR in itself looks good, some comments regarding the tests.
from res.enkf.active_list import ActiveList | ||
|
||
|
||
class LocalObsDataTest(ResTest): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dont use ResTest
unless you need any of those features, here unittest.TestCase
will do the same job. Personally I would rewrite it to pytest
, but not required.
No I have not checked that. |
c8885c8
to
ea661be
Compare
Ok - I have applied your patch (thank you), and addressed the other comments. |
ea661be
to
23f4823
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Though could you also add a summary of this:
The C / C++ implementation of local_obs_data does not have any knowledge of the true set of observations in an enkf_obs instance; i.e. you can in principle add a local observation with an unknown key. This is probably a user error - which will go undetected, but not fatal as such - the unknown key will just be dangling and not used for anything.
In the Python implementation LocalObsData we have attached a reference to the enkf_obs instance while constructing the LocalObsData - the purpose of this has been to be able to input check the keys provided by user.
in the commit body? Would be good to have for posterity.
23f4823
to
99305d3
Compare
The C implementation of local_obsdata has no knowledge of the complete set of observation keys; it is therefor quite simple to create a local observation node with an invalid observation key. The observation node corresponding to the invalid node will be dangling - no real harm. In Python we previously we attached a enkf_obs instance to the local_obs instance, in order to be able to validate keys provided by the user. With this PR that 'pimping' of the Python class is removed. This is in preparation to upcoming C++ / pybing refactoring, where there is only the C++ class and not a separate wrapper class in Python.
99305d3
to
1be4566
Compare
done! |
test required please |
Add test to
LocalObsData
. Followup of this comment from #2966This PR contains some test-code which should be in place before #2966 is merged.
NB: The first commit is a change of behavior (it is also in #2966, but pulled out here to make it more explicit). The situation is:
local_obs_data
does not have any knowledge of the true set of observations in anenkf_obs
instance; i.e. you can in principle add a local observation with an unknown key. This is probably a user error - which will go undetected, but not fatal as such - the unknown key will just be dangling and not used for anything.LocalObsData
we have attached a reference to theenkf_obs
instance while constructing theLocalObsData
- the purpose of this has been to be able to input check the keys provided by user.When switching to pybind we do not any longer have separate C and Python implementations - it is all in C++; it is not therefor natural[1] to pimp the python class with respect to the C++ implementation, I therefor suggest to remove this pimping here as a preparation for merging #2966.
[1]: Yes - it would of course still be possible; but in my opinion not worth it. Some of the user control will be recovered when the localisation is completed with #2981. Furthermore it should be noted that the
local_config
object is decorated with observations, ensemble configuration and grid in Python in the same as described here.