Hi,
I think there is some wrong with build system of opm-autodifffor finding dune.module . Because when I build opm-core it can found dune-common/dune.module successfully but when I turned to opm-autodiff, cmake complained Failed to locate dune.module for dune-common, but the strange thing is that it found dune-common just now... Here is the gist

Hi,
I want to build opm in my ubuntu 13.10 laptop, opm-core and opm-polymer are smoothly built, but the opm-autodiff complained that it can't find dune packages, that's a little strange, because opm-core and opm-polymer can found dune. I create a gist about the config information.

Hi, noticed one of our builds failed last night, link to output here. Guessing it is related to PR #166

Link to CDash output: http://www.opm-project.org/CDash/viewBuildError.php?buildid=23538

Anyone care to check it out?

Running sim_fibo_ad with the SPE1 case now yields screen output as follows:

---------------    Simulation step number 0    ---------------
      Current time (days)     0
      Current stepsize (days) 5
      Total time (days)       -5

... for all steps! Although it seems to actually run through, I have no way of telling.

For the disk output this is really bad, as I only get a single output file in each directory, such as pressure/000.txt.

Could you look at this please, @andlaus?

Hi!

I'm getting a compilation failure on opm-autodiff, anyone able to help me with what I've done wrong? The output is here http://80.240.129.131:8080/job/opm-autodiff/21/console (our new build-server). Have I installed some wrong dependency libs perhaps?

Thanks, Kristian.

Hello;

with the recent updates opm-polymer now depends on opm-autodiff and necessarily also on Eigen. The current opm-autodiff build system automagically downloads and installs Eigen in a opm-autodiff sibling directory. That works 100% for opm-autodiff and also for sibiling builds of opm-polymer, but the approach fails when building opm-polymer based on installed opm modules.

To me it seems that opm-autodiff / Eigen are generally regarded to be a success, maybe we should find a different way to handle Eigen dependency? The possibilities I see are:

1. Eigen is an external dependency which the user must install properly up front - without any automagical help from the Opm build system.
2. The opm-autodiff build system can install Eigen "properly" as part of the opm-autodiff: make install process.

I am sure there are other alternatives as well.

fractional_flows not initialized prior to this call

Did anyone else see this happened? Basically the iteration diverged. It did not happen to me last Friday. I ran SPE 1 with use_cpr=true

--------------- Simulation step number 57 ---------------
Current time (days) 870
Current stepsize (days) 10
Total time (days) 1216

dp_max_rel not found. Using default value '1e+09'.
ds_max not found. Using default value '0.2'.
drs_max_rel not found. Using default value '1e+09'.
relax_max not found. Using default value '0.5'.
max_iter found at /, value is '25'.
relax_type not found. Using default value 'dampen'.

Iteration Residual
0 3.18646682
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.411644538, T=0.003141, TIT=0.000392625, IT=8
1 13.0222952
=== RestartedGMResSolver
=== rate=0.215082807, T=0.003911, TIT=0.0007822, IT=5
2 22.1187174
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.552537755, T=0.006419, TIT=0.000493769231, IT=13
3 90.6083988
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.588871903, T=0.012759, TIT=0.0007974375, IT=16
4 620.001513
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.496296989, T=0.003713, TIT=0.0003713, IT=10
5 228.69902
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.613656847, T=0.00574, TIT=0.000382666667, IT=15
6 17246.4326
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.700885403, T=0.008688, TIT=0.0004344, IT=20
Switching control mode for well INJECTOR from SURFACE_RATE to RESERVOIR_RATE
7 10062.8451
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.757990234, T=0.016041, TIT=0.00064164, IT=25
Switching control mode for well INJECTOR from RESERVOIR_RATE to BHP
8 54084.0059
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.793445626, T=0.020291, TIT=0.000676366667, IT=30
Switching control mode for well INJECTOR from BHP to SURFACE_RATE
9 24001088.2
=== RestartedGMResSolver
=== GMRes::restart
=== GMRes::restart
=== rate=0.859807323, T=0.027779, TIT=0.000603891304, IT=46
Switching control mode for well INJECTOR from SURFACE_RATE to RESERVOIR_RATE
10 5.52198419e+10
=== RestartedGMResSolver
=== GMRes::restart
=== GMRes::restart
=== GMRes::restart
=== GMRes::restart
=== GMRes::restart
=== GMRes::restart
=== GMRes::restart
=== GMRes::restart
=== GMRes::restart
=== GMRes::restart
=== GMRes::restart
=== GMRes::restart
=== GMRes::restart
=== GMRes::restart
=== GMRes::restart
=== GMRes::restart
=== GMRes::restart
=== GMRes::restart
=== GMRes::restart
...........................................
=== GMRes::restart
=== rate=0.999356927, T=7.487372, TIT=0.00149717497, IT=5001
Program threw an exception: [/home/kaib/OPM/test_jenkins/opm-autodiff/opm/autodiff/NewtonIterationBlackoilCPR.cpp:203] Convergence failure for linear solver.
terminate called after throwing an instance of 'std::runtime_error'
what(): [/home/kaib/OPM/test_jenkins/opm-autodiff/opm/autodiff/NewtonIterationBlackoilCPR.cpp:203] Convergence failure for linear solver.
Aborted (core dumped)

I propose the following responsibilities for the Simulator classes, in particular SimulatorFullyImplicitBlackoil:

• Handle the timesteps. This means that the loop over all (report) timesteps should be in this class, and also that this class implements (or uses implementations of) sub-timestepping strategies that take into account convergence, number of nonlinear iterations etc.
• Handle output. I think timesteps and output must be handled at the same level. The lower level FullyImplicitBlackoilSolver class cannot know if what it is computing will be used (trying to take too long a time step), or if output is supposed to be written (if it is in a ministep and the user has chosen not to output intermediate steps between report steps).
• Handle changes to the well configuration. This includes not only obtaining the well controls etc. but also initialising and propagating well states correctly when such things change.

I propose that the following responsibility is removed from the class:

• Handle control switching due to constraints being broken. This must be handled at a lower level so that it can change from one Newton iteration to the next, which seems to be necessary for robustness (this is part of the work being done with the well formulation now).

This requires the following changes to interfaces between levels (sim_fibo_ad, Simulator class and Solver class):

• The Solver class must report the number of nonlinear iterations, max changes to saturation and any other data required by the stepsize logic that will reside in the Simulator class.
• The Simulator class must have a way to get the report timesteps. I propose using the SimulatorTimer class.
• The Simulator class must have a way to (for each new timestep) to create a new well structure. We may want to pass in the parser object for this, or (more general) an object that can construct the required structure on demand. We may also generate something like an array of WellsHandler objects, one for each timestep, and pass that to the Simulator class, but I think this will be too wasteful in terms of memory etc.

Please tell me what you think, before we start working on this.

