Use ies

[joakim-hove]

Approach
On top of: #2412

With this PR the ies_enkf_initX() implementation is used also for the std_enkf module.

Pre review checklist

• Added appropriate labels

[joakim-hove]

This is ready for review.

With this PR the std_enkf module uses the same internal implementation of analysis update as the ies module - i.e. although there are still superficially two modules remaining, there is only one underlying implementation.

[codecov-commenter]

Codecov Report

Merging #2602 (49443d4) into main (de59fc1) will decrease coverage by 0.08%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #2602      +/-   ##
==========================================
- Coverage   65.33%   65.25%   -0.09%     
==========================================
  Files         652      652              
  Lines       53660    53654       -6     
  Branches     4733     4774      +41     
==========================================
- Hits        35060    35010      -50     
- Misses      17067    17086      +19     
- Partials     1533     1558      +25     

Impacted Files	Coverage Δ
libres/lib/analysis/ies/ies.cpp	56.36% <100.00%> (+0.11%)	⬆️
libres/lib/analysis/std_enkf.cpp	57.85% <100.00%> (-1.79%)	⬇️
libres/lib/analysis/update.cpp	34.37% <0.00%> (-8.97%)	⬇️
libres/lib/analysis/enkf_linalg.cpp	40.07% <0.00%> (-6.31%)	⬇️
libres/lib/res_util/matrix.cpp	65.40% <0.00%> (-0.82%)	⬇️
libres/lib/enkf/block_fs_driver.cpp	81.35% <0.00%> (-0.57%)	⬇️
res/fm/templating/template_render.py	84.00% <0.00%> (-0.32%)	⬇️
res/enkf/__init__.py	100.00% <0.00%> (ø)
libres/lib/python/init.cpp	0.00% <0.00%> (ø)
... and 11 more

---

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 de59fc1...49443d4. Read the comment docs.

[dafeda]

What do you think of adding a docstring to this in Doxygen format, something like:

/**
 * @brief 
 * 
 * @param ies_config 
 * @param S 
 * @param R 
 * @param E 
 * @param D 
 * @param X 
 */

[joakim-hove]

Personally I think Doxygen means "old and irrelevant" - so I would prefer not to.

[dafeda]

Which format of docstrings do you prefer?

[joakim-hove]

My general attitude is that I am skeptical to documentation strings, because I feel they very often are stale and irrelevant[1]. The formatted strings (typically doxygen) even more so, because I suspect the guy inserting that comment used a shortcut in his editor with thinking much about it - i.e. it screams: "Comment without love".

My preferred way to handle comments is that when something is really complex/broken/.... and I see no obvious way to improve the problem away I write a comment. The comment can be quite extensive, it is in free form and typically for developers actually working with the problematic code - i.e. in the .cpp file. In addition to the text in the comment the mere fact that I have actually added a comment should signal "here be dragons" for the pour soul coming after me.

But I am pushing 50 and have no spine left - will do as encouraged.

[1]: Due to pydoc I do feel quite different about this in Python - here the comments/document strings are available to a much larger audience and it feels meaningful to write them.

[dafeda]

My general attitude is that I am skeptical to documentation strings, because I feel they very often are stale and irrelevant[1]. The formatted strings (typically doxygen) even more so, because I suspect the guy inserting that comment used a shortcut in his editor with thinking much about it - i.e. it screams: "Comment without love".

The staleness is in my opinion due to docstrings containing too much detail.
In this specific case I would write that initX is equivalent to a standard EnKF implementation but that it uses an iterative ensemble smoother under the hood or something like that.

My preferred way to handle comments is that when something is really complex/broken/.... and I see no obvious way to improve the problem away I write a comment. The comment can be quite extensive, it is in free form and typically for developers actually working with the problematic code - i.e. in the .cpp file. In addition to the text in the comment the mere fact that I have actually added a comment should signal "here be dragons" for the pour soul coming after me.

I think this is fine, but should ideally be dealt with fast.
In other words, such comments should not grow old, which they often do.

But I am pushing 50 and have no spine left - will do as encouraged.

The spine hardens with age!

[joakim-hove]

I have added a comment which I am happy with.

[joakim-hove]

In this specific case I would write that initX is equivalent to a standard EnKF implementation but that it uses an iterative ensemble smoother under the hood or something like that.

Well - that is actually wrong. It uses the standard EnKF implementation which is an internal part of the iterated algorithm. But that aside: I think your comment illustrates an interesting point, when writing comments we feel inclined to document the journey we have completed - that is not really interesting to someone coming after us. When this PR is merged the initX() routine will be the enkf routine.

[dafeda]

In this specific case I would write that initX is equivalent to a standard EnKF implementation but that it uses an iterative ensemble smoother under the hood or something like that.

Well - that is actually wrong.
It uses the standard EnKF implementation which is an internal part of the iterated algorithm. But that aside: I think your comment illustrates an interesting point, when writing comments we feel inclined to document the journey we have completed - that is not really interesting to someone coming after us.

I thought that the iterated algorithm was for the case when the posterior is not Gaussian and when predictions and state vectors were non-linearly related.
That is, I thought the iterated algorithm made fewer assumptions than EnKF.
In any case, the journey completed provides context which is of great importance to those coming after us IMO.

[joakim-hove]

I thought that the iterated algorithm was for the case when the posterior is not Gaussian and when predictions and state vectors were non-linearly related.
That is, I thought the iterated algorithm made fewer assumptions than EnKF.

Both the EnKF and iterated are for the nonlinear case, however the iterated makes smaller steps - i.e. less severe effects of nonlinearity.

In any case, the journey completed provides context which is of great importance to those coming after us IMO.

Here we disagree - or at least I think this will lead to very much comments.

[joakim-hove]

Have updated the comment in the .hpp slightly and added a more verbose comment in the .cpp file

[dafeda]

LGTM 👍