SPE9.DATA
Opened this issue · 23 comments
The grid in SPE9.DATA is specified in block-centered geometry therefore it used OLDTRAN as default. OPM does not support OLDTRAN. For OPM-FLOW to get match with Eclipse on SPE9.DATA NEWTRAN has to be specified in the deck. Either we need to support OLDTRAN or I suggest to remove SPE9.DATA and replace it with SPE9_CP.DATA and add a warning in the parser that OLDTRAN is not supported.
Can we just add NEWTRAN to the deck?
Then it is not SPE9 anymore. The results are significantly differet.
If changing to use the corner-point geometry will yield the same transmissibilities and therefore results I agree, that is what we should do. We might keep the existing one under a different name perhaps?
I think the warning about OLDTRAN should not be made by the parser, but further down in the chain (near to where transmissibilities are computed).
I believe we should add support for OLDTRAN. It is basically the default transmissibility when specifying a grid with DX, DY and DZ. Not supporting it seems like a rather serious deficit.
Not supporting it seems like a rather serious deficit.
do you mean "serious deficit" as in "it is a problem for many real world reservoir models" or as in "it's an annoyance when setting up academic benchmarks"? I'm wondering because IMO the transmissibilty calculation code is pretty fragile and should thus better not be touched if it isn't strictly necessary.
Not sure what you mean by real world reservoirs, but every once in a while a reservoir engineer sets up a regular grid to test something. It is a very common scenario both in academia and in the industry.
Sounds like you are arguing for re-factoring the transmissibility code. I am not sure fragility is a problem in this case though. We only need this for regular grids afaik, i.e., grids specified with DX, DY and DZ (potentially also for DR and DTHETA, but that can be handled later).
Not sure what you mean by real world reservoirs, but every once in a while a reservoir engineer sets up a regular grid to test something. It is a very common scenario both in academia and in the industry.
sure. but then the results will usually not be telling her too much about her real reservoir if she forgets to add NEWTRAN to her test deck and if the real deck does not include the OLDTRAN keyword. (oh, the joys of the ECL file format ;)
Sounds like you are arguing for re-factoring the transmissibility code. I am not sure fragility is a problem in this case though. We only need this for regular grids afaik, i.e., grids specified with DX, DY and DZ (potentially also for DR and DTHETA, but that can be handled later).
I'm not really arguing for a refactoring, but like @atgeirr I argue that a warning is sufficient. (at least if there are no compelling reasons to spend considerable resources to implement support for OLDTRAN.)
Not sure we need to support the keyword, but I believe we need to support it as the default behaviour when NEWTRAN is not given and DX, DY and DZ is used to set-up the grid. Maybe you are unaware of the default behaviour?
I am afraid users will find a warning hard to interpret.
Maybe you are unaware of the default behaviour?
rest be assured that I'm aware of this: I did implement support for NTG and MULT[XYZ]* after all, so I suppose that I'm quite familiar with the current implementation of the transmissibility code and I also had to read the documentation extensively. Given that, I have serious doubts if implementing proper support for OLDTRAN is worth the trouble...
I am afraid users will find a warning hard to interpret.
likely. possibly it should be made a fatal error in this case. IMO, what's worse than that is the E100 behaviour because it will silently do something different and the results will very easily mislead users.
If I understand you correctly, you are arguing that the OLDTRAN behaviour leads to incorrect/unphysical results, and that users should not want the default behaviour?
If I understand you correctly, you are arguing that the OLDTRAN behaviour leads to incorrect/unphysical results, and that users should not want the default behaviour?
no, not "incorrect" in the strict sense but "different from the real deck". in other words, this easily pushes people into comparing apples with oranges (which is wrong, even though neither the apples nor the oranges are "incorrect").
Sorry, I do not understand what you are trying to say.
well, "apples" == "NEWTRAN" and "oranges" == "OLDTRAN": if the reservoir deck uses a cornerpoint grid and your reservoir engineer's test deck uses a Cartesian grid, the results obtained for the test deck will only be of limited use if both decks go with the defaults for the transmissibilities because the real deck uses "NEWTRAN" and the test deck uses "OLDTRAN". (and, as the initial motivation for this issue shows, results are different in some cases.) Both results are equally "valid" or "invalid" from the physical point of view, but one should not be used to make conclusions about the other. Thus I think it is better to produce an error than it is to support OLDTRAN in the E100 way. (the other arguments against OLDTRAN are the effort required to implement it and the bugs potentially introduced by it.)
I think anyone setting up a deck with DX etc. would not expect (even with a dip) to have connections between layers other than straight up and down. That is what NEWTRAN would give (and I think it is warned against) in this context. So I do not think using OLDTRAN as default with DX etc. increases the "unwelcome surprise" factor, and we should eventually implement it. The question is: now?
If we want to support DX, DY, DZ and TOPS input I think we should support OLDTRAN as well. That is what is expected and in my view also the most physcially correct solution. The world is not Cartesian and OLDTRAN is a way of representing an unCartesian world with a Cartesian grid.
okay, I guess I did not consider the fact that the grid for the NEWTRAN and OLDTRAN cases assume grids with completely different properties. Still, the argument that grid specified via D[XYZ]/TOPS with OLDTRAN should not be used to try to gain insights for a grid specified via ZCORN/COORD with NEWTRAN applies at least as much. as far as I can see, the main effort on the OPM side for OLDTRAN would thus not be the transmissibility calculation but the grid representation? (i.e., I was mislead by the initial comments of this issue)
Actually, I think now is a good time. Being able to use flow on regular grids has been a missed feature among existing users, doing it properly with OLDTRAN support is very welcome. We are currently well a-head of planned progress, so if not now, then when?
I realize this is a very old thread, but as user I found it somewhat disconcerting. If I understand it correctly, one should be very careful about using the block centered keywords, such as DX, DY, DZ, and TOPS. I have tried to explain my understanding here. I would appreciate it if someone could take a look to see if I am way off base. Thanks.
I have read the linked text and I think your comments are accurate. As you say this is an old issue, but it has not been closed since it is (unfortunately) still relevant. Flow still does not support OLDTRAN.
It was interesting to see the tools you are building for interacting with the OPM software (although I am not proficient in R). Please consider sending a message to the OPM mailing list introducing yourself and your work, I am sure there are other users with similar interests that would appreciate it! We could also link to it from the OPM web site at some point.
I believe your understanding is correct. Unfortunately, we have not been able to prioritise this yet. The usual "patches are welcome" applies, so it is very welcome if somebody steps up an implements it with good code quality.
I fully agree that open source gridding tools, or more generally geomodelling software, would be great. As far as I know nobody has been able to build a sustained community around that so far. The closest I have seen is the SGEMS effort from Stanford. There are a couple of research projects going on as we speak, so there is some hope for the future.
Thanks for your quick response. Unfortunately my knowledge of c++ is vanishingly small, so a patch from me would probably not be welcome. Also, thanks for your kind words about my efforts with R. At this point, the work is so far from being ready for someone else to use that I think I will wait to introduce it to others. After I have gotten somewhat farther, I will take you up on your suggestion.
a patch from me would probably not be welcome.
don't say that; just open a pull request and then we can still decide whether to rip your head off or not ;)
seriously: the worst that can happen is that your pull request will be closed without being merged, but in the discussion you'll hopefully get some valuable feedback.