(Update: forgot to mention that this is related to issues #103 and #106)

On my laptop (Kubuntu 13.04, GCC 4.7.3), I get the following error if I try to compile dune-autodiff:

and@singularius:~/src/opm-autodiff|master > make
[  4%] Patching Makefile to be DUNE compatible
[  4%] Built target dune-compat
[ 45%] Built target opmautodiff
Linking CXX executable bin/sim_2p_comp_ad
lto1: internal compiler error: in splice_child_die, at dwarf2out.c:5017
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
lto-wrapper: /usr/bin/c++ returned 1 exit status
/usr/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[2]: *** [bin/sim_2p_comp_ad] Error 1
make[1]: *** [CMakeFiles/sim_2p_comp_ad.dir/all] Error 2
make: *** [all] Error 2

I don't have many ideas what the reason for this could be, possibly it has something to do with LTO, but then again. maybe not.

I have problems compiling opm-autodiff on Debian wheezy with Eigen 3.1.0.
This problem occurs in the current master as well as in @rolk 's buildsystem rollup branch.

[  8%] Building CXX object CMakeFiles/opmautodiff.dir/opm/autodiff/FullyImplicitBlackoilSolver.cpp.o
In file included from /usr/include/eigen3/Eigen/src/Core/ArrayBase.h:127:0,
                 from /usr/include/eigen3/Eigen/Core:355,
                 from /usr/include/eigen3/Eigen/Dense:1,
                 from /usr/include/eigen3/Eigen/Eigen:1,
                 from /home/mblatt/tester/opm-autodiff/opm/autodiff/AutoDiffBlock.hpp:24,
                 from /home/mblatt/tester/opm-autodiff/opm/autodiff/FullyImplicitBlackoilSolver.hpp:23,
                 from /home/mblatt/tester/opm-autodiff/opm/autodiff/FullyImplicitBlackoilSolver.cpp:20:
/usr/include/eigen3/Eigen/src/Core/../plugins/ArrayCwiseBinaryOps.h: In instantiation of ‘const Eigen::CwiseBinaryOp<Eigen::internal::scalar_min_op<typename Eigen::internal::traits<T>::Scalar>, const Derived, const Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<typename Eigen::internal::traits<T>::Scalar>, Derived> > Eigen::ArrayBase<Derived>::min(const Scalar&) const [with Derived = Eigen::CwiseUnaryOp<Eigen::internal::scalar_abs_op<double>, const Eigen::Array<double, -1, 1> >; typename Eigen::internal::traits<T>::Scalar = double; Eigen::ArrayBase<Derived>::Scalar = double]’:
/home/mblatt/tester/opm-autodiff/opm/autodiff/FullyImplicitBlackoilSolver.cpp:850:66:   required from here
/usr/include/eigen3/Eigen/src/Core/../plugins/ArrayCwiseBinaryOps.h:39:69: error: could not convert ‘Eigen::ArrayBase<Derived>::min(const Eigen::ArrayBase<OtherDerived>&) const [with OtherDerived = Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<double>, Eigen::Array<double, -1, 1> >; Derived = Eigen::CwiseUnaryOp<Eigen::internal::scalar_abs_op<double>, const Eigen::Array<double, -1, 1> >; typename Eigen::internal::traits<T>::Scalar = double]((*(const Eigen::ArrayBase<Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<double>, Eigen::Array<double, -1, 1> > >*)(& Eigen::DenseBase<Derived>::Constant(Eigen::DenseBase<Derived>::Index, Eigen::DenseBase<Derived>::Index, const Scalar&) [with Derived = Eigen::Array<double, -1, 1>; Eigen::DenseBase<Derived>::ConstantReturnType = Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<double>, Eigen::Array<double, -1, 1> >; typename Eigen::internal::traits<T>::Scalar = double; Eigen::DenseBase<Derived>::Index = long int; Eigen::DenseBase<Derived>::Scalar = double](((const Eigen::EigenBase<Eigen::CwiseUnaryOp<Eigen::internal::scalar_abs_op<double>, const Eigen::Array<double, -1, 1> > >*)this)->Eigen::EigenBase<Derived>::cols<Eigen::CwiseUnaryOp<Eigen::internal::scalar_abs_op<double>, const Eigen::Array<double, -1, 1> > >(), (* & other)))))’ from ‘const Eigen::CwiseBinaryOp<Eigen::internal::scalar_min_op<double>, const Eigen::CwiseUnaryOp<Eigen::internal::scalar_abs_op<double>, const Eigen::Array<double, -1, 1> >, const Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<double>, Eigen::Array<double, -1, 1> > >’ to ‘const Eigen::CwiseBinaryOp<Eigen::internal::scalar_min_op<double>, const Eigen::CwiseUnaryOp<Eigen::internal::scalar_abs_op<double>, const Eigen::Array<double, -1, 1> >, const Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<double>, Eigen::CwiseUnaryOp<Eigen::internal::scalar_abs_op<double>, const Eigen::Array<double, -1, 1> > > >’
/usr/include/eigen3/Eigen/src/Core/../plugins/ArrayCwiseBinaryOps.h: In member function ‘const Eigen::CwiseBinaryOp<Eigen::internal::scalar_min_op<typename Eigen::internal::traits<T>::Scalar>, const Derived, const Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<typename Eigen::internal::traits<T>::Scalar>, Derived> > Eigen::ArrayBase<Derived>::min(const Scalar&) const [with Derived = Eigen::CwiseUnaryOp<Eigen::internal::scalar_abs_op<double>, const Eigen::Array<double, -1, 1> >; typename Eigen::internal::traits<T>::Scalar = double; Eigen::ArrayBase<Derived>::Scalar = double]’:
/usr/include/eigen3/Eigen/src/Core/../plugins/ArrayCwiseBinaryOps.h:40:1: warning: control reaches end of non-void function [-Wreturn-type]
make[2]: *** [CMakeFiles/opmautodiff.dir/opm/autodiff/FullyImplicitBlackoilSolver.cpp.o] Fehler 1
make[1]: *** [CMakeFiles/opmautodiff.dir/all] Fehler 2
make: *** [all] Fehler 2

My g++-4.4 complains about an incomplete type WellControls:

[ 12%] Building CXX object CMakeFiles/opmautodiff.dir/opm/autodiff/FullyImplicitBlackoilSolver.cpp.o
/home/mblatt/src/dune/opm-amg-opt/opm-autodiff/opm/autodiff/FullyImplicitBlackoilSolver.cpp:999:2: warning: #warning "what's the reference phase??"
/home/mblatt/src/dune/opm-amg-opt/opm-autodiff/opm/autodiff/FullyImplicitBlackoilSolver.cpp: In member function ‘void Opm::FullyImplicitBlackoilSolver::assemble(const Eigen::Array<double, -0x00000000000000001, 1, 0, -0x00000000000000001, 1>&, const Opm::BlackoilState&, const Opm::WellState&)’:
/home/mblatt/src/dune/opm-amg-opt/opm-autodiff/opm/autodiff/FullyImplicitBlackoilSolver.cpp:744: error: invalid use of incomplete type ‘const struct WellControls’
/home/mblatt/src/dune/opm-amg-opt/opm-core/opm/core/well_controls.h:37: error: forward declaration of ‘const struct WellControls’
/home/mblatt/src/dune/opm-amg-opt/opm-autodiff/opm/autodiff/FullyImplicitBlackoilSolver.cpp:744: error: invalid use of incomplete type ‘const struct WellControls’
/home/mblatt/src/dune/opm-amg-opt/opm-core/opm/core/well_controls.h:37: error: forward declaration of ‘const struct WellControls’
/home/mblatt/src/dune/opm-amg-opt/opm-autodiff/opm/autodiff/FullyImplicitBlackoilSolver.cpp:745: error: invalid use of incomplete type ‘const struct WellControls’
/home/mblatt/src/dune/opm-amg-opt/opm-core/opm/core/well_controls.h:37: error: forward declaration of ‘const struct WellControls’
/home/mblatt/src/dune/opm-amg-opt/opm-autodiff/opm/autodiff/FullyImplicitBlackoilSolver.cpp:745: error: invalid use of incomplete type ‘const struct WellControls’
/home/mblatt/src/dune/opm-amg-opt/opm-core/opm/core/well_controls.h:37: error: forward declaration of ‘const struct WellControls’
/home/mblatt/src/dune/opm-amg-opt/opm-autodiff/opm/autodiff/FullyImplicitBlackoilSolver.cpp:747: error: invalid use of incomplete type ‘const struct WellControls’
/home/mblatt/src/dune/opm-amg-opt/opm-core/opm/core/well_controls.h:37: error: forward declaration of ‘const struct WellControls’
/home/mblatt/src/dune/opm-amg-opt/opm-autodiff/opm/autodiff/FullyImplicitBlackoilSolver.cpp:747: error: invalid use of incomplete type ‘const struct WellControls’
/home/mblatt/src/dune/opm-amg-opt/opm-core/opm/core/well_controls.h:37: error: forward declaration of ‘const struct WellControls’
/home/mblatt/src/dune/opm-amg-opt/opm-autodiff/opm/autodiff/FullyImplicitBlackoilSolver.cpp:749: error: invalid use of incomplete type ‘const struct WellControls’
/home/mblatt/src/dune/opm-amg-opt/opm-core/opm/core/well_controls.h:37: error: forward declaration of ‘const struct WellControls’
/home/mblatt/src/dune/opm-amg-opt/opm-autodiff/opm/autodiff/FullyImplicitBlackoilSolver.cpp:749: error: invalid use of incomplete type ‘const struct WellControls’
....

Indeed this struct in opm-core is never defined in any header, just in the source file opm/core/wells/well_controls.c. Ergo most compilers cannot guess its size correctly and code should only use pointers to WellControls.

Either we only use pointers in FullyImplicitBlackoilSolver.cpp, or me move the definition to the header in opm.core. BTW I would prefer the latter to limit surprises.

After updating to the latest and greatest I can't link the examples in opm-autodiff anymore.
The problem is the missing cjson library. opm-parser and opm-core seem to be compiled fine.
A look into the cmake cache of opm-parser tells me that CJSON_INCLUDE_DIR-NOTFOUND.
My guess is that the cmake files in autodiff need an update to handle this situation.

Hi,
I want to calculate watercut from sim_fibo_ad's output, but I found the values in wellrates/ are totally different from that in summary file and restart file, which one should I believe now？

For SPE 9, the size of the linear system is 27104X27104. In output, it is said that umfpack was used in default. While for each linear solution, it takes pretty long time. In my experience, for this size of linear system, umfpack should take a few seconds or one second.

I tried with the left division with Matlab with the generated linear system. It took 3 seconds.

Does anyone have any clue for this?

If the umfpack is used indeed, I think some optimization can be done here.

here is the valgrind log:

and@singularius:~/src/opm-autodiff/bin|require-umfpack > valgrind ./sim_2p_comp_ad
==391== Memcheck, a memory error detector
==391== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==391== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==391== Command: ./sim_2p_comp_ad
==391== 

================    Test program for weakly compressible two-phase flow     ===============

---------------    Reading parameters     ---------------
nx not found. Using default value '100'.
ny not found. Using default value '100'.
nz not found. Using default value '1'.
dx not found. Using default value '1'.
dy not found. Using default value '1'.
dz not found. Using default value '1'.
porosity not found. Using default value '1'.
permeability not found. Using default value '100'.
num_phases not found. Using default value '2'.
rho1 not found. Using default value '1000'.
mu1 not found. Using default value '1'.
rho2 not found. Using default value '1000'.
mu2 not found. Using default value '1'.
num_phases not found. Using default value '2'.
relperm_func not found. Using default value 'Linear'.
rock_compressibility_pref not found. Using default value '100'.
rock_compressibility not found. Using default value '0'.
gravity not found. Using default value '0'.
convection_testcase not found. Using default value 'false'.
ref_pressure not found. Using default value '100'.
injected_porevolumes_per_day not found. Using default value '0.1'.
use_pside not found. Using default value 'false'.
linsolver not found. Using default value 'umfpack'.
output not found. Using default value 'true'.
output_dir not found. Using default value 'output'.


================    Starting main simulation loop     ===============
                        (number of epochs: 1)

nl_maxiter not found. Using default value '30'.
nl_tolerance not found. Using default value '1e-09'.
output not found. Using default value 'true'.
output_vtk not found. Using default value 'true'.
output_dir not found. Using default value 'output'.
output_interval not found. Using default value '1'.
check_well_controls not found. Using default value 'false'.
max_well_control_iterations not found. Using default value '10'.
num_transport_substeps not found. Using default value '1'.
use_segregation_split not found. Using default value 'false'.
num_psteps not found. Using default value '1'.
stepsize_days not found. Using default value '1'.


---------------    Simulation step number 0    ---------------
      Current time (days)     0
      Current stepsize (days) 1
      Total time (days)       1

==391== Invalid read of size 4
==391==    at 0x4B1AB1: Opm::ImpesTPFAAD::computeExplicitData(double, Opm::BlackoilState const&, Opm::WellState const&) (ImpesTPFAAD.cpp:230)
==391==    by 0x4B74DC: Opm::ImpesTPFAAD::solve(double, Opm::BlackoilState&, Opm::WellState&) (ImpesTPFAAD.cpp:165)
==391==    by 0x49F896: Opm::SimulatorCompressibleAd::Impl::run(Opm::SimulatorTimer&, Opm::BlackoilState&, Opm::WellState&) (SimulatorCompressibleAd.cpp:376)
==391==    by 0x4A0BCB: Opm::SimulatorCompressibleAd::run(Opm::SimulatorTimer&, Opm::BlackoilState&, Opm::WellState&) (SimulatorCompressibleAd.cpp:139)
==391==    by 0x49B8FA: main (sim_2p_comp_ad.cpp:213)
==391==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==391== 
==391== 
==391== Process terminating with default action of signal 11 (SIGSEGV)
==391==  Access not within mapped region at address 0x0
==391==    at 0x4B1AB1: Opm::ImpesTPFAAD::computeExplicitData(double, Opm::BlackoilState const&, Opm::WellState const&) (ImpesTPFAAD.cpp:230)
==391==    by 0x4B74DC: Opm::ImpesTPFAAD::solve(double, Opm::BlackoilState&, Opm::WellState&) (ImpesTPFAAD.cpp:165)
==391==    by 0x49F896: Opm::SimulatorCompressibleAd::Impl::run(Opm::SimulatorTimer&, Opm::BlackoilState&, Opm::WellState&) (SimulatorCompressibleAd.cpp:376)
==391==    by 0x4A0BCB: Opm::SimulatorCompressibleAd::run(Opm::SimulatorTimer&, Opm::BlackoilState&, Opm::WellState&) (SimulatorCompressibleAd.cpp:139)
==391==    by 0x49B8FA: main (sim_2p_comp_ad.cpp:213)
==391==  If you believe this happened as a result of a stack
==391==  overflow in your program's main thread (unlikely but
==391==  possible), you can try to increase the size of the
==391==  main thread stack using the --main-stacksize= flag.
==391==  The main thread stack size used in this run was 8388608.
==391== 
==391== HEAP SUMMARY:
==391==     in use at exit: 11,658,260 bytes in 544 blocks
==391==   total heap usage: 80,834 allocs, 80,290 frees, 22,189,246 bytes allocated
==391== 
==391== LEAK SUMMARY:
==391==    definitely lost: 0 bytes in 0 blocks
==391==    indirectly lost: 0 bytes in 0 blocks
==391==      possibly lost: 14,172 bytes in 453 blocks
==391==    still reachable: 11,644,088 bytes in 91 blocks
==391==         suppressed: 0 bytes in 0 blocks
==391== Rerun with --leak-check=full to see details of leaked memory
==391== 
==391== For counts of detected and suppressed errors, rerun with: -v
==391== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
Segmentation fault (core dumped)

