Grids and rockFluid

FESAPI
1

I am opening this topic to follow up the discussion started here.
I think It is not a standard question because the standard supports that functionality (i.e. linking an interpretation via the representedInterpretation member). Then, it is a fesapi question because it is how fesapi supports that standard functionnality.
Maybe, fesapi could have a test on the type of the representedInterpretation and put it either as a RockFluidOrganizationInterpretation or a StratigraphicOrganizationInterpretation.

2

The standard supports indeed that functionality and even much more : it allows IjkGridRepresentation to be linked to all different kind of interpretations including RockFluidOrganizationInterpretation or a StratigraphicOrganizationInterpretation.
Fesapi cannot provide all getters for all different possible interpretations to get for an ijk grid rep.
It is up to the fesapi user to check that.
The user can use getInterpretation from AbstractRepresentation to get the interp and then check its type by using dynamic_cast or getXmlTag method. Then the fesapi user can cast the interp with the desired class.

3

I agree with you in this direction of linkage.
What I had in mind is for the other linkage sense that is reconstructed by fesapi.
For example when a grid has its representedInterpretation of type RockFluidOrganizationInterpretation. The RockFluidOrganizationInterpretation object could record this grid in his own gridRepresentationSet.

4

I cannot do that neither.

Standardly speaking, Fesapi keeps allowing the possibility but does not encourage this approach since it really really looks to me not the good way to use RESQML. Indeed, RESQML has designed a particular way to attach grid and rock fluid org. Using another (even if technically allowed) way should in my opinon not be encouraged by Fesapi (even if it should still be possible). I have never seen major softwares exchanging like that and I have seen at least one using the cell assocation approach.

A second point is that if I do that for this link, I should do it everywhere else. And as you can put all kind of interp for all kind of rep then I should check all backwards relationships of interpretations and see if they apply to some other rep links as well.

Last but not least, it would create an asymetry in relationships which I don’t like at all for consistency reason.

I think the cost on fesapi side is too high compared to the cost on adopter side:

  • First, I think this use case won’t appear often at (if it does then I can change my mind in the future)

  • Second, it keeps consistency on fesapi side

  • Third, the impact on user side is really low (just one check to add for this particular use case) if the user really wants to use RESQML this way and not implement the only clearly well defined way.