Open bska opened 7 years ago
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:
m_isradial
and the m_iscircle
could be merged in a bitmask like structure, which could also embody the alternatives cornerpoint and block-centered?i == 0
cell (that would require an api extension to get the coordinates of a cell though. Based on: #1097 this could be implemted as:const auto& p = grid.getCornerPos(0,0,0,0);
double inrad = sqrt( p[0]*p[0] + p[1]*p[1] );
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