Hi All, On Sunday, August 10, 2014 13:17:09 wireless wrote: > 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? > > [...]
While I personally also think that documentation is important, I am of the strong opinion that "dedicated" documentation like flow diagrams or reference handbooks are not really suitable for open-source projects in general and in particular not for open source projects which strive to use an open development model such as OPM. The reason which makes me think this is that architectural diagrams -- in contrast to "embedded" documentation such as doxygen comments -- are either (a) trying to force doing crucial design decisions at a too early stage (i.e., when the implementational problems cannot yet be foreseen) or (b) if they are produced after the act, they are just dead weight which take a lot of effort to create and even more to maintain while not helping the people who do the implementation even a trifle. That said, I think such diagrams still are useful in some corporate contexts which follow the "water fall" development model: They can be used for the customer and the contractor to specify upfront which software must be delivered and how it should look like. So the tl;dr is: While most (all?) current OPM developers won't spend time on such diagrams unless forced to do so, you are welcome to create some and propose them for inclusion in the official repositories... Now the actual topic of this thread: Grids. I am of the strong opinion that it is very beneficial to use a grid definition which allows to swap implementations easily, and which has been defined and is maintained by as many groups as possible. I don't actually care what turns out to be chosen for OPM in the end, but I consider the is-done-by-multiple-groups argument to be essential. (note, that this is more of a social than a technical argument.) cheers Andreas -- Any program which runs right is obsolete.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Opm mailing list Opm@opm-project.org http://www.opm-project.org/mailman/listinfo/opm
