Reading of SeismicLattice from DataObjectRepository

[Husnain]

Fesapi has provided method to write SeismicLatticeFeature to EPC file as shown in below link.
https://f2i-consulting.com/fesapi/doxygen/2.0/classcommon_1_1_data_object_repository.html#a92f42a99ab11a7d1007638ac0c92ddd0 .But could not found any method to read SeismicLatticeFeature directly from DataObjectRepository.
Although there is indirect way to read SeismicLatticeFeature through getInterpretedFeature() method of GenericFeatureInterpretation that is attached with that specific SeismicLatticeFeature.

Incase if no GenericFeatureInterpretation is attached with SeismicLatticeFeature and repository is serialized,then how SesimicLatticeFeature would be read from file?

[philippeVerney]

Hi @Husnain and welcome on board!

There is a generic way to access whatever dataobject of the data object repository based on their type using the template method getDataObjects.

You should be able to access all your SeismicLatticeFeature using it as for example :
const std::vector<RESQML2_NS::SeismicLatticeFeature *> mySeismicLatticeFeatures = repo.getDataObjects<RESQML2_NS::SeismicLatticeFeature >();

I hope it answers your question.

[Husnain]

@philippeVerney Thanks for your responce. I am using java wrapper of fesapi. In java wrapper of fesapi version 1.2.0.0 no such method getDataObjects is available.
This method repo.getDataObjectByUuid(uuid) is available, which is not useful because uuid is required to find the object.
Is this method is missing in Java wrapper or there is some way to get SeismicLatticeFeature from Repository?

[philippeVerney]

This method is not ported in JAVA (neither CSharp, nor Python) because it translates badly into those languages using SWIG.
It means that you actually cannot easily get SeismicLatticeFeature from a DataObjectRepository.

It would require some time on my side to expose this method and it won’t probably be backported in 1.2.0 but will be in the next v2.*
I’ll create a Github issue to keep track of such a request : https://github.com/F2I-Consulting/fesapi/issues/277

Here is a workaround waiting for the development (consider your company joining the FESAPI Initiative if you want to prioritize new FESAPI developements) and waiting for your v2.* adoption:

• Use DataObjectRepository::getUuids method in order to get all uuids of your repository. This should be ported in JAVA/CSharp/Python.
• Loop on those uuids and get related DataObject using DataObjectRepository::getDataObjectByUuid(string uuid)
• Within the loop, create a condition on the type of the result of DataObjectRepository::getDataObjectByUuid(string uuid) using intanceof in JAVA
• When the above condition is honored, do your process.

[shakirhusain]

Hello Philippe,
Thanks for your response. Couple of follow up questions.

1. Could you please provide additional pointers on joining FESAPI initiative ?
2. We are using java to read/write RESQML.
   Our thinking was that java API is as rich as the corresponding C++ one, but from your response apparently, it is not the case. Could you please give an idea on approximately, what percentage of functionality is missing from java APIs?
   Apart from prioritization, are there any C++ APIs that can’t be made available in java for some technical reasons?

More context:
We are at this point dealing with two data types - Seismic Lattice and 3D Horizons.
Once are are able to fully create/read/update/delete with these two data types we want to expand to more data types.

[philippeVerney]

Hi Shakir Husain,

1. The FESAPI initiative gives a way for members to vote for new FESAPI developments.
   The FESAPI initiative is constituted of 3 phases of development per year, 4 weeks each. At the beginning of each phase, members receive 25 points that they can spend on the task(s) they want to be worked. The task(s) receiving the higher number of points are worked by F2I-CONSULTING sequentially during the 4 weeks. This is the general idea.
   In more details, each member also decide how many days they want the voted task(s) to be worked.This is to prevent a member to vote for a no ending task.
   As a result, the score of a task is simply : spent points - days of work for this task.
   As an example, a “JAVA port of SeismicLatticeFeature acces from DataObjectRepository” vote can be 10 spent points for 3 days maximum of work which will end in a score of 10 - 3 = 7. All other tasks with a score superior to 7 will be worked before, all other tasks with a score inferior to 7 will be worked after. In case of draw, F2I-CONSULTING would decide on what we prefer to work on.
   If two members vote for the same task (it occurs often), then points, worked days and consequently score accumulate which leverage the prioritization of shared member wishes.
   As a final example, here is the latest votes of the FESAPI initative
   

   
   
   The annual fees are based on the revenues of the joining company. In order to ease contract constraints, the SOW and billing is done by Energistics which will pay F2I-CONSUTING afterwards (please contact Jana Schey and myself by email for more details).
   The 2021 annual fees are as below
   
   

2. Your thinking that java API is as rich as the corresponding C++ one is mainly true. The percentage of missing functionality in other languages is less than 10% in my opinion, I even guess less than 5%. The missing functionalities are mostly due to a lack of time to port them. And when easy, it can be ported very quickly and a new FESAPI version can be released.
   We use SWIG to port C++ to other languages so the rigorous answer to technical limitations can be found in swig documentation : SWIG-4.0 Documentation and more specifically SWIG-4.0 Documentation
   As of today, we have not faced any blocker to port C++. We have seen some difficulties with quite a lot of C++ pattern but we have always found a way to solve them, for example : polymorphism (downcasting into the right non abstract type when returning an abstract type in a function), directors (to be able to inherit from a FESAPI class in a non C++ language class, this is quite hard and need to be done class by class), Gabage Collection management for primitive arrays (need to allocate and deallocate arrays even in non C++ languages), dynamic array of polymorphic class (we have ideas but no solution today, this is by the way the main underneath this post), template port (need to define them for each class, no generic way), signed vs unsigned integer (some problems may rise if values above signed max 64 bits integer are used in C++ and ported into JAVA)
   After some experience, I am more concerned about cultural issues (C++ community vs JAVA community vs C# community vs Python community etc…) because the way C++ is ported in other languages still have some C++ flavours. Some adopters do not like these C++ flavors deeming it “clunky” which I can understand. To me this is mostly a cultural problem, not a technical problem.
   I am also concerned about performance issue. There is a cost to wrapping which for now is not a problem for anybody. One day, I am always wondering if this could become a problem. The cost is non significant for now (I have not tried to measure it but it theoretically exists according to SWIG especially when using directors i.e. ETP) but I cannot know all the future requirements.
   The alternative developing and maintaining 4 RESQML libraries in 4 different languages is just impossible regarding F2I-CONSULTING resources which is the main reason why we picked this option.