Test obs_data_allocE

[dafeda]

Issue
Resolves #2529

Approach
Short description of the approach

[joakim-hove]

The details of the obs_block was originally meant to be an internal implementation detail of obs_data - I would recommend doing the testing fully through the obs_data api.

[dafeda]

Do you mean that I should not test the obs_block_initE function directly, but instead just test obs_data_allocE?

[joakim-hove]

I would do that yes.

[dafeda]

That makes sense, thanks!
I've pushed a fix.

[codecov-commenter]

Codecov Report

Merging #2530 (7d2510d) into main (6e14454) will increase coverage by 0.04%.
The diff coverage is n/a.

❗ Current head 7d2510d differs from pull request most recent head 0c71514. Consider uploading reports for the commit 0c71514 to get more accurate results

@@            Coverage Diff             @@
##             main    #2530      +/-   ##
==========================================
+ Coverage   64.33%   64.37%   +0.04%     
==========================================
  Files         645      645              
  Lines       54318    54323       +5     
  Branches     4538     4538              
==========================================
+ Hits        34947    34973      +26     
+ Misses      18001    17967      -34     
- Partials     1370     1383      +13     

Impacted Files	Coverage Δ
libres/lib/enkf/obs_data.cpp	47.50% <ø> (+12.89%)	⬆️
ert_gui/ertwidgets/validationsupport.py	79.45% <0.00%> (-19.18%)	⬇️
ert_gui/ertwidgets/__init__.py	75.00% <0.00%> (-2.28%)	⬇️
libres/lib/enkf/block_fs_driver.cpp	81.35% <0.00%> (-0.57%)	⬇️
libres/lib/res_util/block_fs.cpp	53.22% <0.00%> (-0.15%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6e14454...0c71514. Read the comment docs.

[BjarneHerland]

An observation: The differences btw linux and mac in this example is surprisingly symmetric. Could it be caused by some indexing-issue instead of actual difference in sequences?

[dafeda]

An observation: The differences btw linux and mac in this example is surprisingly symmetric. Could it be caused by some indexing-issue instead of actual difference in sequences?

Looks like it's because of the way the elements of the matrix E are calculated.

Each element of E is multiplied by a factor.
The factor is a function of the elements of E, which means that it changes together with E and "cancels" out some of the differences in std::normal_distribution.
Why some numbers change sign is I think just due to chance, but I have not looked that deeply into it.

Does that make sense?

Here are the admittedly poorly formatted numbers that go into the calculation of E:

Linux:

E[i, j]: -0.937757 factor: 0.319912 E[i, j] * factor: -0.3
E[i, j]: 0.937757 factor: 0.319912 E[i, j] * factor: 0.3
E[i, j]: -0.959462 factor: 0.521125 E[i, j] * factor: -0.5
E[i, j]: 0.959462 factor: 0.521125 E[i, j] * factor: 0.5
E[i, j]: 0.369076 factor: 0.812841 E[i, j] * factor: 0.3
E[i, j]: -0.369076 factor: 0.812841 E[i, j] * factor: -0.3
E[i, j]: -0.11267 factor: 4.43772 E[i, j] * factor: -0.5
E[i, j]: 0.11267 factor: 4.43772 E[i, j] * factor: 0.5
E[i, j]: -0.204426 factor: 1.46752 E[i, j] * factor: -0.3
E[i, j]: 0.204426 factor: 1.46752 E[i, j] * factor: 0.3
E[i, j]: -0.239391 factor: 2.08863 E[i, j] * factor: -0.5
E[i, j]: 0.239391 factor: 2.08863 E[i, j] * factor: 0.5
E[i, j]: -1.17627 factor: 0.510086 E[i, j] * factor: -0.6
E[i, j]: 1.17627 factor: 0.510086 E[i, j] * factor: 0.6

MacOS:

E[i, j]: 0.914876 factor: 0.327913 E[i, j] * factor: 0.3
E[i, j]: -0.914876 factor: 0.327913 E[i, j] * factor: -0.3
E[i, j]: -0.264962 factor: 1.88706 E[i, j] * factor: -0.5
E[i, j]: 0.264962 factor: 1.88706 E[i, j] * factor: 0.5
E[i, j]: 0.150479 factor: 1.99363 E[i, j] * factor: 0.3
E[i, j]: -0.150479 factor: 1.99363 E[i, j] * factor: -0.3
E[i, j]: -0.0873137 factor: 5.72648 E[i, j] * factor: -0.5
E[i, j]: 0.0873137 factor: 5.72648 E[i, j] * factor: 0.5
E[i, j]: -0.842567 factor: 0.356055 E[i, j] * factor: -0.3
E[i, j]: 0.842567 factor: 0.356055 E[i, j] * factor: 0.3
E[i, j]: 0.295955 factor: 1.68945 E[i, j] * factor: 0.5
E[i, j]: -0.295955 factor: 1.68945 E[i, j] * factor: -0.5
E[i, j]: 0.346664 factor: 1.73078 E[i, j] * factor: 0.6
E[i, j]: -0.346664 factor: 1.73078 E[i, j] * factor: -0.6

[dafeda]

The "symmetry" is a consequence of centering the matrix with only two realizations.

Here's the first part of the calculations done in obs_data_allocE:

nens = 2 # Size of ensemble
nobs = 5 # Number of observations

E = rng.normal(0, 1, size=(nobs, nens))
E - E.mean(axis=1).reshape(nobs, 1)

This results in:

array([[-0.14346748, 0.14346748],
[-0.50043274, 0.50043274],
[ 0.2308551 , -0.2308551 ],
[-0.63106343, 0.63106343],
[-0.9199802 , 0.9199802 ]])

This "symmetry" goes away when using more than two realizations, so I've updated my tests.

[dafeda]

For completeness, here's the rest of the calculation that produces the same results as were used in the test before increasing the number of realizations:

I will put this in the documentation of the test.

E = rng.normal(0, 1, size=(5, 2))
nens = E.shape[1]
nobs = E.shape[0]

E_centered = E - E.mean(axis=1).reshape(nobs, 1)

# Estimate of variance
pert_var = (E_centered * E_centered).sum(axis=1)

obs_block_std = np.array([0.3, 0.5, 0.3, 0.5, 0.6])

factor = obs_block_std.reshape(nobs, 1) * np.sqrt(
    nens / pert_var.reshape(nobs, 1)
)

E_final = E_centered * factor

E_final

array([[ 0.3, -0.3],
[-0.5, 0.5],
[ 0.3, -0.3],
[ 0.5, -0.5],
[ 0.6, -0.6]])

[BjarneHerland]

Apart for the nits, this LGTM.