this one is probably for @blattms. I'm not sure if the problem is in 'Dune::CpGrid` or if it is caused by another module (I guess the likelyhood that it's the former is about 55%):

and@heuristix:~/src/opm-autodiff|remove_old_parser > ./bin/sim_fibo_ad_cp deck_filename=~/SPE9/SPE9.DATA

================    Test program for fully implicit three-phase black-oil flow     ===============

---------------    Reading parameters     ---------------
deck_filename found at /, value is /home/and/SPE9/SPE9.DATA
deck_filename found at /, value is /home/and/SPE9/SPE9.DATA
output not found. Using default value 'true'.
output_interval not found. Using default value '1'.
output_dir not found. Using default value '.'.
pvt_tab_size not found. Using default value '200'.
sat_tab_size not found. Using default value '200'.
threephase_model not found. Using default value 'simple'.
sim_fibo_ad_cp: /usr/include/boost/range/iterator_range_core.hpp:340: reference boost::iterator_range<const Dune::cpgrid::EntityRep<0> *>::operator[](difference_type) const [IteratorT = const Dune::cpgrid::EntityRep<0> *]: Assertion `at >= 0 && at < size()' failed.
[heuristix:13638] *** Process received signal ***
[heuristix:13638] Signal: Aborted (6)
[heuristix:13638] Signal code:  (-6)
[heuristix:13638] [ 0] /lib64/libc.so.6(+0x358d0) [0x7f3f871638d0]
[heuristix:13638] [ 1] /lib64/libc.so.6(gsignal+0x39) [0x7f3f87163849]
[heuristix:13638] [ 2] /lib64/libc.so.6(abort+0x148) [0x7f3f87164cd8]
[heuristix:13638] [ 3] /lib64/libc.so.6(+0x2e616) [0x7f3f8715c616]
[heuristix:13638] [ 4] /lib64/libc.so.6(+0x2e6c2) [0x7f3f8715c6c2]
[heuristix:13638] [ 5] ./bin/sim_fibo_ad_cp(_ZNK5boost14iterator_rangeIPKN4Dune6cpgrid9EntityRepILi0EEEEixEl+0x6b) [0x91c75b]
[heuristix:13638] [ 6] ./bin/sim_fibo_ad_cp(_ZNK4Dune6cpgrid19OrientedEntityRangeILi0EEixEi+0x26) [0x91c626]
[heuristix:13638] [ 7] ./bin/sim_fibo_ad_cp(_ZNK4Dune6CpGrid8faceCellEii+0x13f) [0x91c42f]
[heuristix:13638] [ 8] ./bin/sim_fibo_ad_cp(_ZNK3Opm12AutoDiffGrid23FaceCellsContainerProxyclEii+0x24) [0x91b8c4]
[heuristix:13638] [ 9] ./bin/sim_fibo_ad_cp() [0x8d60a2]
[heuristix:13638] [10] ./bin/sim_fibo_ad_cp(_ZN3Opm17initStateFromDeckINS_12AutoDiffGrid23FaceCellsContainerProxyEN4Dune6CpGrid16CentroidIteratorILi1EEENS5_ILi0EEENS_27BlackoilPropertiesInterfaceENS_13BlackoilStateEEEviPKiiT_T0_T1_iRKT2_St10shared_ptrIKNS_4DeckEEdRT3_+0x2946) [0x94aa76]                                                                                                 
[heuristix:13638] [11] ./bin/sim_fibo_ad_cp(_ZN3Opm25initBlackoilStateFromDeckINS_12AutoDiffGrid23FaceCellsContainerProxyEN4Dune6CpGrid16CentroidIteratorILi1EEENS5_ILi0EEENS_27BlackoilPropertiesInterfaceENS_13BlackoilStateEEEviPKiiT_T0_T1_iRKT2_St10shared_ptrIKNS_4DeckEEdRT3_+0xf9) [0x8d8959]                                                                                           
[heuristix:13638] [12] ./bin/sim_fibo_ad_cp(main+0x11b5) [0x8d0735]                                                                                                                             
[heuristix:13638] [13] /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f3f8714fbe5]
[heuristix:13638] [14] ./bin/sim_fibo_ad_cp() [0x8cf4a5]
[heuristix:13638] *** End of error message ***
Aborted

