> There is only one sane answer to that question: During construction.

you need to compute the pvtIdx array one level up if you do not want to assume specific properties of the grid within the PVT classes. (how to map compressed indices to logically cartesian ones can only canonically be defined by the grid.) If you need to compute this array anyway why replicate and store it in each attribute object and not only once in the higher-level class? the "during construction" way makes the PVT property classes also implicitly (and IMHO unnecessarily) dependent on the grid. But I've no problem being called insane for this reasoning ;)

> We decided a few years ago that we should pass the cell indices to all high-level fluid functions.

maybe, but this decision is not set in stone, right? Also @bska's point with analytical functions is correct: what's the cell index for those? Further, what happens if you want to use a discretization that uses non-cell DOFs?

> I suggest doing this in the PvtInterface subclasses (common things could live in the PvtInterface class if needed).

that's what this patch tries to do so far. But I've come to the conclusion, that this stuff is better fully kept one level above...

> Doing it at the level above would mean that one level would translate from cell index to PVTNUM-ish index,

right. How about a common static method in PvtInterface to do this? The point of not making the PVT objects specific to the cells of a given grid is that this would regress their current functionality as you currently can put in anything and get a consistent answer out of it. so doing the cell index to pvt-region mapping internally would make things much more complicated than necessary...

> So I do think passing cells to PvtInterface methods is the best.

what happens if you don't look at cells?