Hi,
I am new to both ResQML and FESAPI and so I apologise in advance if this is a dumb question.
The data sets that I am trying to load have a grid representation in one .epc/h5 file pair and the properties in another .epc/h5 file pair.
I have successfully loaded the grid geometry, but I don’t know the best way to load the properties and attach them to the grid.
What would be the best way to achieve the above?
Regards,
Brian
Hi Brian and welcome in this forum!
Your question is not dumb at all.
What you are facing is known as “partial transfer” : one EPC contains a part of the whole, the other EPC contains another part of the whole.
Hopefully, if the writer did not do mistake, you should see in your properties (xml file) the UUID of the grid in the SupportingRepresentation xml tag. I will assume now that the writer did a good job.
Easy case:
If I have done/finished my job right (probably in master which is in development, maybe not in v1.2), you should be able to deserialize both your EPC documents into the same DataObjectRepository using FESAPI and the links should be automatically resolved thanks to UUID.
There is no unit test on that and few/no people use that for now. Since this is quite an advanced functionality, see that as at least a wish on how FESAPI should behave. You can consider a failure as a bug if it does not work and I will work on it when time permits.
Alternate case (should work in 1.2):
You can deserialize the grid in a DataObjetRepository and
You can deserialize the properties in another DataObjetRepository.
The properties will reference a “partial” grid representation in the second DataObjetRepository (getRepresentation() method). In FESAPI, a “partial” grid representation is simply a normal AbstractGridRepresentation which returns true to the method isPartial().
Since a partial object can return its UUID and its title using getUUID() et getTitile(), you can on your application map the UUID of the partial grid representation to the same UUID non partial grid representation of your other DataObjectRepository.
To summarize
Regards
Philippe
Hi Philippe,
Many thanks for providing such a full answer so quickly.
I am currently using v1.2 as my work will go into production software so I will try the alternate case first. I have had a quick look at the UUIDs inside the EPC documents and I think they look correctly cross-referenced so hopefully this should work.
But, it is good to know that an easier way to handle the situation will be making its way into stable builds. Once the pressure is off, I will try to set up a build environment that tracks master and hopefully help with testing.
Regards,
Brian
Hi Philippe,
I just wanted to let you know that I started by populating two DataObjectRepositories and building up maps to UUIDs so that I could verify that the files I’m working with correctly reference each other and that all seems to be working.
But, just out of curiosity, I tried loading a grid EpcDocument and a property EPC document, I then deserialized into a single repo, as follows:
status = gridDoc.deserializeInto(gridRepo);
status = propDoc.deserializeInto(gridRepo);
then looped over the properties associated with each grid representation.
I was very happy to find that while using v1.2 the properties seemed to be attached to the grid as I had expected/hoped. They also appear to have the correct number of values etc.
I think I will proceed by this route and keep my fingers crossed that everything works out. I still have the dual repo plan as a backup, but it would be nice to keep using the easy way.
Regards,
Brian
Hi Brian,
I am glad it works even in 1.2.0.0.
It is :
And it is definitely not a lot used, not a lot tested.
With ETP, it is more tested since almost all exchanges are done partially.
Even on my side, using v1.2.0.0 I don’t implement the easy way since I can import the grid one day and the properties ten days after… And of course, the final application does not persist the DataObjectRepo after an exchange is done.
I am still happy to hear that 1.2 behaves as expected. And thanks for having reported it.
Down the road, both ways are useful I guess.
Hi Philippe,
I just wanted to post with an update and, if you don’t mind, I will add a small query here as well.
The very good news is that in my application I am correctly loading the grid geometry and all of the expected properties for the example data I have been given. This has the grid in one epc document and the properties in a separate one.
The only slight issue I had was that I needed to add a missing signature to one of the swig files since I am using this from Java and needed this method to be exposed in the wrapper. Namely:
ULONG64 getXyzPointCountOfKInterfaceOfPatch(unsigned int patchIndex);
I am using v1.2.0.0 and added this at line 3004 in swigResqml2_0_1Include.i
I was preparing a pull request to get this added to the main repository but when I look at master I can’t find where to add this as I don’t seem able to find the related method:
void getXyzPointsOfKInterfaceOfPatch(…)
Would it be possible for you to add this missing signature or point me to where it should go?
Regards,
Brian
Hi Brian,
Glad that you can load the grid geometry and properties in your application. This is the real purpose of FESAPI!
Thanks for the feedback to add ULONG64 getXyzPointCountOfKInterfaceOfPatch(unsigned int patchIndex); into swig.
In the main branch, the IJK grid (and almost all other dataobjects) have been promoted to resqml2 (and not resqml2_0_1 namesapce) preparing the RESQML2.2 release. So the method is probably to be added in fesapi/swigResqml2Include.i at master · F2I-Consulting/fesapi · GitHub
I am going to give a look at it and hopefully will backport it in a potential next 1.* version.
Tracked in Port getXyzPointCountOfKInterfaceOfPatch with SWIG · Issue #282 · F2I-Consulting/fesapi · GitHub
Hi Philippe,
Many thanks again for your explanations and assistance.
In that case, I will patch it locally until it is backported.
Regards,
Brian