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.
What do you think?
> Alf
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?
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.
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