this issue together with the fact that dune-cornerpoint can't handle neither the SPE1 nor the Norne decks, means that the decks I can test with sim_fibo_ad_cp is equal to the empty set...

IIRC, this used work last week and is probably related to endpoint scaling:

and@heuristix:~/src/opm-autodiff|master > ./bin/sim_fibo_ad deck_filename=~/Norne/Norne_ATW_2013/NORNE_ATW2013.DATA

================    Test program for fully implicit three-phase black-oil flow     ===============

---------------    Reading parameters     ---------------
deck_filename found at /, value is /home/and/Norne/Norne_ATW_2013/NORNE_ATW2013.DATA
deck_filename found at /, value is /home/and/Norne/Norne_ATW_2013/NORNE_ATW2013.DATA
output not found. Using default value 'true'.
output_interval not found. Using default value '1'.
output_dir not found. Using default value '.'.
pvt_tab_size not found. Using default value '200'.
sat_tab_size not found. Using default value '200'.
threephase_model not found. Using default value 'simple'.
Program threw an exception: [/home/and/src/opm-core/opm/core/props/satfunc/SatFuncSimple.hpp:43] SatFuncSimple   --  need to be implemented ...
terminate called after throwing an instance of 'std::runtime_error'
  what():  [/home/and/src/opm-core/opm/core/props/satfunc/SatFuncSimple.hpp:43] SatFuncSimple   --  need to be implemented ...
Aborted

Preprocessors, templates, headers.. Always fun.
Certain functions (UgHelpers) are only compiled if cpgrid is available. That's fine.

Problem happens in downstream modules. They might have cpgrid, while autodiff does not. If the gridhelper is used in the downstream project, you will get linker errors with shared libraries due to the missing symbols in the opm-autodiff library.

Solution would be to differentiate opm-autodiff-has-cp-grid and general has-cpgrid. Alternatively a build system level check and fail if the configurations differ.

