search

OPM / opm-common

Common components for OPM, in particular build system (cmake).
http://www.opm-project.org
GNU General Public License v3.0
31 stars 112 forks source link

OLYMPUS + FILLEPS #1078

Closed totto82 closed 4 years ago

totto82 commented 5 years ago

Currently unmodified OLYMPUS fails. Removing FILLEPS makes is run again.

The issue is in "writeSatFuncScaling(...)" in WriteInit.cpp.

Any clue @bska ? My guess is that it is related to OLYMPUS being a oil+water case. But I stopped digging when I came down to writeSatFuncScaling(...)

bska commented 5 years ago

I don't have the model. What kind of diagnostic message do you get?

totto82 commented 5 years ago

I am sure @atgeirr or @GitPaean can help you with getting the model.

bska commented 5 years ago

Just a quick follow-up: If removing FILLEPS does make the model run, then this is likely to be related to the automatic creation of missing scaled end-point vectors (e.g., SOWCR, SWL etc.). What are the saturation function keywords used in the model and what scaled end-point vectors exist?

During assertKeyword() we're running the saturation function initializers and finalizers. The FILLEPS feature has produced errors there before, but I thought we fixed all of them in #925 (commit 8c9674856).

totto82 commented 5 years ago

Only SWOF.

bska commented 5 years ago

My guess is that it is related to OLYMPUS being a oil+water case.

Thinking more about it, that seems plausible. Our initializers and finalizers don't really handle two-phase models at all. At this point my only suggestion is to remove FILLEPS, because we're not going to be able to fix that problem right now.

atgeirr commented 5 years ago

At this point my only suggestion is to remove FILLEPS, because we're not going to be able to fix that problem right now.

What about a minor modification: if 2-phase, treat as no FILLEPS (and give a warning)? Would that be a sufficient workaround for now?

bska commented 5 years ago

At this point my only suggestion is to remove FILLEPS, because we're not going to be able to fix that problem right now.

What about a minor modification: if 2-phase, treat as no FILLEPS (and give a warning)?

That's a good idea, and easy to implement—at least if we do not want to integrate it into the ParseContext/ErrorGuard mechanism which will require changing the API.

On the other hand, I don't think we should use ParseContext and ErrorGuard here because this is (hopefully short-term) problem in Flow itself rather than the input deck.

bska commented 5 years ago

@totto82 : The symptoms of this are supposed to be relieved by #1087. On the other hand, the underlying issue does still remain. I suppose you/we want to keep this issue (#1078) open? Maybe open another and close this?