Fesapi 0.13.0 Linux strange behavior

FESAPI
1

Hi, I am using Fesapi 0.13.0 (somewhat recently updated) on both Windows and Linux. I am exporting RESQML EPC for two separate use case scenarios: (1) an AbstractIjkGridRepresentation with one associated grid property (cell IDs) and (2) the same as above and additionally I also export associated faults with corresponding interpretations, with the AbstractIjkGridRepresentation as a supporting representation. The export goes through OK and I am able to visualize the corresponding EPC using RESQML editor to confirm that they are as expected in each case, e.g. I can see the property for scenario (1) and both, the property and all the faults for scenario (2).

When reading these in, for scenario (1) I use APIs such as getIjkGridRepresentation(0) to retrieve the grid and getValuesPropertySet() to retrieve the associated properties and from there APIs getValuesCountOfPatch() and getIntValuesOfPatch(), to retrieve the specific cell ID property data etc. Similarly for scenario (2) I use the APIs such as getGridConnectionSetRepresentationCount, getGridConnectionSetRepresentation(), getInterpretation(), getCellIndexPairCount(), getCellIndexPairs() to retrieve the fault connection data. On Windows I confirm that everything is OK for both scenarios under debugger, however on Linux for the exact same input data, in scenario (1) everything is OK and read in as expected, but in scenario (2) even the APIs getValuesPropertySet() or getValuesPropertyCount() are all returning 0 and hence the data loading fails.

I am really puzzled by this behavior. Is this a known issue? Will updating to a more current version resolve the issues on Linux? I was hoping to avoid that if at all possible, so I would appreciate any ideas/workaround to enable scenario (2) to be read correctly on Linux.

2

Hi Sunil,

A different behavior on windows against Linux is not a well known issue. Then, I don’t know if updating to a more current version would resolve the issues on Linux.
However, updating is clearly always a good option.

Regards

3

Thanks. I was able to workaround this by switching to UnstructuredGridRepresentation instead, works great on both platforms and in both scenarios above when I do that. In another place in our workflow we actually have used (for a different RESQML deck) the AbstractIjkGridRepresentation but there, all the cell properties are defined on a sub-representation (not a huge difference I think), and there are no faults (with interpretations), so somewhat different - with only two GridConnectionSetRepresentations, and there it works OK on both platforms. Very puzzling. Anyway at least I have it working now, and next will plan to upgrade to 1.2.1 and test if that fixes it. Thanks.

4

Good to read that it now works.

I advise you switching directly to v2.4+ (not to v1.2.1) because otherwise you would pay twice the price to port your code for a less efficient code and a shorter time maintainance.