Certain API usage throws exceptions

Hi,

I noticed that using some API results in exceptions being thrown in the code. For example:

   for(size_t s = 0; s < subdomains_count; s++) {
          boost::shared_ptr<AbstractIjkGridRepresentation> abstract_ijk_grid_ptr(m_impl->epc->createPartialIjkGridRepresentation("", subdomains_name[s]));
          abstract_ijk_grid_ptr->setICellCount(subdomain_nijk[s * 3 + 0]);
          abstract_ijk_grid_ptr->setJCellCount(subdomain_nijk[s * 3 + 1]);
          abstract_ijk_grid_ptr->setKCellCount(subdomain_nijk[s * 3 + 2]);
          abstract_ijk_grid_ptrs[s] = abstract_ijk_grid_ptr;
   }

The above call to API setICellCount throws exceptions. But this works:

for(size_t s = 0; s < subdomains_count; s++) {
	boost::shared_ptr<IjkGridNoGeometryRepresentation> abstract_ijk_grid_ptr(m_impl->epc->createIjkGridNoGeometryRepresentation("", subdomains_name[s], subdomain_nijk[s * 3 + 0], subdomain_nijk[s * 3 + 1], subdomain_nijk[s * 3 + 2]));
	m_impl->abstract_ijk_grid_ptrs.push_back(abstract_ijk_grid_ptr);
}

Further, the below code throws exception too.

   boost::shared_ptr<resqml2::GridConnectionSetRepresentation> grid_conn_set_rep(m_impl->epc->createGridConnectionSetRepresentation("", "GridConnectionSetRepresentation"));
   // IX assumes only top level grid connections presently
   grid_conn_set_rep->pushBackSupportingGridRepresentation((resqml2::AbstractGridRepresentation*)m_impl->epc->getIjkGridRepresentation(0));

at the call to pushBackSupportingGridRepresentation, but the below code works fine (when the grid pointer is cached):

	boost::shared_ptr<resqml2::GridConnectionSetRepresentation> grid_conn_set_rep(m_impl->epc->createGridConnectionSetRepresentation("", "GridConnectionSetRepresentation"));
	// IX assumes only top level grid connections presently
	grid_conn_set_rep->pushBackSupportingGridRepresentation(m_impl->abstract_ijk_grid_ptrs[0].get());

I am not sure why these exceptions are thrown - any ideas? I suspect it may be due to const correctness of the relevant APIs and their internal implementation, but the same works when accessing the HDF proxy using the API getHdfProxy, so I am not sure if that is the reason or not. Likewise, I see an exception just now for the below usage:

boost::uint64_t nb_resqml_connections = m_impl->epc->getIjkGridRepresentation(0)->getGridConnectionSetRepresentation(0)->getCellIndexPairCount();

which I plan to resolve by caching again (I hope so, anyway).

Hi Sunil,

I would need information about the thrown exception please?
What are their types and what are the associated messages?

It might be that you are trying to work on partial objects…

But to confirm, I really need to have information about the thrown exceptions.

Thanks for the response,
This is what I got for the first one:

image

Then this is what I got for the second one:

image

For the last one I got:

image

Again, I was able to resolve the first two in the end (first one by switching to IjkGridNoGeometryRepresentation, and second one by caching the grid pointers), and am about to use caching to try and resolve the third one.

Please try to catch the exceptions and to look at the exception message :https://stackoverflow.com/questions/3132935/how-to-get-message-of-catch-all-exception/32211681

I more and more think you are working with partial objects.

OK, I am using partial grid object, by design in this case. But I should be able to set the grid dimensions in I, J, and K directions, after creating an AbstractIjkGridRepresentation, right? What is wrong with the usage there? Do you mean I have to check the exception message to find out the details? I resolved it using a IjkGridNoGeometryRepresentation which as per my understanding is also a partial object.

