You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an API design issue and I welcome any and all comments.
I am currently working on implementing a transmissibility calculation for radial grids (assuming essentially the OLDTRAN method and diagonal tensors in cylinder coordinates, no support for faults). The calculation depends on
Being able to identify whether or not a simulation case uses radial coordinates (i.e., essentially whether or not keyword RADIAL is present in RUNSPEC).
Extracting the (positive) inner radius of the model geometry (keyword INRAD from the GRID section.
My current approach to obtaining the requisite information changes (mutilates?) the EclipseGrid API as outlined below. I am not too happy about this because it adds data members to the class that have a very specialised purpose and are hardly ever used/useful in a real simulation case. Any other suggestions for where to put these (or similar) query methods? Could/should we key this off the SimulationConfig?
Yes - this would of course mean that some very seldom used properties got disproportionally large room in the api/class - but of course that is a bit the way things are. I would merge this - some
possible alternatives:
The m_isradial and the m_iscircle could be merged in a bitmask like structure, which could also embody the alternatives cornerpoint and block-centered?
The inner radius could be calculated from a i == 0 cell (that would require an api extension to get the coordinates of a cell though. Based on: Added EclipseGrid method to get corner positions. #1097 this could be implemted as:
This is an API design issue and I welcome any and all comments.
I am currently working on implementing a transmissibility calculation for radial grids (assuming essentially the OLDTRAN method and diagonal tensors in cylinder coordinates, no support for faults). The calculation depends on
Being able to identify whether or not a simulation case uses radial coordinates (i.e., essentially whether or not keyword
RADIAL
is present inRUNSPEC
).Extracting the (positive) inner radius of the model geometry (keyword
INRAD
from theGRID
section.My current approach to obtaining the requisite information changes (mutilates?) the
EclipseGrid
API as outlined below. I am not too happy about this because it adds data members to the class that have a very specialised purpose and are hardly ever used/useful in a real simulation case. Any other suggestions for where to put these (or similar) query methods? Could/should we key this off theSimulationConfig
?Changes to
EclipseGrid.hpp
Changes to
EclipseGrid.cpp
The text was updated successfully, but these errors were encountered: