On 08/10/14 12:50, Alf Birger Rustad wrote:
Hi James,
The points you raise all make sense. The documentation part is a moving target,
which
always needs improvement. As much as we would like to improve on it to make opm
attractive
for more developers, we are currently prioritizing getting a useful black-oil
simulator in
place. Doxygen documentation is available, and you will find some of the
documentation
you seek on the wiki. Feel free to get involved in improving the wiki
documentation.
OK, good information.
When it comes to performance, we are basically piggy backing on other projects
for the
low level stuff. We currently support umfpack and Dune solvers, while you will
find
patches for using petsc with opm on github. As such the current discussion is
an attempt
to have a common grid interface to various solver packages, taking parallel
implementations
into consideration. I suggest we keep this discussion to that. Feel free to
initiate
discussions on other topics separately.
[W]
Ah great, do you have a list of the low level stuff you are examining
(piggy backing on), or is the Dune/umfpack and petsc [X) the extent of
the low level effort, related to the Grid Interface?
I thought I was providing a "broad stroke" of background on how proper,
well documented design documents can lift discussions like this from the
comment inside the codes (which are great) to a level more apropos for
easing the discussion on the (code) design details. Apologies for a lack
of specific (targeted) details, strictly adherent to the subject line. I
do appreciate your feedback. Perhaps it is not too much to ask to
include some background links into your discuss, so folks like myself
can follow the discussions, including reading of the background
documents; just a thought ?
The first question to my mine with petsc is are you attempting to
support cuda as well as openCL? Has/is anyone from the OPM team
interested in contacting AMD about Mantle [Y]?
I'm not promoting any agendas other than exploring various components
on a performance basis; and that motivates me to inquire into the OPM
thought processes, such as the direction of the "Grid interface" issue
[V,Z].
Petsc does look feasible. Other grids could be supported by translations
sincerely,
James
[X] http://www.mcs.anl.gov/petsc/
[Y]
http://developer.amd.com/resources/documentation-articles/conference-presentations/#GPGPU7
[Z]
http://scicomp.stackexchange.com/questions/2430/structured-grid-and-unstructured-grid
[W] http://www.dune-project.org/doc/doxygen/dune-grid-html/modules.html
[V] http://www.siam.org/pdf/news/1912.pdf
Cheers,
Alf
wireless <[email protected]>:
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
-------------------------------------------------------------------
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