Update: I resolved the last exception also by caching (and I confirmed that I was able to query the correct # of connections from it). To me, this doesn’t appear to be just due to using partial object, otherwise why would it be resolved simply by caching the relevant pointers? But I am not sure.

You cannot set I, J and K dimension on a partial grid. by RESQML rule.
In your first code, you use createPartialIjkGridRepresentation so you cannot set the dimensions even if you have a AbstractIjkGridRepresentation as a result.

Yes, when you face an exception, you should always looks at the exception message and type to understand WHY you face this exception. That’s general to C++ not to fesapi.

No, an IjkGridNoGeometryRepresentation is not always a partial object.
A partial object return true to bool AbstractObject::isPartial() const. That’s the only rule to identify a partial object. If you want to create a partial grid, you must use epcDocument.createPartialIjkGridRepresentation method.

About the other exceptions, it looks to be general C++ exception, not fesapi exception. Without access to more code, I don’t think I can help a lot.
You should debug by yourself to find more information : https://docs.microsoft.com/fr-fr/visualstudio/debugger/how-can-i-debug-an-access-violation-q

Then how come the AbstractIjkGridRepresentation class has a setICellCount, setJCellCount, and (inherited) setKCellCount APIs? You mean those are not usable?

Exactly, they throw exception if the grid is actually partial. If the grid is non partial, then they behave normally.
You should first check if it is a partial Ijk grid or not (using isPartial method)

The fesapi architecture has been decided like that because it was the quickest to implement. Another way would have to double ALL classes because ALL classes can be partial (i.e having PartialIJkGrid class and PartialGpGrid and PartialUnstructuredGrid and partialWellbore and partialHorizon etc…)

Looking at my avaialble time on fesapi, this decision to have only one class for partial and non partial objects has been done. Of course, with more available time, we could think about some other solutions.

I see. My understanding (apparently wrong, based on your explanation) was that one can always create a AbstractIjkGridRepresentation, and that it would be partial by definition (return geometry type “UNKNOWN”), but that one can set the IJK dimensions for such a grid. Previously you mentioned that IjkGridNoGeometryRepresentation is not always a partial object. If I create it and only assign IJK dimensions and no geometry, then it should be partial, am I right? In what instance is it not partial?

No

It is never partial unless :

  • you call the partial constructor epc->createPartialIjkGridRepresentation
    or
  • you deserialize an epcDocument where it exists a partial ijk grid representation.

OK, so is it not possible then to create a partial IJK grid and assign it IJK dimensions? If it is possible, appreciate if you can outline how to do that since I didn’t find that in the examples.

It is not possible at all by RESQML rule (not by FESAPI rule).
You might guess the IJK dimensions by looking at the HDF5 datasets dimension of the non partial IJK grid associated properties. This is all I see as a potential workaround if really needed.

But the official answer is : No you cannot have I,J,K dimensions on a partial grid which is basically only :

  • an UUID
  • a Title
  • a content type

I guess one more question. If we create an object with empty string for UUID, then it should automatically create the UUID behind the scene, and that doesn’t pose any problems, am I right?

Right as long as you don’t have to use a particular uuid.

I have one more question related to this. Supposing I used createPartialIjkGridRepresentation API, then after the EPC is created can I expect to find a grid object in the EPC? I unpacked the EPC contents that were generated and couldn’t find any. Is this expected?

Yes this is the right behaviour.
A partial grid does not exist in the EPC document. It is just a “pointer” contained in associated objects.

This is almost the definition of “partial” : it does not exist on the EPC but it probably exists somewhere else (in another store).

OK, does that mean also that none of the UUIDs in the EPC or the H5 correspond to the grid, right? That’s what I was looking for actually.

None of the UUID of the files (aka top level element) in the EPC or the H5 correspond to the grid: Yes!

However if you open some of these files such as a property of the grid, you would find the UUID of the grid inside the property XML file.

Actually sorry, I just checked one of the cell properties whose supporting representation would be the grid and I see the following in one of the obj_ContinuousProperty_.xml file:

<resqml2:SupportingRepresentation xmlns:eml="http://www.energistics.org/energyml/data/commonv2" xsi:type="eml:DataObjectReference">
	<eml:ContentType xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="xsd:string">application/x-resqml+xml;version=2.0;type=obj_IjkGridRepresentation</eml:ContentType>
	<eml:Title xsi:type="eml:DescriptionString">CoarseGrid</eml:Title>
	<eml:UUID xsi:type="eml:UuidString"></eml:UUID>
</resqml2:SupportingRepresentation>

So the UUID is empty here. I looked even at the GridConnectionSetRepresentation and even there the supporting representation grid UUID is empty. Am I missing something? Or is this as expected?