ConnectionSetRepresentation

FESAPI
1

Hi,
Apologies if this is not the right place to ask the question, but I was looking through the FesAPI for ConnectionSetRepresentation and I notice there is no API to “set grid index pairs”, but there is an API to “get the grid index pairs”. Does this mean that the “cell index” in cell index pairs refers to a global cell index (from which a grid index can be deduced given a starting cell ID, for e.g.?), in order to correctly handle the case with multiple grids associated with a given connection set representation? I recall that the API for older versions of RESQML required setting the grid index pairs as well (explicitly), and had an optional argument to specify grid index pairs in the API to set cell index pairs.
Thanks,
-Sunil

2

Hi Sunil,

Is the method
void setCellIndexPairs(const ULONG64 & cellIndexPairCount, ULONG64 * cellIndexPair, const LONG64 & nullValue, COMMON_NS::AbstractHdfProxy * proxy, ULONG64 * gridIndexPair = nullptr);
not working?
You can find this method in https://github.com/F2I-Consulting/fesapi/blob/master/src/resqml2/GridConnectionSetRepresentation.h

As you can notice, the last (default) parameter of this method allows you to set grid index pairs.

3

OK, sorry I didn’t clarify that this was in the C# binding. There there is no option to supply the last (default) parameter.

4

It should also be available on C# because this method is listed in fesapi/swigResqml2Include.i at master · F2I-Consulting/fesapi · GitHub
On my computer, I have this method in fesapi\cs\src\resqml2\GridConnectionSetRepresentation.cs

image
image1875×165 23.3 KB

Can you double check that :

  • you have the right method listed in fesapi/swig/swigResqml2Include.i
  • there is no error when swig is operated
  • have not the right method in fesapi\cs\src\resqml2\GridConnectionSetRepresentation.cs
5

Thanks Philippe,
I think we may be using outdated Fesapi code, so I will update later and confirm with you. But I have a couple of more questions regarding the GridConnectionSetRepresentation API.

Is it required to push back “supporting grid representations”? The reason I ask is that it is possible that one or more (indeed, several) connections occur between different grids (and consequently different grid representations). We anyway provide this in the gridIndexPair argument of the setCellIndexPairs() function, so it appears redundant, no? So in this case, what is the relevance of pushing back (supporting) grid representations? Regardless, do we still have to push back all the supporting grid representations from which the connections are established? What if we pushed back more supporting grid representations than required and say, there are no connection contributions from one of the grids? Does this render the GridConnectionSetRepresentation invalid?

Also the grid index is simply the index of the grid representation following the order in which they have been created in the EPC, am I right?

6

I guess one more minor comment is that it would be useful to have an overloaded API in the future, to load gridIndexPairs as UINT16 (shorts), since in the vast majority of use cases, we have only grid representations numbering in the single digits, and yet, for such cases, if we have millions of connections (which we almost always do), we still have to specify that many gridIndexPairs, which can be be wasteful on memory.

7

OK for support of gridIndexPairs as UINT16 (shorts).
I created an issue to trace this demand : https://github.com/F2I-Consulting/fesapi/issues/61

8

Here, what you provide is grid indices, not the grid representations.

To provide the grid representations (not only their indices, their idenitfiers) which are involved into the grid connection set representation.

The grid index is the index of the grid representation following the order in which they have been push backed (as supporting grid representations) into the grid connection set representation.

This is more a question for the RESQML standard itself (i.e. Energistics), not for one of its implementation.
I would personaly answer/guess/bet :

  • yes
  • readers would ignore the unused grid supporting representation
  • no
9

How about also cell indices in the cell index pairs? Should these refer to the actual index of the cell in the subdomain in question, in the order in which they’ve been stored (e.g., in property data), or should it refer to the “expanded subdomain cell index” which accounts also for gaps due to, say, inactive, and dead cells?

I have also one more question about ordering the data. There is a comment in the API setCellIndexPairs for this argument which states “All the cell index pair in a 1d Array where the cell indices go faster than the pair.” I am not sure I fully understand, so let’s suppose we have 2 connections with cell indices for the 1st connection being c1_1, c1_2 and cell indices for the second being c2_1, c2_2; then right now I am ordering it as {c1_1, c1_2, c2_1, c2_2}. I wonder if it should be ordered as {c1_1, c2_1, c1_2, c2_2}?

10

This is the cell index in the domain of the corresponding supporting representation.
For instance, if your supporting representation is a IJKGridRep, then the cell indices are first I, then J then K (as cell property values are ordered).
If your supporting representation is an unstructuredGridRep, then the cell indices follow the indexing of the unstructuredGridRep cells.
etc…

{c1_1, c1_2, c2_1, c2_2 is fine.

11

Thanks, yes, I was able to test it out last evening with those interpretations (as you described exactly) and it worked well with the flow simulator and gives identical result as the equivalent case with non-RESQML bulk data formats.