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
i
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
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 seri
22. mai 2015 kl. 13:46 skrev Joakim Hove :
> 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 models, realistical
22. mai 2015 kl. 13:46 skrev Joakim Hove :
> 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 models, realistical
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
> without copying the whole class
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