On 08/09/14 18:45, wireless wrote:
On 08/09/14 07:18, Alf Birger Rustad wrote:
Hello everybody,
Finally we have a reference black-oil simulator coming into shape, but
admittedly still some rough edges to iron out. During this effort we uncovered
challenges with our plumbing.
The most prominent is perhaps the two grid interfaces cpgrid and
unstructered grid. The first is what we have interfaced to Dune with,
the second is the one used for the black-oil simulator
in opm-autodiff. I believe they both have technical merits, but
accommodating to both has become a growing burden. Hence, I suggest
we discuss possibilities for unifying the two interfaces into one.
Pros and cons, technical merits of the two, suggested approaches for
unifying, or arguments to keep both, are all welcome topics in the
discussion.
Well, I'm new to the list. I'm still crawling up to speed on the codes,
and building a solution for Gentoo linux. That said, you have an
excellent idea. However, I do think the 'OPM_team" needs to develop
things a bit further. I'd like to see some Overall Architectural
diagrams for the main components. [1] These would detail how each of the
major components interact; with some detail of the mechanisms for this
program (codes) to interact. Perhaps a technical paper of the OPM
project that someone might want to present at a conference?
Some of the basic information is in the README files of the sources:
<snip>
opm-core is the core library within OPM and contains the following
* Eclipse deck input and preprocessing
* Fluid properties (basic PVT models and rock properties)
* Grid handling (cornerpoint grids, unstructured grid interface)
* Linear Algebra (interface to different linear solvers)
* Pressure solvers (various discretization schemes, flow models)
* Simulators (some basic examples of simulators based on sequential
splitting schemes)
* Transport solvers (various discretization schemes, flow models)
* Utilities (input and output processing, unit conversion)
* Wells (basic well handling)
<end/snip>
So it just needs to be conveniently located in some software
architectural diagrams/ Unified Modeling Language is but one candidate
[A]. "Plantuml" is but one of these opensource tools [B].
Other options exist to generate overall architectural documents and
useful diagrams, imho.
Directed graphs, flow charts or state diagrams on each of the major
components and how they are suppose to function and interface face
internally to each of the code block inside each of the major components
would be keen. [2] Once basic diagram creation is accomplished, then
each module can be broken down into a clear, graphical representation of
the main functional blocks of each sub-component. At that point coding
and enhancing the interactions of the codes becomes more clear for the
existing team members as well as new contributors. This approach also
allows for component testing to discover where the overall bottlenecks
are; thus identifying where the major coding efforts could/should be
focused.
Large projects with a group of coders surely need this sort of top down
organization, in order for others to develop codes that can be
integrated into the project, imho. Otherwise, new developers spend
inordinate amounts of time trying to figure out how the components and
sub-components are support to work. Consistency in data set exchange
between the components and withing the sub-components is often an area
where subtle sources of errors can occur.
When we look in
"/var/tmp/portage/sci-physics/opm-core-2013.10/work/opm-core-release-2013.10-final/opm/core/wells.h"
I see lots of good documentation:
<snip>
* Controls for a single well.
* Each control specifies a well rate or bottom-hole pressure. Only
* one control can be active at a time, indicated by current. The
* meaning of each control's target value depends on the control type:
*
* - BHP -> target pressure in Pascal.
* - RESERVOIR_RATE -> target reservoir volume rate in cubic(meter)/second
* - SURFACE_RATE -> target surface volume rate in cubic(meter)/second
*
* The sign convention for RATE targets is as follows:
*
* - (+) Fluid flowing into reservoir, i.e. injecting.
* - (-) Fluid flowing out of reservoir, i.e. producing.
*
* For *_RATE controls, the distribution of phases used for the control
* is also needed. For example, a total rate control should have 1.0
* for each phase, whereas a control on oil rate should have 1.0 for
* the oil phase and 0.0 for the rest. For BHP controls, this is unused.
* The active control acts as an equality constraint, whereas the
* non-active controls should be interpreted as inequality
* constraints (upper or lower bounds). For instance, a PRODUCER's
* BHP constraint defines a minimum acceptable bottom-hole pressure
* value for the well.
<end/snip>
Now this is the sort of information that can be included in the more
detailed, including diagrams, in a easy to comprehend form. That way,
the Geologists, Engineers. mathematicians, and coders can all easily
converse on the merits of the various componen
ts.
Furthermore, dataset "standards" are coalescing, much to the chagrin
of the Largest industry players? It is an attempt to standardize how
data is represented among other lofty goals. "Participants will consist
of the executive leadership from CDA, ECIM and PPDM, as well as BP,
Shell, Maersk and Halliburton" [C].
So; am I "barking up the wrong tree with OPM"? If someone is not
comfortable with direct replies to the list, then personal email
or a private phone call would be very encouraging. Some feedback
would be keen for me. Excellent organization, has it's benefits
in code development, code maintenance and soliciting stimulating ideas
from a wide variety of experts, who are not going to waste their time
parsing reams of code variants, imho.
For example, If I'm running OPM on a linux server, what are the opimized
parameters for building a custom (distributed or clustered) linux kernel
for OPM? We cannot even begin to address such precision until the codes
are well documented, components tested and analyzed for bottlenecks
and then collecting kernel based data for proper analysis of the linux
kernel parameters. This will need to occur before migration to a
distributed file system (etc etc etc).
I hope I am (crystal) clear as the path I intend to pursue?
sincerely,
James
[A]
http://www.princeton.edu/~achaney/tmve/wiki100k/docs/Unified_Modeling_Language.html
[B] http://plantuml.sourceforge.net/
[C] https://www.ppdm.org/news/view/205
curiously,
James
[1]
https://www.google.com/search?q=software+design+diagrams&client=seamonkey-a&rls=org.mozilla:en-US:unofficial&tbm=isch&tbo=u&source=univ&sa=X&ei=W6DmU4DRHbHksATrzYDQDw&sqi=2&ved=0CBwQsAQ&biw=886&bih=829
[2]
https://www.google.com/search?q=flow+charts+state+diagrams+directed+graphs&client=seamonkey-a&rls=org.mozilla:en-US:unofficial&tbm=isch&tbo=u&source=univ&sa=X&ei=4KDmU9v9JoTmsATszYG4CA&ved=0CC8QsAQ&biw=886&bih=829
-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination
of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and
delete
this message.
Thank you
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
