Dear OPM community,
We have been considering how to best refactor the (huge) class
FullyImplicitBlackoilSolver
in such a manner that it can be more easily be extended with new options and
functionality
without copying the whole class (as is currently done to implement the
flow_polymer variant
There seems to be two main alternatives:
Could code generation be a third alternative?
J
---
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination
[] except on one technical comment concerning sibling builds. Sibling
build trees do not need to be in a location relative to the source trees and
do moreover, not have to have the same name for all modules.
Well - I'll take your word for it; but I still insist there must be some
Hi,
On Friday 22 May 2015 11:46:11 Joakim Hove wrote:
There seems to be two main alternatives:
Could code generation be a third alternative?
not before you completely change the approach used by the current Opm
simulators. If you go this route, you could also call it FeNICS ;)
more
22. mai 2015 kl. 13:46 skrev Joakim Hove jo...@statoil.com:
Could code generation be a third alternative?
You could think of templates as a form of structured code generation happening
inside
the C++ language. I think we want to keep this inside C++, since we are not
talking
about 100s of
On 22/05/15 15:43, Jørgen Kvalsvik wrote:
On 05/22/2015 01:09 PM, Atgeirr Rasmussen wrote:
Dear OPM community,
We have been considering how to best refactor the (huge) class
FullyImplicitBlackoilSolver
in such a manner that it can be more easily be extended with new options and
functionality
