[Opm] Problem with WELDIMS

Mon Feb 10 22:14:08 UTC 2020

Hi Karl,

Sorry about the delay.  Indeed, this behaviour is fairly new.  It came about as a result of our ongoing effort to create ECLIPSE-compatible restart files.  Earlier, and in particular in releases prior to 2019.04, we did not pay attention to the size and content requirements of certain restart file arrays.  In later releases we do attempt to create output files that compatible with ECLIPSE where possible and then we run into additional restrictions.

As a practical matter, If you don't plan on restarting ECLIPSE from a base run in Flow you can typically ignore those restrictions.  In that case you typically don't need the strict WELLDIMS parsing.  Off the top of my head I don't recall exactly how to turn it off, but the relevant keys are

    RUNSPEC_*

Joakim Hove is the project's expert on how to tune those parser settings.

Regards,

Bård Skaflestad
SINTEF Digital, Mathematics & Cybernetics
Computational Geosciences group

-----Original Message-----
From: Stephen, Karl D <K.D.Stephen at hw.ac.uk> 
Sent: Saturday, February 8, 2020 10:39 AM
To: Bård Skaflestad <Bard.Skaflestad at sintef.no>; opm at opm-project.org
Subject: RE: Problem with WELDIMS

Thank you Bård. That does make sense from how you explain it.

I admit I am looking at flow through my Eclipse glasses but this must be a new feature as my model worked on the 18.10 version.

Regards,
Karl

-----Original Message-----
From: Bård Skaflestad <Bard.Skaflestad at sintef.no> 
Sent: 07 February 2020 19:07
To: Stephen, Karl D <K.D.Stephen at hw.ac.uk>; opm at opm-project.org
Subject: RE: Problem with WELDIMS

Hi,

In this case the manual is somewhat incomplete or possibly misleading.  Item 4 of WELLDIMS really is both the maximum number of wells in a group *and* the maximum number of child groups in a group.  The first applies to groups that "own"/contain wells and the latter applies to groups that "own"/contain other groups.

On the other hand, in your case all groups other than the implicit FIELD group contain exactly one child item so in this case it's only the FIELD group that happens to have two child items.  I suppose FIELD could be treated as a special case (e.g., by inferring the maximum size from the declared maximum number of groups in the run), but then outputting group-related results will be more complicated.  The output protocol requires that each group records its child groups (or contained wells) in an integer array and that array has to be sized according to the maximum group size (number of child wells or child groups).

I hope this helps.  In the short term we're not going to be able to change this, so I suggest raising the fourth item of WELLDIMS in this model.

Regards,

Bård Skaflestad

SINTEF Digital, Mathematics & Cybernetics Computational Geosciences group

-----Original Message-----
From: Opm <opm-bounces at opm-project.org> On Behalf Of Stephen, Karl D
Sent: Tuesday, February 4, 2020 10:05 AM
To: opm at opm-project.org
Subject: [Opm] Problem with WELDIMS

Hi,
Has the usage of WELDIMS changed in the recent version of flow?

I have a simple quarter 5 spot model where injector, "INJ", is placed on one corner and producer "PROD" on the other of a square model (5 x 5 x 3 cells).
PROD is added to group G1 and INJ is added to group G2 in WELLSPECS. Both wells are completed vertically over the three layers.

I would expect WELLDIMS to be set up as:

-- Maximum well/connection/group values
--     #wells  #cons/w  #grps  #wells/grp
--     ------  -------  -----  ----------
WELLDIMS
         2       3         2       1  /

When WELLSPECS and COMPDAT are:
-- Location of wellhead and pressure gauge
--      Well  Well   Location   BHP    Pref.
--      name  group   I    J   datum   phase
--     -----  ----    -    -   -----   -----
WELSPECS
        PROD   G1     1    1    8000    OIL  /
        INJ    G2     5    5    8000    WATER /
/
-- Completion interval
--      Well   Location  Interval  Status           Well
--      name    I    J    K1  K2   O or S            ID
--      ----    -    -    --  --   ------          ------
COMPDAT
        PROD    1    1     1   3      OPEN     2*      0.667  /
       INJ     5    5     1   3      OPEN     2*      0.667  /
/

This is what worked in the previous version of flow that I ran (18.10) and in ECLIPSE. I still have 18.10 installed on a virtual machine.

Now I get the error message:
Error: Run uses maximum group size of 2, but allocates at most 1 in RUNSPEC section.  Increase item 4 of WELLDIMS accordingly.
Failed to create valid EclipseState object.
Exception caught: RUNSPEC_GROUPSIZE_TOO_LARGE: Run uses maximum group size of 2, but allocates at most 1 in RUNSPEC section.  Increase item 4 of WELLDIMS accordingly.

All is fine if I set the fourth item of WELDIMS to 2 for the number of groups but it should be possible to set it to 1 as there is one well per group.

Is this a bug? The latest manual for 19.10 states that the 4th item is the "maximum number of wells that can belong to a group".

It seems as if MXGRPS and MXGRPW are being confused?

Regards,
Karl
________________________________

Founded in 1821, Heriot-Watt is a leader in ideas and solutions. With campuses and students across the entire globe we span the world, delivering innovation and educational excellence in business, engineering, design and the physical, social and life sciences. This email is generated from the Heriot-Watt University Group, which includes:

  1.  Heriot-Watt University, a Scottish charity registered under number SC000278
  2.  Heriot- Watt Services Limited (Oriam), Scotland's national performance centre for sport. Heriot-Watt Services Limited is a private limited company registered is Scotland with registered number SC271030 and registered office at Research & Enterprise Services Heriot-Watt University, Riccarton, Edinburgh, EH14 4AS.

The contents (including any attachments) are confidential. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system.
_______________________________________________
Opm mailing list
Opm at opm-project.org
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopm-project.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopm&data=02%7C01%7CBard.Skaflestad%40sintef.no%7Ccd807d1657bc4df91c5308d7acb58171%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C0%7C637167767878809760&sdata=0IfpAjJ5LXdA6qBOzfpWBTXovT%2F8t%2FiBaT73TGsCJKo%3D&reserved=0