search

OPM / opm-simulators

Simulator programs and utilities for automatic differentiation.
http://www.opm-project.org
GNU General Public License v3.0
112 stars 122 forks source link

2019-10-RC3 TRANX/TRANY/TRANZ Restart File Bug **Important** #2148

Open OPMUSER opened 4 years ago

OPMUSER commented 4 years ago

There is a problem with the TRANX, TRANY and TRANZ arrays written to the RESTART file. This is a "write" issue as the simulation results are identical with the the previous release.

It looks like TRANY has been set to TRANZ and TRANZ has been set to TRANY.

Test deck attached for reference. MOD01-MULT1-OPM1910-R01.zip

joakim-hove commented 4 years ago

I can look at this.

OPMUSER commented 4 years ago

The riTranX/Y/Z arrays are correct.

The MULTX/Y/Z arrays are missing as well, as well as the MULTPV array

joakim-hove commented 4 years ago

The riTranX/Y/Z arrays are correct.

Ehhh - this I did not understand?

joakim-hove commented 4 years ago

OK - when I look at this I find:

  1. TRANX different from TRANY - I assume they should be ~similar.
  2. TRANZ == 0

Is that the same as you see?

OPMUSER commented 4 years ago

Give me a minute and I'll sent you some pictures.

OPMUSER commented 4 years ago

TRANX and TRANY comparison

MOD01_MULT1_ECL2004_R01_3D_View_TRANX_00_01_Jan_2019

And TRANZ comparison MOD01_MULT1_ECL2004_R01_3D_View_TRANX_00_01_Jan_2019 Does that help?

joakim-hove commented 4 years ago

Does that help?

Yes - left column (correct) is from previous release?

OPMUSER commented 4 years ago

To clarify, the left column is from the commercial simulator so that is correct. When I restored the 2019-04 run, it appears different. In this case TRANX is correct, but TRANY=TRANZ with TRANZ being correct.

OPMUSER commented 4 years ago

This is a 2D cross-section so there is no flow in the y-direction, so TRANY should always be zero.

joakim-hove commented 4 years ago

This is a 2D cross-section so there is no flow in the y-direction, so TRANY should always be zero.

Right!

joakim-hove commented 4 years ago

OK - I have looked through this and think I understand the issue. As you say this an output issue, and not really related to the simulation. It is related to the fact that your domain is 2D (it would be even worse for 1D ...). This has never worked in flow.

I will try to come up with a fix; I don't know it if will be included in the release.

joakim-hove commented 4 years ago

The MULTX/Y/Z arrays are missing as well, as well as the MULTPV array

In flow these arrays are not output to the INIT file unless they are explicitly manipulated in the deck. So for the model you have posted - where the vectors are not explicitly manipulated - it would just be long vectors of 1.0. I really think this is the way it has "always" been in flow - so I don't think you are pointing to regression, but it might very well be a bug. What where you expecting:

  1. MULTX/Y/Z vectors present.
  2. Values different from 1?
OPMUSER commented 4 years ago

For the 2019-04 release the MULTX/Y/Z arrays are not written out when the arrays are absent from the input deck, whereas they are for the commercial simulator (all values set equal to the default value of 1.0). See MOD01-MULT1-OPM1904-R01.zip attached.

When I run a case run with MULTZ set to zero in a layer with 2019-04 we get the same problem, no MULT arrays. See MOD01-MULT1-OPM1904-R02.zip attached. This is the same as 2019-10, but with the previously mentioned TRANX/Y/Z issue.

MOD01-MULT1-OPM1904-R01.zip MOD01-MULT1-OPM1904-R02.zip

I'll set up some 3D cases to confirm this is a domain issue.

OPMUSER commented 4 years ago

I think we may have a bug in the 2019-10RC3 release with respect to the MULTZ keyword in the EDIT section not being applied. The keywords are applied in the 2019-04 release and this is consistent with the commercial simulator.

Here is a comparison for the two 2019 versions: image

And the reason for the difference is because the MULTZ keyword has not been applied in 2019-10RC3, as you can see below: image

Note that TRANZ equals TRANY is a known bug.

Tests decks are attached for reference.

MOD01-MULT1-OPM1910-R05.zip MOD01-MULT1-OPM1904-R05.zip

joakim-hove commented 4 years ago

