Hi, On Wednesday, November 19, 2014 21:29:30 Alf Birger Rustad wrote: > Oops, there you go, I actually forgot opm-material. Kind of underlines the > point of simplifying, we all get lost in the dependency tree. I believe > opm-material, just like opm-porsol, can be put into the other repos > wherever the parts fit best.
since material properties are not in any way specific to any simulation approach they best fit into their own module ;) But opm-material is actually a quite good example why modules are beneficial: the most through user is eWoms, but it is also (although lightly) used by opm- porsol for CO2 simulations. should eWoms and porsol now be united even though they use completely different approaches and don't share any code simulator whatsoever? (For reference, porsol is IMPES with global assembly, eWoms uses fully implicit discretizations with localized assembly.) Also, what's the difference from a practical POV between an internal module and an external library like ERT? (in this context, remember that most of our current code was first developed externally and some even precedes OPM by a fair amount of time.) > Moreover, I would rename > opm-polymer+opm-autodiff to opm-simulators, reconsidering the naming > whenever we figure out how to include a compositional simulator. yeah, refactoring the module hierarchy should be done as it is currently a bit illogical, but refactoring it to not having *any* modules at all would not be a smart move... 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
