Open andlaus opened 7 years ago
Well - there might certainly be bugs, but I do not agree with the current analysis. The relevant part of the COPY
statement is:
COPY
...
'SWL' 'ISWL' 1 46 1 112 5 22 /
...
/
i.e. only the layers k ∈ [4,21] are copied. So - the difference between SWL
and ISWL
for the first elements is legitimate. Since the ISWL
is not explicitly assigned to in the deck it will assume default values for the layers k ∈ [0,3].
As I wrote in my previous comment I do not think this is a bug; but of course please elaborate and give more details if you think I misunderstand the case.
I suppose you're right. That said, I'm pretty sure this was not intended by the deck's authors: it makes the endpoints of imbibition and drainage for hysteresis mismatch which is disallowed by the documentation as far as I can remember.
anyway, closing.
I'm pretty sure this was not intended by the deck's authors:
That I don't know of course; but there are no active cells in the top four layers so my hunch is that the original deck authors used some ill-advised assignment saving algorithm.
but there are no active cells in the top four layers
really? the reason I've stumbled over this was that the material laws initialize differently for the second active cell. maybe I have another bug, though...
really?
Ehhh no - sorry; my bad. There are certainly active cells in the four top layers.
When looking at the INIT
file from ECLIPSE the first values of the ISWL
keyword are -100000002004087734272.000 - that could be the sign of some "magic" unitialized value which eclipse makes sensible use of? So - there might still be a bug (or maybe more precisely: not-correctly- implemented-undefined-behavior-in-the-case-of-invalid-user-input)? Feel free to reopen if you feel appropriate - although I think the initial analysis was to simple.
Feel free to reopen if you feel appropriate - although I think the initial analysis was to simple.
ok, I'll reopen it as a reminder. Merry Christmas, too :)
Copy should over write layers 5 to 22, why do you say 4 to 21? ThunderBird Signature File
Regards, David Baxendale Email: David.Baxendale@gmail.com
On 2016-12-24 03:17, Joakim Hove wrote:
Well - there might certainly be bugs, but I do not agree with the current analysis. The relevant part of the |COPY| statement is:
|COPY ... 'SWL' 'ISWL' 1 46 1 112 5 22 / ... / |
i.e. only the layers k ∈ [4,21] are copied. So - the difference between |SWL| and |ISWL| for the first elements is legitimate. Since the |ISWL| is not explicitly assigned to in the deck it will assume default values for the layers k ∈ [0,3].
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OPM/opm-parser/issues/1017#issuecomment-269033914, or mute the thread https://github.com/notifications/unsubscribe-auth/ARIID6mNWKyJrpNfOWTECgt4EgCXYkhKks5rLB4vgaJpZM4LU5V0.
OPM. uses zero offset variables internally - I just did that subtraction upfront.
Joakim,
I'm confused ,the mods should apply to layers 5 to 22 in the user domain, is that equivalent to 4 to 21 in OPM domain? If this was tranmissibility then it would either be 4 to 21 or 6 to 23 depending on the numerical scheme.
Internally, OPM represents layer 1 with numerical zero.
The confusion comes from FORTRAN vs C style indices: FORTRAN (and the ECL file format) uses the indices 1, .., n to access arrays of size n, in C it is 0, ..., n-1. since OPM is written in C(++) and Eclipse in FORTRAN there's this small "impedance mismatch".
Thanks for the clarification. ThunderBird Signature File
Regards, David Baxendale Email: David.Baxendale@gmail.com
On 2016-12-24 16:44, jokva wrote:
Internally, OPM represents layer 1 with numerical zero.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OPM/opm-parser/issues/1017#issuecomment-269075510, or mute the thread https://github.com/notifications/unsubscribe-auth/ARIIDwTifMde4bzloehiMFah8m8OvmnMks5rLNtugaJpZM4LU5V0.
Andreas thanks for the clarification, being an old FORTRAN guy, you can see why I was confused :-) ThunderBird Signature File
Regards, David Baxendale Email: David.Baxendale@gmail.com
On 2016-12-24 17:24, Andreas Lauser wrote:
The confusion comes from FORTRAN vs C style indices: FORTRAN (and the ECL file format) uses the indices 1, .., n to access arrays of size n, in C it is 0, ..., n-1. since OPM is written in C(++) and Eclipse in FORTRAN there's this small "impedance mismatch".
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OPM/opm-parser/issues/1017#issuecomment-269076739, or mute the thread https://github.com/notifications/unsubscribe-auth/ARIID8T6gimgW-7io97RxNBuRpNvujmSks5rLOTVgaJpZM4LU5V0.
edit: although there seems to be a bug related to the property initialization, the initial analysis is not correct. see below: https://github.com/OPM/opm-parser/issues/1017#issuecomment-269038613
The Norne deck from opm-data features the "SWL" and "ISWL" double grid properties and the latter is supposed to be identical to the former because it is copied via the COPY statement on line 342 of the deck's main file. Unfortunately opm-parser currently thinks otherwise: Running the following program on the Norne deck
yields