[... ] When I run a case run with MULTZ set to zero in a layer with 2019-04 we get the same problem, no MULT arrays. See MOD01-MULT1-OPM1904-R02.zip attached. This is the same as 2019-10, but with the previously mentioned TRANX/Y/Z issue.

OK - I have now looked through this in some detail:

MULTXYZ not mentioned in Deck: In this case flow will not save MULTXYZ vectors to the INIT file. That is the way flow has always been. Bug or feature? How interesting is it to write large arrays of ones?

MULTXYZ mentioned in Deck: Current version of flow will not save MULTXYZ to the INIT file - uncertain of previous versions, but this code has changed substantially between the releases, so a change in behavior is not entirely unrealistic. This is certainly a bug.

As far as I am aware there is no keyword configuring exactly what should go to the restart file, so this has traditionally been left to the common sense - or lack thereof - for the developer working with the code. Would be happy to be proven wrong on this point.

I were asked I would say that the 2019.10 release should proceed as planned, even with these issues.

joakim-hove commented 4 years ago

I think we may have a bug in the 2019-10RC3 release with respect to the MULTZ keyword in the EDIT section not being applied. The keywords are applied in the 2019-04 release and this is consistent with the commercial simulator.

Yes - the behavior with MULTZ in the EDIT section has changed. We (@totto82, @alfbr and myself) had a long session working with a model2 realization where the current implementation reproduces the commercial behavior. Reading the manual of the commercial simulator it seems that MULTZ in the EDIT section is borderline undefined behavior - and the recommendation is quite clear to only have MULTZ in the GRID section.

That said the code in question is complex to work with; there might be more issues.

OPMUSER commented 4 years ago

At the moment if the MULTXYZ keywords are in the EDIT section, we get this message:

Warning: The keyword 'MULTZ' is located in the 'EDIT' section where it is invalid
In file /media/sf_D_DRIVE/Linux/OPM/MOD01/MOD01-MULT1-OPM1910-R05.DATA, line 275

If we wish to keep this behavior, can we change the handling to ERROR and stop the run. This will make it clearer to the engineers that there is an issue with input deck. In full field models with lots of messages, the current message can be easily missed. And then the "why are the results different" journey starts :-)

alfbr commented 4 years ago

The message is maybe misleading, I believe flow currently handles MULTZ in the EDIT section correctly, but maybe I am wrong?

OPMUSER commented 4 years ago

May be, but OPM Flow 2019-04 and 2019-10 treatments are different, so that is an issue. See my test cases above.

alfbr commented 4 years ago

I believe the issue is solved in master, but did not make it into the release (so far).

blattms commented 4 years ago

IF this is fixed then please point me to the relevant PR.

alfbr commented 4 years ago

https://github.com/OPM/opm-common/pull/1113

blattms commented 4 years ago

I did backport OPM/opm-common#1113 and wanted to do some tests but I must admit that I am a bit lost. Running MOD01-MULT1-OPM1910-R05 how can I see that the data is as expected (read: what should I visualize with ResInsight and how should it look)?

joakim-hove commented 4 years ago

I am sorry but you can not see any changes in Resinsight - i.e. the output, the PR here only fixed the calculations, and that was done by staring at the simulation results, and not actually the MULTZ.

The MULT? output mentioned in this PR is still buggy:-(

OPMUSER commented 4 years ago

@joakim-hove is correct in terms of the TRANX/Y/Z values, as this is a display issue. However, we can look at the production rates to see if the keyword has been applied correctly, which is I think is what @blattms is after.

The correct behavior is the 2019-04 release, that is the red lines in the plot below.

image

This is based on my graphics program and is based on DISLIN which is unfortunately not open source.

So in ResInsight, you need to load the respective cases and then plot the summary data. Right click on Summary Plots label and select Open Summary Plot Editor, image Select both cases, select Field, and select FOPR. image

Does that help?

OPMUSER commented 4 years ago

The display issue for 2D domains is still in 2019-10RC4 release, so @joakim-hove fix did not make it into the release, correct?

blattms commented 4 years ago

Which fix? I did not see any mention of a fix here despite OPM/opm-common#1113, which is not from Joakim and in the release, and #2150, which is stated to be still buggy, not merged to master, and hence not a candidate for the release. I might have missed the fix, though.

Anyway, fixes coming in now will most probably not make it to the release.

BTW thanks for the helpful description on how to plott. That is very useful and I will try it if I find time.

joakim-hove commented 4 years ago

Which fix?

That is right - there is no existing fix to the display issue.