F2I-Consulting / fesapi

API for ENERGISTICS™ data standards (mainly RESQML™), multi-languages (C++, Java, C#, Python)
Apache License 2.0
34 stars 24 forks source link

Method resqml2::AbstractGridRepresentation::getParentCellIndexCount fails #352

Open SimoneRinco opened 3 hours ago

SimoneRinco commented 3 hours ago

What are the steps to reproduce this issue?

Read a dataset which contains an UnstructuredGridRepresentation item with a single value Cell Parent Window attribute.

What does happen?

The method throws an exception with message "This list of cells can only be stored in HDF5 file."

What were you expecting to happen?

The method should return 1.

Any logs, error output, etc?

Any other comments?

This error occurs because a single value cell parent window, set via the setParentWindow method, is not creating an HDF dataset, but storing it as an integer constant array of size 1. Without knowing how many elements there are, which is the information returned by getParentCellIndexCount(), it is not possible to allocate memory for the output array to pass to getParentCellIndices. Ideally, we want this value stored in HDF.

What versions of fesapi are you using?

2.8.0

philippeVerney commented 2 hours ago

Thanks for the report. I'll fix that in the next release : 2.11.1.0 or 2.12 probably. If it's urgent, please let me know. I don't think to store the value into HDF. Looking at RESQML2.2, I even think the opposite since RESQML2.2 allows to store arrays directly into XML in order to save opening/closing an external binary file for tiny arrays. But I may be wrong.

Finally, I don't expect to release a 2.8.1.0 version with this fix since I cannot afford to maintain too much versions with the community support. I hope this is fine with you. You could think about cherry picking the fix by yourself if needed.

SimoneRinco commented 1 hour ago

Hi Philippe, it is not urgent. You have a valid point to avoid saving tiny arrays that would require opening/closing files to read a few bytes. However, our code is assuming all data is saved in HDF files. A "small vector" optimisation that can save data directly in XML based on some internal fesapi logic would actually break most of our code. This is the typical case of application of Hyrum's Law:

"With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody."

Unfortunately we are somebody.