Just created a gist to provide the full reading of the build failure for everybody, here:
https://gist.github.com/alfbr/1180bcb420cd385d8528

I get the following massage when I run cmake:

-- Performing Test HAVE_OPM_CORE - Failed
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:91 (MESSAGE):
Could NOT find opm-core (missing: opm-core_LIBRARY HAVE_OPM_CORE)
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:252 (_FPHSA_FAILURE_MESSAGE)
cmake/Modules/OpmPackage.cmake:358 (find_package_handle_standard_args)
cmake/Modules/Findopm-core.cmake:16 (find_opm_package)
cmake/Modules/OpmFind.cmake:146 (find_package)
cmake/Modules/OpmFind.cmake:204 (find_and_append_package_to)
cmake/Modules/OpmLibMain.cmake:90 (find_and_append_package_list_to)
CMakeLists.txt:63 (include)

I build in a directory opm-autodiff-build that has sibling directories as opm-autodiff, opm-core, opm-core-build etc.

Tor Harald

In this file line 781, the origin message is ImpesTPFAAD::solver(): Linear solver convergence failure.
But it should be FullyImplicitBlackoilSolver::solver(): Linear solver convergence failure.

Eclipse and OPM does not agree on the trans multipliers when MULTREGT is applied on the Norne deck. I don't see that MULTREGT is tested in test_transmissibilitymultipliers. I guess that's a good starting point for debugging this.

@andlaus Can you do this? I guess you are the one that know this part of the code best.

Norne: Starting out with 3 wells and a total of 18 completion intervals. In the fourth step a new well with 9 intervals is opened and we get the following problem:
Program threw an exception:
opm-autodiff/opm/autodiff/WellDensitySegmented.cpp:51
Here np:3 nw:4 nperf:27 and wstate.perfPhaseRates().size():54
Thus wstate seems to be out of sync with reality ...

Hi
This afternoon(Beijing time) the KW RS and RV bothering me a lot, the problem is that. In ECLIPSE, if you don't specify DISGAS and VAPOIL, you can't use RS and RV to do the initialization, even you set all the values are 0, i.e

RS
 113344*0/
RV
 113344*0/

But in OPM, even if there are no DISGAS, VAPOIL in deck file, you must set

RS
 113344*0/
RV
 113344*0/

if you don't set, the problem is coming.

> #3  0x0000000000638621 in 
> Opm::initBlackoilStateFromDeck<Opm::UgGridHelpers::FaceCellsProxy, 
> double*, double*, Opm::BlackoilPropertiesInterface, 
> Opm::BlackoilState> ()

The lastest version of all master branches unfortunately gives a segfault with the modified NORNE deck after 143 days. I just double checked, it's NOT due to the latest commit on DuneMatrix.

I tried to compile the updated opm, and I got the following linking error messages. Anyone got some clue about this?

