Hi Liu Ming, all,

On Fri, 2013-09-27 at 09:19 +0200, Ming Liu wrote:
> I am trying to run some test cases about three-phase problem with OPM,
> so far as I know, the keyword “EQUIL” just support two-phase flow, the
> problem is that how to do if I want to initialize three-phase problem,
> that give WOC and GOC or the ECLIPSE EQUIL information for
> three-phase.

Well, at least OPM's support for EQUIL is limited to two phases only.
And by "support" I mean that we do something vaguely reasonable that
sort of works for the immiscible and incompressible case, but in reality
we are quite a ways away from having an ECLIPSE-style equilibration
facility.  In practice, we (i.e., OPM) are currently limited to
computing the initial state by some external means and then inputting
that state through the PRESSURE, SWAT, SOIL, SGAS, and RS keywords of
the SOLUTION section.

At SINTEF we sometimes use a separate MATLAB code (part of the MRST
suite) to do this initial computation, but that code is of course
useless if you don't have MATLAB.  If you *do* have access to MATLAB,
you're welcome to download MRST from http://www.sintef.no/mrst .

Furthermore, I suppose that if you have ECLIPSE, you could use ERT's
binary file reading support, including the Python bindings, to extract
the same initial state information from the ".INIT" file of an ECLIPSE
simulation and thus create a work-around for the EQUIL support that is
currently missing from OPM.  It will probably be a bit of work but
hopefully not too much.  Maybe Joakim Hove could comment on the
viability of this approach?

> I heard about that OPM will support the equilibrium of three-phase,
> what’s the progress? Can we use it in this coming September release? 

I am not aware of any ongoing effort that is on the path to producing a
workable equilibration facility.  We will in any case not have this in
the 2013.09 release.  The equilibration code in MATLAB that I mentioned
earlier is currently around 800 lines in a somewhat terse style.  That
count includes blank lines and comments.  Moreover, the code relies
*heavily* on MATLAB's built-in library of ODE solvers (and convenient
indexing operations).  Therefore, I *estimate* that one would need at
least two months of work to port the MATLAB code to C++ to reach a
usable state.

If anyone has any other information or comments, please do inform the
list.


Best Regards,
-- 
Bård Skaflestad <[email protected]>


_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm

Reply via email to