update reference data for spe9 spe3 multpvv_model2 spe1 spe5 spe9group fetkovich_2d base_model2 spe12p editnnc_model2 ctaquifer_2d_oilwater spe1nowells polymer2d multflt_model2 faults_model_1 base_model_1 wecon_wtest polymer_injectivity multiply_tranxyz_model2 spe1_metric_vfp1 msw_2d_h spe1_foam hysteresis_model2 udq spe12 msw_3d_hfa multregt_model2 polymer_oilwater msw_model_1 swatinit_model2 nnc endscale_model2 multxyz_model2 spe1oilgas spe1thermal

[jenkins4opm]

Reason: OPM/opm-common#979
OPM/opm-simulators#1987

libecl = e2429574117e2f8a9651f8423c00de6d3ef11297
opm-common = e4027b41fc089d66d98066cc6fea331e00f7ddb3
opm-grid = db8ccca0f667b1d37530a8d711a07284e54579b1
opm-material = 77202e291ddc05ebb8fa133d896a25765308b8a9
opm-models = 5bfb639795fd7abbc140d105039346e99ebffb95
opm-simulators = 33f238e38d19cc31f305f838e0cde6cfbc26194b

[atgeirr]

Lots of SMSPEC changes here. Did we have a consensus on what tends to cause those changes?

[akva2]

no. if you hex dump and diff you will see there's a few values near the end that changes. i don't know what those values contains, i tried to ping @tskille but got no response. @GitPaean said it's an old issue re-appearing.

[GitPaean]

Lots of SMSPEC changes here.

It is that all the SMSPEC change here. The old issue is because there is some unnitialized values that are random, it should be fixed. Not knowing what is the cause now.

[joakim-hove]

The old issue is because there is some unnitialized values that are random, it should be fixed.

I (thought) I fixed one such issue in libecl quite some time ago; either that fix was incomplete or this is a new issue. I don't know - if I can get a copy of the files I can take a look.

In general the SMSPEC files have quite a lot of information which is not used; it should of course be correctly initialized, but should not lead to problems in the regression testing either.

[bska]

you will see there's a few values near the end that changes

Aha! That brings a little more light to issue. I converted the current BASE_MODEL_1.SMSPEC file to formatted and the last entry is

 'STARTDAT'           6 'INTE'
           1           1        2000  -693560688       32623 -1190967296

These values are supposed to be a timestamp (day, month, year, hour, minute, second) corresponding to the simulation's start point (essentially a copy of the data in the START keyword), but the hour-minute-second values are clearly uninitialised.

I haven't looked into what we'd need to do to correct the issue, but I'm currently working in this area and I can have a look. Note that @tskille reported this issue in OPM/opm-common#915.

[atgeirr]

I'm currently working in this area and I can have a look.

Does that mean we should not merge this data update?

[bska]

I'm currently working in this area and I can have a look.

Does that mean we should not merge this data update?

No, it does not mean that. It does however mean that we'll have at least one more SMSPEC-related data update coming if we do merge it at this time.

[joakim-hove]

Aha! That brings a little more light to issue. I converted the current BASE_MODEL_1.SMSPEC file to formatted and the last entry is

OK - a fix is here: equinor/resdata#651

[atgeirr]

It does however mean that we'll have at least one more SMSPEC-related data update coming if we do merge it at this time.

I'm fine with that, so I'll merge this set of PRs now to get Jenkins green and move on.

[tskille]

These values are supposed to be a timestamp (day, month, year, hour, minute, second)

the 6th item should be micro seconds (not seconds).

[joakim-hove]

the 6th item should be micro seconds (not seconds).

yes but no - in the context where this comment was written the value is seconds - what is actually written to disk is seconds * 1000000 - which of course still only has seconds resolution; but that is another matter.