Linking CXX executable bin/sim_fibo_ad
/home/kaib/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(ParserKeyword.cpp.o):(.gcc_except_table+0x6ec): undefined reference to typeinfo for boost::regex_error' /home/kaib/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(ParserKeyword.cpp.o): In functionbool boost::regex_match<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, char, boost::regex_traits<char, boost::cpp_regex_traits > >(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterator<char const*, std::string>, boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > >&, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits > > const&, boost::regex_constants::_match_flags)':
ParserKeyword.cpp:(.text.ZN5boost11regex_matchIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS5_EEEcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEEEbT_SD_RNS_13match_resultsISD_T0_EERKNS_11basic_regexIT1_T2_EENS_15regex_constants12_match_flagsE[ZN5boost11regex_matchIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS5_EEEcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEEEbT_SD_RNS_13match_resultsISD_T0_EERKNS_11basic_regexIT1_T2_EENS_15regex_constants12_match_flagsE]+0x77): undefined reference to boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::match()' /home/kaib/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(ParserKeyword.cpp.o): In functionboost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits > >::assign(char const, char const, unsigned int)':
ParserKeyword.cpp:(.text._ZN5boost11basic_regexIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE6assignEPKcS7_j[_ZN5boost11basic_regexIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE6assignEPKcS7_j]+0x2a): undefined reference to boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::do_assign(char const*, char const*, unsigned int)' /home/kaib/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(ParserKeyword.cpp.o): In functionboost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits > >::perl_matcher(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterator<char const*, std::string>, boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > >&, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits > > const&, boost::regex_constants::_match_flags, __gnu_cxx::__normal_iterator<char const*, std::string>)':
ParserKeyword.cpp:(.text.ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEEC2ES6_S6_RNS_13match_resultsIS6_S9_EERKNS_11basic_regexIcSD_EENS_15regex_constants12_match_flagsES6[ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEEC5ES6_S6_RNS_13match_resultsIS6_S9_EERKNS_11basic_regexIcSD_EENS_15regex_constants12_match_flagsES6]+0x10b): undefined reference to `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits > >::construct_init(boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits > > const&, boost::regex_constants::_match_flags)'
collect2: error: ld returned 1 exit status
make[2]: *** [bin/sim_fibo_ad] Error 1
make[1]: *** [CMakeFiles/sim_fibo_ad.dir/all] Error 2
make: *** [all] Error 2

Currently, the control mode of wells seems to be switched after each iteration of the Newton-Raphson solver. This is unphysical because the non-converged solutions which are seen by the non-linear solver do not need to exhibit any correlation with physical reality and can actually assume values which are far away from anything which is physically possible (e.g., pressures or saturations can be negative for such interim solutions). Thus, no control decision should be made based on such values and the control mode for wells should only be switched at the beginning of each time step.

If I understood something wrong, I'm happy to be corrected...

When running SPE9 through Eclipse, I get 37 report steps from the UNRST file. When running the same data through sim_fibo_ad, I only get 36. Any ideas as to where I should look for the source of this problem? The text files saturation/***.txt files contains 36 too. SPE1 and SPE3 are OK, though.

Currently the AutoDiffBlock class cannot be easily used by external (non-opm) codes since it includes the build-system-generated pragma file. What is the best solution to this? Two possible solutions are:

• Make the header part of the install, and use the module from an install location.
• Make the header a regular file in the source tree.

After PR #166. Some building and running error were found here. Could anyone try to repeat it?

Linking CXX executable bin/test_welldensitysegmented
[100%] Built target test_welldensitysegmented
In file included from /home/kaib/learning/Git/OPM/build/opm-autodiff/tests/test_transmissibilitymultipliers.cpp:27:0:
/home/kaib/learning/Git/OPM/build/opm-autodiff/opm/autodiff/GeoProps.hpp: In member function ‘void Opm::DerivedGeology::multiplyHalfIntersections_(const Grid&, Opm::EclipseStateConstPtr, const std::vector&, Opm::DerivedGeology::Vector&, std::vector&) [with Grid = UnstructuredGrid; Opm::EclipseStateConstPtr = std::shared_ptr; Opm::DerivedGeology::Vector = Eigen::Array<double, -1, 1>]’:
/home/kaib/learning/Git/OPM/build/opm-autodiff/opm/autodiff/GeoProps.hpp:215:47: error: expected primary-expression before ‘,’ token
OPM_THROW(std::logic_error, "Unhandled face direction: " << faceTag);
^
/home/kaib/learning/Git/OPM/build/opm-autodiff/opm/autodiff/GeoProps.hpp:215:81: error: invalid operands of types ‘const char [27]’ and ‘int’ to binary ‘operator<<’
OPM_THROW(std::logic_error, "Unhandled face direction: " << faceTag);
^
/home/kaib/learning/Git/OPM/build/opm-autodiff/opm/autodiff/GeoProps.hpp:215:88: error: ‘OPM_THROW’ was not declared in this scope
OPM_THROW(std::logic_error, "Unhandled face direction: " << faceTag);
^
make[2]: *** [CMakeFiles/test_transmissibilitymultipliers.dir/tests/test_transmissibilitymultipliers.cpp.o] Error 1
make[1]: *** [CMakeFiles/test_transmissibilitymultipliers.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
Linking CXX executable bin/sim_fibo_ad
[100%] Built target sim_fibo_ad

When Running SPE9

--------------- Simulation step number 2 ---------------
Current time (days) 2
Current stepsize (days) 2
Total time (days) 900

Iteration Residual
0 0.705650991
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.446070214, T=0.18565, TIT=0.018565, IT=10
1 0.144569303
Program threw an exception: [/home/kaib/learning/Git/OPM/build/opm-autodiff/opm/autodiff/NewtonIterationBlackoilCPR.cpp:243] Cannot do Schur complement with respect to non-diagonal block.
terminate called after throwing an instance of 'std::logic_error'
what(): [/home/kaib/learning/Git/OPM/build/opm-autodiff/opm/autodiff/NewtonIterationBlackoilCPR.cpp:243] Cannot do Schur complement with respect to non-diagonal block.
Aborted (core dumped)

Something also wrong with SPE3, while not that serious.

Hi,

I have just tried to build opm-autodiff on Statoil's RHEL 5 system, but cmake is complaining about some missing Eiegen3 dependency. Is this a new dependency and what do we use it for?

During one of my recent tests, with 5 wells, two water injection wells (One rate control and one BHP control) and three bhp control oil production wells.

The results look very good except the water injection rate of the BHP control injection well. The difference looks like if I divide the water injection rate by the B of the water, it will look good. (At least for this test)

I tried to figure out if we output the water injection rate under reservoir condition instead of standard condition, while this part is a little tricky for me to find the exact answer.

I am wondering if anyone familiar with this part can help a little bit to tell WWIR under what condition (reservoir condition or standard condition) we output.

I am not saying it is very likely to be the real reason, while since the results from all the other wells are so good and I think it is good to take a look at to make sure.

And it also can be a hidden problem, since the B of water is not very big and we did not pay a lot of attention to the water rate. For the rate control wells, we just copy the target rate, so no problem happened with that rate.

I wanted to open a pull request to make UMFPack mandatory as opm-autodiff does not compile without it. Unfortunately, they seem to be disabled for this repo. in the meantime, you find my patch at [email protected]:andlaus/opm-autodiff.git in the require-umfpack branch.

With GCC under Ubuntu with updated ert.

.......................
[ 86%] Built target test_block
Scanning dependencies of target test_boprops_ad
[ 89%] Building CXX object CMakeFiles/test_boprops_ad.dir/tests/test_boprops_ad.cpp.o
/home/kaib/learning/Git/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(EclipseGrid.cpp.o): In function Opm::EclipseGrid::equal(Opm::EclipseGrid const&) const': EclipseGrid.cpp:(.text+0x8b3): undefined reference toecl_grid_compare'
/home/kaib/learning/Git/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(EclipseGrid.cpp.o): In function Opm::EclipseGrid::getNumActive() const': EclipseGrid.cpp:(.text+0x8da): undefined reference toecl_grid_get_nactive'
/home/kaib/learning/Git/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(EclipseGrid.cpp.o): In function Opm::EclipseGrid::getNX() const': EclipseGrid.cpp:(.text+0x8fe): undefined reference toecl_grid_get_nx'
/home/kaib/learning/Git/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(EclipseGrid.cpp.o): In function Opm::EclipseGrid::getNY() const': EclipseGrid.cpp:(.text+0x922): undefined reference toecl_grid_get_ny'
/home/kaib/learning/Git/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(EclipseGrid.cpp.o): In function Opm::EclipseGrid::getNZ() const': EclipseGrid.cpp:(.text+0x946): undefined reference toecl_grid_get_nz'
/home/kaib/learning/Git/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(EclipseGrid.cpp.o): In function Opm::EclipseGrid::getCartesianSize() const': EclipseGrid.cpp:(.text+0x96a): undefined reference toecl_grid_get_global_size'
/home/kaib/learning/Git/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(EclipseGrid.cpp.o): In function Opm::EclipseGrid::getCellVolume(unsigned long) const': EclipseGrid.cpp:(.text+0xb88): undefined reference toecl_grid_get_cell_volume1'
/home/kaib/learning/Git/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(EclipseGrid.cpp.o): In function Opm::EclipseGrid::getCellVolume(unsigned long, unsigned long, unsigned long) const': EclipseGrid.cpp:(.text+0xc07): undefined reference toecl_grid_get_cell_volume3'
/home/kaib/learning/Git/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(EclipseGrid.cpp.o): In function Opm::EclipseGrid::getCellCenter(unsigned long) const': EclipseGrid.cpp:(.text+0xc77): undefined reference toecl_grid_get_xyz1'
/home/kaib/learning/Git/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(EclipseGrid.cpp.o): In function Opm::EclipseGrid::getCellCenter(unsigned long, unsigned long, unsigned long) const': EclipseGrid.cpp:(.text+0xd23): undefined reference toecl_grid_get_xyz3'
/home/kaib/learning/Git/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(EclipseGrid.cpp.o): In function Opm::EclipseGrid::initCornerPointGrid(std::vector<int, std::allocator<int> > const&, std::shared_ptr<Opm::GRIDSection const>)': EclipseGrid.cpp:(.text+0x1a93): undefined reference toecl_grid_alloc_GRDECL_data'
EclipseGrid.cpp:(.text+0x1aad): undefined reference to ecl_grid_free' /home/kaib/learning/Git/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(EclipseGrid.cpp.o): In functionOpm::EclipseGrid::initDVDEPTHZGrid(std::vector<int, std::allocator > const&, std::shared_ptr<Opm::GRIDSection const>)':
EclipseGrid.cpp:(.text+0x2f59): undefined reference to ecl_grid_alloc_dxv_dyv_dzv_depthz' EclipseGrid.cpp:(.text+0x2f68): undefined reference toecl_grid_free'
/home/kaib/learning/Git/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(EclipseGrid.cpp.o): In function Opm::EclipseGrid::initDTOPSGrid(std::vector<int, std::allocator<int> > const&, std::shared_ptr<Opm::GRIDSection const>)': EclipseGrid.cpp:(.text+0x350b): undefined reference toecl_grid_alloc_dx_dy_dz_tops'
EclipseGrid.cpp:(.text+0x351a): undefined reference to ecl_grid_free' /home/kaib/learning/Git/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(EclipseGrid.cpp.o): In functionOpm::EclipseGrid::exportACTNUM(std::vector<int, std::allocator >&) const':
EclipseGrid.cpp:(.text+0x3fd9): undefined reference to ecl_grid_init_actnum_data' /home/kaib/learning/Git/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(EclipseGrid.cpp.o): In functionOpm::EclipseGrid::exportMAPAXES(std::vector<double, std::allocator >&) const':
EclipseGrid.cpp:(.text+0x4005): undefined reference to ecl_grid_use_mapaxes' EclipseGrid.cpp:(.text+0x4040): undefined reference toecl_grid_init_mapaxes_data_double'
/home/kaib/learning/Git/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(EclipseGrid.cpp.o): In function Opm::EclipseGrid::exportCOORD(std::vector<double, std::allocator<double> >&) const': EclipseGrid.cpp:(.text+0x407f): undefined reference toecl_grid_get_coord_size'
EclipseGrid.cpp:(.text+0x40b7): undefined reference to ecl_grid_init_coord_data_double' /home/kaib/learning/Git/OPM/build/opm-parser-build/lib/x86_64-linux-gnu/libParser.a(EclipseGrid.cpp.o): In functionOpm::EclipseGrid::exportZCORN(std::vector<double, std::allocator >&) const':
EclipseGrid.cpp:(.text+0x40e3): undefined reference to ecl_grid_get_zcorn_size' EclipseGrid.cpp:(.text+0x411b): undefined reference toecl_grid_init_zcorn_data_double'
collect2: error: ld returned 1 exit status
make[2]: *** [bin/test_impestpfa_ad] Error 1
make[1]: *** [CMakeFiles/test_impestpfa_ad.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
Linking CXX executable bin/sim_simple
.......................

This ability is in most parts of the class, but some parts have bugs that prevent it, and others have not implemented the capability.

The Norne model fails after 329 days when an injector goes from injecting water to gas.
It seems like the wellManager handles this correctly and the perfphaserates_ computed by well_state.init are ok. But the well_state.partialCopy overwrites this data with the previous well_state.

What is the logic behind this partial copying? @atgeirr could you comment on this.

We used an optional-umfpack branch from bska until now, where the Eigen3 was downloaded automatically. With current master it seems cmake exits without attempting to download eigen3. Roland and Bård, you should already have the log in your mailbox.

The test AutoDiffBlockTest failed with GCC 4.7 on Debian. Here is a link to information: https://gist.github.com/flikka/e446fcd15f42e9d2f032

I don't think it is our fault, but I put it in here as a reminder, if someone else gets this problem.

It seems like (at least for the parser-integrate branch) that the examples/*.ad files impicitely require ERT. If ERT is not found, then an error occurs during runtime that support is missing.

Shouldn't opm-autodiff search (and even require) ERT during configure?

Those functions (at least if they do not require Eigen) should be of interest outside of opm-autodiff.
Therefore the funcions for Ug should be moved to opm-core and the ones for CpGrid to dune-cornerpoint.

That way the free function interface within UgGridHelpers should become more clear and more usable.

I mentioned previously that on SPE3, I observed quite large differences between the results produced by sim_fibo_ad on Statoil RH machines, as opposed to the "Cloud Debian" (and my Ubuntu) RH machines.

I've also noticed that the execution is very slow on our RH systems, see below for the first step on SPE9, could it be that the use_cpr stuff somehow "does not kick in"?

Statoil RH:

================    Test program for fully implicit three-phase black-oil flow     ===============

---------------    Reading parameters     ---------------
deck_filename found at /, value is SPE9.DATA
strict_parsing not found. Using default value 'true'.
deck_filename found at /, value is SPE9.DATA
output not found. Using default value 'true'.
output_interval not found. Using default value '1'.
output_dir found at /, value is 'opm-simulation'.
Trying to create directory "opm-simulation" for the simulation output
pvt_tab_size not found. Using default value '-1'.
sat_tab_size not found. Using default value '-1'.
threephase_model not found. Using default value 'gwseg'.
use_cpr not found. Using default value 'true'.
output not found. Using default value 'true'.
output_dir found at /, value is 'opm-simulation'.
output not found. Using default value 'true'.
output_vtk not found. Using default value 'true'.
output_dir found at /, value is 'opm-simulation'.
output_interval not found. Using default value '1'.


================ Starting main simulation loop ===============


---------------    Simulation step number 0    ---------------
      Current time (days)     0
      Current stepsize (days) 1
      Total time (days)       900

dp_max_rel not found. Using default value '1e+09'.
ds_max not found. Using default value '0.2'.
drs_max_rel not found. Using default value '1e+09'.
relax_max not found. Using default value '0.5'.
max_iter not found. Using default value '15'.
relax_type not found. Using default value 'dampen'.
Switching control mode for well INJE1 from SURFACE_RATE to BHP
Iteration         Residual
        0       0.128697489
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.207444472, T=6.594997, TIT=1.09916617, IT=6
        1       0.115141158
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.242618668, T=7.261896, TIT=1.03741371, IT=7
Switching control mode for well PROD26 from SURFACE_RATE to BHP
        2        6.18181185
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.381650899, T=6.761972, TIT=0.8452465, IT=8
        3        4.07741895
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.374189977, T=6.173061, TIT=0.771632625, IT=8
        4       0.257511719
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.4032373, T=6.388029, TIT=0.798503625, IT=8
        5      0.0368557544
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.448307187, T=6.90795, TIT=0.76755, IT=9
        6      0.0450621865
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.38267461, T=6.723977, TIT=0.840497125, IT=8
        7     0.00228779421
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.373491264, T=6.938946, TIT=0.770994, IT=9
        8     0.00311875158
Fully implicit solver took: 101.993045 seconds.

On our jenkins server:

================    Test program for fully implicit three-phase black-oil flow     ===============

---------------    Reading parameters     ---------------
deck_filename found at /, value is SPE9.DATA
strict_parsing not found. Using default value 'true'.
deck_filename found at /, value is SPE9.DATA
output not found. Using default value 'true'.
output_interval not found. Using default value '1'.
output_dir found at /, value is 'opm-simulation'.
pvt_tab_size not found. Using default value '-1'.
sat_tab_size not found. Using default value '-1'.
threephase_model not found. Using default value 'gwseg'.
use_cpr not found. Using default value 'true'.
output not found. Using default value 'true'.
output_dir found at /, value is 'opm-simulation'.
output not found. Using default value 'true'.
output_vtk not found. Using default value 'true'.
output_dir found at /, value is 'opm-simulation'.
output_interval not found. Using default value '1'.


================ Starting main simulation loop ===============


---------------    Simulation step number 0    ---------------
      Current time (days)     0
      Current stepsize (days) 1
      Total time (days)       900

dp_max_rel not found. Using default value '1e+09'.
ds_max not found. Using default value '0.2'.
drs_max_rel not found. Using default value '1e+09'.
relax_max not found. Using default value '0.5'.
max_iter not found. Using default value '15'.
relax_type not found. Using default value 'dampen'.
Switching control mode for well INJE1 from SURFACE_RATE to BHP

Iteration         Residual
        0       0.128697489
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.207444479, T=0.180012, TIT=0.030002, IT=6
        1       0.115141158
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.242618519, T=0.192012, TIT=0.0274302857, IT=7
Switching control mode for well PROD26 from SURFACE_RATE to BHP
        2        6.18181178
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.381651146, T=0.172011, TIT=0.021501375, IT=8
        3        4.07742267
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.374189919, T=0.17201, TIT=0.02150125, IT=8
        4       0.257511732
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.403237322, T=0.168011, TIT=0.021001375, IT=8
        5      0.0368557594
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.448304523, T=0.188012, TIT=0.0208902222, IT=9
        6      0.0450621868
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.382674586, T=0.168011, TIT=0.021001375, IT=8
        7     0.00228779427
=== RestartedGMResSolver
=== GMRes::restart
=== rate=0.373491596, T=0.184012, TIT=0.0204457778, IT=9
        8     0.00311875163
Fully implicit solver took: 6.9972 seconds.

Class BlackoilPropsAdFromDeck has members

std::vector<int> cellPvtRegionIdx_;
std::vector<int> pvtTableIdx_;

the contents of which are set in BlackoilPropsAdFromDeck::init<>() as

// ...
extractPvtTableIndex(cellPvtRegionIdx_, deck, number_of_cells, global_cell);
// ...
Opm::extractPvtTableIndex(pvtTableIdx_,
                          deck,
                          number_of_cells,
                          global_cell);

Name-space qualification aside, the input parameters to function extractPvtTableIndex() (i.e., deck, number_of_cells, and global_cell) are exactly the same in both cases so by construction the region vectors cellPvtRegionIdx_ and pvtTableIdx_ contain the same values and thus define the same cell-to-region mapping.

At present, cellPvtRegionIdx_ is used to index into the surface condition density table densities_, (method surfaceDensity()) and as the return value of public method cellPvtRegionIndex() while pvtTableIdx_ is used for "everything else". The mapping vectors were both introduced in commit 756de35 (PR #131) as part of the work to introduce support for multiple PVT regions.

Neither the commit log nor the PR discussion explained this (and I clearly didn't pay enough attention to details in the review--mea culpa) so I'm asking after the fact: Why do we need both mapping objects? Just for the record: The accompanying comments don't justify the existence of both members.

it seems like the DV{X,Y,Z} keywords seem to have suddenly gone unsupported:

and@heuristix:~/src/opm-autodiff|master > ./bin/sim_fibo_ad deck_filename=~/spe1/spe1deck.data

================    Test program for fully implicit three-phase black-oil flow     ===============

---------------    Reading parameters     ---------------
deck_filename found at /, value is ~/spe1/spe1deck.data
Program threw an exception: The GRID section must have COORD / ZCORN or D?? + TOPS keywords
terminate called after throwing an instance of 'std::invalid_argument'
  what():  The GRID section must have COORD / ZCORN or D?? + TOPS keywords
Aborted

I cannot seem to find any sort of "hook" into any kind of documentation. I would suggest that some sort of link to this be put into the README.md, a README.txt, INSTALL.txt, or the wiki.

If no documentation exists, perhaps make some? (There is a target 'doc' set up by the CMakeLists.txt, but it doesn't seem to generate anything useful for me...)

[I wanted to label this "enhancement", but cannot find a UI-component to do this... Maybe I do not have sufficient permissions for this...?!]

This is a request for discussion concerning design choices for supporting the WCONHIST keyword (history matched producers), and in particular the RESV control mode. A little bit of background on that keyword can be found in OPM/opm-parser#224, but essentially the well constraints can no longer be defined ahead of time. In other words, the constraint values become dependent on the reservoir state.

At the time of writing, the main time loop of examples/sim_fibo_ad.cpp looks like this (some details omitted)

for (timeMap->numTimesteps()) {
    WellsManager wells(eclipseState, /* ... */);

    SimulatorFullyImplicitBlackoil<UnstructuredGrid>
        simulator(/* ... */, wells, /* ... */);

    SimulatorReport episodeReport =
        simulator.run(simtimer, state, well_state);

    outputWriter.writeTimeStep(simtimer, state,
                               well_state.basicWellState());
}

The WellsManager in this case is class Opm::WellsManager from opm-core (file opm/core/wells/WellsManager.hpp). One of the objectives of class WellsManager is to turn the current notion of the present wells and associate constraints into the struct Wells that's used within the simulator and solver classes.

As far as I can tell, we do not need to change anything in struct Wells in order to support constraints on (total) reservoir volume flow rates. We do, however, have to change the setup of the constraints themselves (and to actually implement RESV-type constraints in the simulator, but that's fairly easy--just a bit of reshuffling code within class FullyImplicitBlackoilSolver<Grid>, and especially within method addWellControlEq()).

I don't think there's a reason to make opm-core aware of opm-autodiff's BlackoilStateSolutionState, so short-term I think I'd like to duplicate the topology, well/completion index calculation and constraints portion of WellsManager::WellsManager() into examples/sim_fibo_ad.cpp and to introduce state-dependent constraints in that restricted environment. Any comments/apprehensions?

Long term I think the WellsManager as it exists today will become less useful/relevant. I just don't think it's possible to have a single, centralised facility that meets all our current and future needs. The FullyImplicitBlackoilSolver<Grid> is actually a case in point. That class performs its own constraint matching and control switching, for example.

Note: The background for this request is task 1.12 from http://www.opm-project.org/wiki/index.php/Norne_tasks#List_of_tasks.

Hi,
When I tried to run sim_fibo_ad, it threw an exception fully implicit black oil solver can't handle boundary conditions other than noflow BCs, not implement yet. I think in the file sim_fibo_ad.cpp should give an empty BC which is equal to noflow BC, and then give an hint fully implicit black oil solver can't handle boundary conditions other than noflow BCs to make the solver running successfully other than threw an exception. Because for most cases, the boundary condition should be noflow.

There are two problems with the GridHelpers facility in opm-autodiff.

• The files have the same names as files in opm-core. While they have different include paths and guard macros, it is confusing and unfortunate. It is not clear to me what belongs in which file.
• The faceCells() function for UnstructuredGrid has two different implementations (and declarations). I am not sure why this even compiles, in any case the implementations have differing performance characteristics, and the one from opm-core should be preferred.

There may be more problems here, but I do not fully understand the division of responsibilities of these files.

A obvious deviation from the Gas rate was observed after the PR #144. More precisely is after the commit 3e3b39d , which introduced the primalVaraible_ to control the switching of the primary variables.

https://www.dropbox.com/s/ldnpd78vzzth9e7/before_commit.png
https://www.dropbox.com/s/w4efw6825cql8y8/after_commit.png

I am wondering if anyone familiar with this part can help to take a look. I wanted to fix that while I got messed by the logic there.

I found something interesting by accident when I was debugging opm-polymer. I have a deck file, the max pressure in PVTO and PVTG is less than 600 bar and 410 bar, in schedule part I set well configuration as follow:

WCONINJE
     'INJE01' 'WATER' 'OPEN' 'RATE' 6000.00  1* 10000 /
/

Obviously here 10000 are out of PVT pressure range, when I finished the simulation, I found that opm has different results with ECLIPSE after some time, as pictures show in the following. From WBHP picture we know that the max injection bhp is around 900 bar. But if you set a reasonable value (maybe 500 or 600), opm and eclipse get the same results. So I am thinking for interpolation opm has different strategy with ECLIPSE. This issue will not cause any problems for many scenarios, but will for some cases, like what I have.
BTW, this PVTO and PVTG are region 1 from Norne.