Re: [Opm] SHUT functionality in 2019.04

[Andreas Lauser]

Hi Lex,

While I have no idea what the root of your problem is, it is probably worth to 
check if it is related to the multi-segment well model: just pass the 
--use-multisegment-well=false command line parameter to your simulator.

cheers
  Andreas

On Tuesday, 2 July 2019 17:44:11 CEST Lex Rijkels wrote:
> Dear OPM community,
> Has the SHUT functionality maybe changed in version  2019.04 of Flow? I am
> running a simple well test forecast and my well does not react to:
> WELOPEN
>   WELLNAME SHUT /
> /
> 
> It simply continues producing. It does stop with STOP (but then I lose the
> reported FBHP) or a rate constraint of 0.
> Have I missed something in the use of SHUT?
> Thanks for your help,
> Kind regards,
> Lex Rijkels
> ___
> Opm mailing list
> Opm@opm-project.org
> https://opm-project.org/cgi-bin/mailman/listinfo/opm


-- 
The graveyards are full of people the world could not do without. 
  -- Elbert Hubbart

signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
https://opm-project.org/cgi-bin/mailman/listinfo/opm

Re: [Opm] Opm Digest, Vol 33, Issue 5

[Andreas Lauser]

Hi,

On Thursday, 27 September 2018 09:47:02 CEST Alf Birger Rustad wrote:
> Just ran a test over here on Red Hat 6. The case runs, but memory
> consumption seems to be in the order of 5GB. Are you sure your VM has
> enough memory?
 
Mohamad -- please note that, because of how the ECL parser currently works, 
this is also the ballpark per-core memory requirement for parallel runs.

cheers
  Andreas

-- 
Simple makefiles are a unicorn. A myth. [...] Every single case of a 
supposedly simple Makefile has turned out to be a mule with a carrot glued to 
its forehead.
-- Jussi Pakkanen

signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
https://opm-project.org/cgi-bin/mailman/listinfo/opm

Re: [Opm] PowerShell issue

[Andreas Lauser]

Hi,

On Monday, May 7, 2018 10:38:41 PM CEST Adam Watt wrote:
> I am new to this software and plan on using it for my MSc thesis.
> 
> I am looking for some advice, a little issue with installing:
> 
> 
> 
> I am running windows 10 and get the above message. Is there a fix to this
> and if so can you advise?

the installation instructions for windows on the website should probably be 
updated: It is preferable to use WSL on windows 10 instead of a virtual 
machine:

https://docs.microsoft.com/en-us/windows/wsl/install-win10

after this, the installation instructions for Ubuntu apply. (be aware that 
compared to native linux, the performance of the simulators is generally 
slightly worse on windows.)

cheers
  Andreas

-- 
With great power come great bugs.
-- Narcisa Vasile


signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
https://opm-project.org/cgi-bin/mailman/listinfo/opm

Re: [Opm] jenkins downtime

[Andreas Lauser]

thanks! this is much appreciated.

On Friday, 15 December 2017 13:32:09 CET Arne Morten Kvarving wrote:
> jenkins is back better than ever.
> 
> 
> - we now have 12 procs and 32GB ram. this translates to 3 concurrent jobs
> with 4 build threads.
> 
> - a dedicated slave has been added for the post-build jobs. this means that
> the post-builder jobs only run one at at time, and the other 2 slots are
> reserved for pull request builders.
> 
> 
> ie. we have higher throughput and higher responsiveness for the PR builder.
> 
> yell if anything breaks.
> 
> 
> Fra: Opm  på vegne av Arne Morten Kvarving
>  Sendt: 15. desember 2017 10:06:50
> Til: opm@opm-project.org
> Emne: [Opm] jenkins downtime
> 
> 
> hi,
> 
> 
> jenkins will be taken down at 12 cet for upgrades. shouldn't take too long.
> 
> 
> arnem


-- 
We no longer have things with computers embedded in them. We have
computers with things attached to them.
-- Bruce Schneier


signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

[Opm] OPM 2017.10 has been released

[Andreas Lauser]

Hi,

On behalf of the OPM project, I'm happy to announce that version 2017.10 has 
been released. Packages for Ubuntu 16.04 and Red-Hat Enterprise Linux 6 and 7 
have been prepared or should be available soon.

As usual, this release contains a multitude of new features and improvements. 
Most notable are probably that the flow simulator is now considerably faster 
than in the 2017.04 release, flow now supports the solvent and polymer black-
oil extensions and that there now is freely available documentation for the 
file format that is used to specify the input.

Finally, as the release manager, I'd take the opportunity and thank everyone 
involved in making the release process for 2017.10 go as smoothly as it did.

Have A Lot Of Fun!

Andreas


signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

[Opm] Release branches have been created

[Andreas Lauser]

Hi,

The branches for the 2017.10 release have been created and the master branches 
are open for (cautious-mode) business as usual again. Since Arne handles the 
packaging, sovereignty over these branches is hereby transferred to him.

Have fun
  Andreas

--
We no longer have things with computers embedded in them. We have
computers with things attached to them.
-- Bruce Schneier


signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

[Opm] Reminder: Feature merge deadline today

[Andreas Lauser]

Hi,

This is a reminder that the deadline for merging features that will go into 
the 2017.10 release is midnight today; as usual, you may pick the time and 
timezone you like best.

Tomorrow, non-documentation stuff on the master branches is supposed to only 
be touched if build issues or serious regressions like segmentation faults are 
discovered. On Wednesday, release branches are scheduled to be created and the 
master branches go back to business as usual after these branches have been 
made. I advice maintainers to be a bit cautious when merging features into 
master until the release has been finalized, though.

have fun
  Andreas

-- 
We no longer have things with computers embedded in them. We have
computers with things attached to them.
-- Bruce Schneier


signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

[Opm] Brace yourself for the OPM 2017.10 release

[Andreas Lauser]

Dear OPM community,

Once again it is that special time time of the year -- correct; we're getting 
ready for the next OPM release. This time we became very creative and will 
call it "2017.10", and because we've decided to go the high risk route, I'll 
be the guy who will be the responsible for part of your OPM-related back 
pains, i.e., I have the honor to be the release manager for this cycle again.

The modules involved in this release are the same as the ones which were 
included in the 2017.04 release. Here's the list for your convenience, the 
people whom I consider to be their maintainers are given in brackets; please 
yell at me if I got something wrong:

  - opm-data (Alf Birger Rustad)
  - opm-common (Atgeirr Rasmussen, Bård Skaflestad, Arne Morten Kvarving, 
Joakim Hove, Robert Klöfkorn, Tor Harald Sandve, Andreas Lauser)
  - opm-parser (Joakim Hove)
  - opm-output (Joakim Hove)
  - opm-grid (Atgeirr Rasmussen, Robert Klöfkorn, Bård Skaflestad)
  - opm-material (Andreas Lauser, Tor Harald Sandve, Robert Klöfkorn)
  - opm-core (Atgeirr Rasmussen, Robert Klöfkorn, Bård Skaflestad)
  - ewoms (Andreas Lauser, Robert Klöfkorn, Tor Harald Sandve)
  - opm-simulators (Atgeirr Rasmussen, Tor Harald Sandve, Robert Klöfkorn, 
Andreas Lauser)
  - opm-upscaling (Arne Morten Kvarving, Atgeirr Rasmussen, Bård Skaflestad)

The release process is supposed follow the usual drill; if you forgot it, do 
not despair, here it is once more:

- All maintainers take a hard look at all open pull requests and github issues 
for the modules which they are responsible for as soon as possible.
- Also as soon as possible, maintainers update the CHANGELOG file for the 
modules they are responsible for. If you are amongst this group, you probably 
should have look at the changes which got merged since the last release. This 
can be done using the commands

  FROM_DATE="Apr 11, 2017"
  FROM_ID="$(git rev-list -n 1 --first-parent --before="$FROM_DATE" master)"
  git log $FROM_ID..master

- The cut-off date for potentially disruptive code changes is Tuesday, October 
17,  2017. Thereafter, the master branches of all modules will be closed for 
non-trivial, non-regression and non-documentation merges until release 
branches are created.
- The release/2017.10 branches will be created two days later, i.e., on 
Thursday, October 19, 2017. To simplify the bug hunting, the master branches 
are supposed to be only open for non-invasive code changes until the final 
version of the release is ready. I leave it to the digression of the 
maintainers to determine what is "non-invasive" but I will also hold 
maintainers responsible for backporting bugfixes.
- Then Arne will prepare Debian/Ubuntu and RHEL packages packages and the rest 
of the community is expected to happily camp in front of their computer 
screens and test them.
- Finally, the tentative date for the final version is Tuesday, October 24, 
2017. Depending on the outcome of the packaging/testing efforts, 
this may be delayed by a few days.
- Don't forget to party after everything is over!

cheers
  Andreas

-- 
The Illuminati don't run the world. C programmers do. 
-- Daniel Angel Muñoz Trejo


signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

Re: [Opm] Explicitly setting the initial solution of EBOS.

[Andreas Lauser]

Hi,

On Montag, 31. Juli 2017 10:12:01 CEST you wrote:
> Thank you for your answer.  I've attached a minimum working example. As you
> can see, the residuals do not change after the update of the initial
> solution.
> In the example, the initial solution is (attempted) to be set to be equal
> to the final state.

sorry, but I cannot see that you change anything compared to the current 
solution before the call to convertInput(tmp_reservoir_state), so getting the 
same result is the expected behavior. Also, I still can't see how your code is 
supposed to be used without doing some guesswork of where it should go (I 
suppose the run() method of the simulator class?) it would be less confusing 
if you would send patches (i.e., the output of `git diff origin/master`).

I've attached a patch which probably does what you want. In particular, note 
that if you cannot guarantee a fixed number of changed variables of the result 
due to a single change of the initial condition, the problem is not sparse.

cheers
  Andreas

> 2017-07-28 11:41 GMT-03:00 Andreas Lauser :
> > Hi Joakim,
> > 
> > it looks like you modify copies of the objects which are actually used by
> > the
> > simulator. I can't be too sure because the file which you attached is
> > incomplete.
> > 
> > cheers
> > 
> >   Andreas
> > 
> > On Donnerstag, 27. Juli 2017 16:15:32 CEST Joakim R. Andersen wrote:
> > > Hi, all.
> > > 
> > > I am trying to calculate the numerical Jacobian of the reservoir
> > 
> > residuals
> > 
> > > w.r.t. the initial state. To do this I need to replace the initial
> > 
> > solution
> > 
> > > of EBOS with a perturbed one. I've been trying for a while, and I am
> > > getting nowhere.
> > > 
> > > I've attached the code. It is placed at the end of "nonlinearIteration"
> > 
> > in
> > 
> > > "BlackoilModelEbos.hpp":
> > > 
> > > if (!report.converged) { ... }
> > > 
> > > else {
> > > // all the code goes here.
> > > }
> > > 
> > > I've also made the "nonlinearIteration" take the initial reservoir state
> > 
> > as
> > 
> > > an input. Thus, we have both the final state and the initial state when
> > 
> > the
> > 
> > > "else"-case is invoked.
> > > 
> > > Setting the initial solution as done in the attachment does not work.
> > > How
> > > can I pass this information further such that the "linearize()" function
> > > (the one that calculates the residuals and the Jacobian in EBOS) will be
> > > affected?
> > > 
> > > Let me be more precise. The code runs, and the initial solution is set,
> > 
> > but
> > 
> > > the "linearize()" function are not aware of the change.
> > > 
> > > 
> > > Best regards,
> > > Joakim R. Andersen
> > 
> > --
> > The Illuminati don't run the world. C programmers do.
> > 
> > -- Daniel Angel Muñoz Trejo
> > 
> > ___
> > Opm mailing list
> > Opm@opm-project.org
> > http://opm-project.org/cgi-bin/mailman/listinfo/opm


-- 
The Illuminati don't run the world. C programmers do. 
-- Daniel Angel Muñoz Trejodiff --git a/opm/autodiff/SimulatorFullyImplicitBlackoilEbos.hpp b/opm/autodiff/SimulatorFullyImplicitBlackoilEbos.hpp
index 90ff48d..aa3a88a 100644
--- a/opm/autodiff/SimulatorFullyImplicitBlackoilEbos.hpp
+++ b/opm/autodiff/SimulatorFullyImplicitBlackoilEbos.hpp
@@ -315,6 +315,8 @@ public:
 // \Note: The report steps are met in any case
 // \Note: The sub stepping will require a copy of the state variables
 if( adaptiveTimeStepping ) {
+auto tmpState = state;
+
 bool event = events.hasEvent(ScheduleEvents::NEW_WELL, timer.currentStepNum()) ||
 events.hasEvent(ScheduleEvents::PRODUCTION_UPDATE, timer.currentStepNum()) ||
 events.hasEvent(ScheduleEvents::INJECTION_UPDATE, timer.currentStepNum()) ||
@@ -323,6 +325,18 @@ public:
  output_writer_.requireFIPNUM() ? &fipnum : nullptr );
 report += stepReport;
 failureReport_ += adaptiveTimeStepping->failureReport();
+
+// this is a big fat hack!
+const double eps = 100.0; // [Pa]
+tmpState.pressure()[0] += eps;
+stepReport = adaptiveTimeStepping->step( timer, *solver, tmpState, we

Re: [Opm] Explicitly setting the initial solution of EBOS.

[Andreas Lauser]

Hi Joakim,

it looks like you modify copies of the objects which are actually used by the 
simulator. I can't be too sure because the file which you attached is 
incomplete.

cheers
  Andreas

On Donnerstag, 27. Juli 2017 16:15:32 CEST Joakim R. Andersen wrote:
> Hi, all.
> 
> I am trying to calculate the numerical Jacobian of the reservoir residuals
> w.r.t. the initial state. To do this I need to replace the initial solution
> of EBOS with a perturbed one. I've been trying for a while, and I am
> getting nowhere.
> 
> I've attached the code. It is placed at the end of "nonlinearIteration" in
> "BlackoilModelEbos.hpp":
> 
> if (!report.converged) { ... }
> 
> else {
> // all the code goes here.
> }
> 
> I've also made the "nonlinearIteration" take the initial reservoir state as
> an input. Thus, we have both the final state and the initial state when the
> "else"-case is invoked.
> 
> Setting the initial solution as done in the attachment does not work. How
> can I pass this information further such that the "linearize()" function
> (the one that calculates the residuals and the Jacobian in EBOS) will be
> affected?
> 
> Let me be more precise. The code runs, and the initial solution is set, but
> the "linearize()" function are not aware of the change.
> 
> 
> Best regards,
> Joakim R. Andersen


-- 
The Illuminati don't run the world. C programmers do. 
-- Daniel Angel Muñoz Trejo

signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

Re: [Opm] Extracting matrices and right-hand sides

[Andreas Lauser]

Hi,

On Freitag, 19. Mai 2017 22:05:34 CEST Alan King wrote:
> I'd like to be able to extract the matrices and right-hand sides that are
> sent to the solvers. Does anyone have some pointers on where in the code I
> can look to write a dump routine?

Easy, look here: 

https://github.com/OPM/opm-simulators/blob/master/opm/autodiff/
BlackoilModelEbos.hpp#L451

The residual can be printed simply by using

std::cout << ebosResid;

For its Jacobian matrix, I recommend

Dune::printSparseMatrix(std::cout, ebosJac, "J", "row"); 

Because you probably don't want to be flooded by dozens of millions of boring 
zero entries. If I remember correctly, there are also some routines in Dune 
which output matrices and vectors to standardized format like MatrixMarket. I 
haven't personally used them yet, though.

cheers
  Andreas

-- 
Just because a patch doesn't solve world hunger isn't really a good
reason to reject it.
-- Daniel Vetter

signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

[Opm] Version 2017.04 of the OPM simulation software suite has been released

[Andreas Lauser]

Dear OPM community,

The Open Porous Media project is glad to announce that version 2017.04 of the 
OPM suite of simulation software has been released:

http://opm-project.org/?p=890

Installation instructions can be found on our download page:

http://opm-project.org/?page_id=36

Certainly the most significant change of this release cycle is the introduction 
of the "flow_ebos" simulator. Compared to the previous "flow" simulators, 
"flow_ebos" uses a different approach to linearize the non-linear system of 
partial differential equations and for this reason exhibits significantly 
better performance. The new simulator is intended to eventually fully replace 
the current family of simulators (i.e., "flow", "flow_mpi", "flow_solvent",  
"flow_polymer", etc.) and unify them under the name "flow". Also, it should 
already provide a proper superset of the capabilities of the "flow" simulator 
of previous OPM releases and for this reason, the name "flow" has been made an 
alias for "flow_ebos" in OPM 2017.04. If, for some reason, the previous 
simulator must be used, it is still shipped as "flow_legacy" in this release, 
but we strongly encourage you to send us bug reports if you encounter any case 
that can be simulated using "flow_legacy" but not using the new "flow" 
simulator.

Besides the introduction of "flow_ebos", plenty unit tests have been added, a 
plethora of bugs has been fixed, well handling has been considerably improved 
and now supports e.g. top-hole pressure controls and vertical flow performance 
tables, ECL output and restart capabilities have been made much more 
comprehensive, and all grid related functionality of opm-core has been moved 
to the opm-grid module in preparation of the former module's eventual 
retirement. In addition, a Docker container has been uploaded to Docker Hub to 
ease deployment for people who are interested in container technologies.

Last but not least, I would like to thank everyone who contributed to making 
the many changes of this release happen so smoothly. It has been a pleasure to 
work with you!

Have fun with the new toy!
  Andreas


signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

[Opm] Packages for the second release candidate of OPM 2017.04 available

[Andreas Lauser]

Dear OPM community,

On behalf of the release team, I'm happy to announce that packages of the 
second release candidate of the upcoming OPM 2017.04 release are available for 
Ubuntu 16.04:

https://launchpad.net/~opm/+archive/ubuntu/testing/

If no release critical issues will be found, the software contained packages 
will be identical to the final version.

Have Fun
  Andreas





signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

[Opm] The 2017.04 release branches have been created

[Andreas Lauser]

Hi,

I have just created and uploaded the stable branches of OPM 2017.04 for all 
modules featured by this release. They are called "release/2017.04" and are 
fairly close to what the final release will look like, i.e., these branches are 
supposed to only get fixes for serious bugs and packaging updates. For this 
reason, Arne Morten Kvarving is the person in charge of them. That said, 
maintainers are responsible to apply all bugfixes from the master branch to the 
release branch and vice versa until the final version have been made; i.e., if 
maintainers decide to merge disruptive changes to master, that's okay with me, 
but I'll grill them if they do not fix corresponding bugs in the release branch 
via minimal patches, so I advice to be a bit conservative with pressing The 
Green Button (TM) during the next two weeks or so.

cheers
  Andreas

-- 
Just because a patch doesn't solve world hunger isn't really a good
reason to reject it.
-- Daniel Vetter

signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

[Opm] Reminder: Feature merge cutoff

[Andreas Lauser]

Hi,

This is just a reminder that the cutoff date for potentially disruptive 
merges into the master branches of all OPM modules that are involved in the 
2017.04 release is today. You may pick the time zone of your choice.

The master branches will be fully frozen for feature merges tomorrow and 
Thursday until release branches will be created, and they will stay "sluggish" 
until the release has been finalized. I may make an exception for PRs which are 
nominated in response to this e-mail, but only if these PRs are already open.

cheers
  Andreas

-- 
Just because a patch doesn't solve world hunger isn't really a good
reason to reject it.
-- Daniel Vetter

signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

Re: [Opm] Plan for the OPM 2017.04 release

[Andreas Lauser]

Hi Pål,

On Dienstag, 4. April 2017 13:27:49 CEST you wrote:
> > Cut-off date for code changes: Tuesday April 11, 2017. The master branches
> > of all modules will be closed for non-trivial, non-regression and non-
> > documentation merges after this, i.e., I'll be a jerk and personally
> > revert any merged code changes that do not fix serious problems
> > thereafter.
> I don't know if I understand you correctly here, but I hope you can clarify.
> Why can't every module simply make a release 2017-04 that is frozen from
> April 11, and then you can simply pick that one, and we can go on doing
> development as usual in the master branch?
>
> It's simple to just update the release and cherry-pick from master if need
> be.

that's basically the plan. judging from past experience, there will be some 
minor problems that must be fixed before the release and if larger changes are 
merged to master during this period, cherry-picking might become a pain. 
anyway, if everything works smoothly, the "hard" freeze for master will 
only be three days, and the "soft" one only two weeks. also, new PRs can be 
opened and existing ones can be worked-on during that period, they should just 
not be merged.
 
> This will also be a lot less invasive (and sane?).

I don't think that this plan is very invasive, and IMO it is certainly less 
restrictive than the Linux kernel's development model.

> But I probably misunderstood something.

maybe: my point is simply that you should not press Green from April 12 to 
April 15, and you should be careful from April 15 to April 25, i.e., try to 
not merge anything that kills cherry-picking.

cheers
  Andreas

-- 
Sacred cows make the tastiest hamburger.
-- Abbie Hoffman


signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

[Opm] Plan for the OPM 2017.04 release

[Andreas Lauser]

Dear OPM community,

As you may know, OPM aims for a biannual releases and it is time for the next 
one, dubbed -- surprise -- 2017.04. Since for some reason Yours Truly came out 
on top of our ludicrously hard process of selecting a release manager this 
time, I  thought it would be a good idea to inform the wider OPM community 
about the tentative release plan -- if you want any changes, let me know:

Modules involved in the release (maintainers are given in brackets):

  - opm-data (Alf Birger Rustad)
  - opm-common (Atgeirr Rasmussen, Bård Skaflestad, Arne Morten Kvarving, 
Joakim Hove, Robert Klöfkorn, Tor Harald Sandve, Andreas Lauser)
  - opm-parser (Joakim Hove)
  - opm-output (Joakim Hove)
  - opm-grid (Atgeirr Rasmussen, Robert Klöfkorn, Bård Skaflestad)
  - opm-material (Andreas Lauser, Robert Klöfkorn, Tor Harald Sandve)
  - opm-core (Atgeirr Rasmussen, Robert Klöfkorn, Bård Skaflestad)
  - ewoms (Andreas Lauser, Robert Klöfkorn, Tor Harald Sandve)
  - opm-simulators (Atgeirr Rasmussen, Robert Klöfkorn, Tor Harald Sandve, 
Andreas Lauser)
  - opm-upscaling (Arne Morten Kvarving, Atgeirr Rasmussen, Bård Skaflestad)

Guidelines for the release process:

- All maintainers: Please review all open pull requests and github issues for 
the modules which you feel responsible for.
- All maintainers: Update the CHANGELOG for your modules. You probably should 
have look at the changes since the last release. You can do this using the 
command `git log "master@{Nov 1, 2016}..master"`.
- Cut-off date for code changes: Tuesday April 11, 2017. The master branches 
of all modules will be closed for non-trivial, non-regression and non-
documentation merges after this, i.e., I'll be a jerk and personally revert 
any merged code changes that do not fix serious problems thereafter.
- Creation of the release/2017.04 branches: Thursday April 15, 2017. To 
simplify the bug hunting, the master branches are only open for merging non-
invasive code changes until the final version of the release is ready. 
Maintainers should use common sense to determine what is "non-invasive".
- Preparation of Debian/Ubuntu and RHEL packages packages and testing based on 
the release branches. Arne Morten Kvarving will be responsible for this.
- Tentative date for the final version of the release: Tuesday April 25, 2017. 
Depending on the outcome of the packaging/testing efforts, this may be delayed 
by a few days.
- A corresponding release of the  ERT libraries will also be created.
- After the release: Beer (or champagne or Coke if you prefer). The master 
branches are fully open again.

For your convenience, we've also put up that plan on our website:

http://opm-project.org/?p=848

cheers
  Andreas

-- 
Sacred cows make the tastiest hamburger.
-- Abbie Hoffman


signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

Re: [Opm] Two Phase Modelling

[Andreas Lauser]

Hi Pete,

On Mittwoch, 22. Februar 2017 05:44:37 CEST Pete Clinckemalie wrote:
> Is Flow now supporting 2-phase runs, in particular water-gas?

IIRC, gas-water simulations are not supported yet, proably not by flow_legacy 
and definitely not by flow_ebos. Both simulators support the oil-gas case, 
though, so getting them into shape should not be too much work, but it simply 
has not been a priority so far.

cheers
  Andreas

-- 
Sacred cows make the tastiest hamburger.
-- Abbie Hoffman

signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

Re: [Opm] PRT Files

[Andreas Lauser]

Hi Bob,

welcome to OPM!

On Donnerstag, 15. Dezember 2016 20:59:34 CET bobmerr...@mersep.com wrote:
> I'm pretty sure that the
> reservoir pressure is NOT 334; I have BHP constrants of 4800 (producer)
> and 5100 (injector).
> 
> So what is it?  If it's not what it says, are the volumes in place correct?

possibly, it's the pressure in bar instead of PSI: 4800 PSI are roughly 330 
bars...

cheers
  Andreas

-- 
In a sense, programming is all about what your program should do in the first 
place. The “how” question is just the “what”, moved down the chain of 
abstractions until it ends up where a computer can understand it, and at that 
point, the three words “multichannel audio support” have become those 9,000 
lines that describe in perfect detail what's going on.
-- Steinar H. Gunderson

signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

Re: [Opm] Version information?

[Andreas Lauser]

Hi,

On Montag, 14. November 2016 23:55:22 CET Roland Kaufmann wrote:
> On 19. Oct. 2016 at 10:45, Bernd Flemisch wrote:
> On 14. Nov. 2016 at 17:19, Andreas Lauser wrote:
> > include "opm/$MODULE/version.hpp"... but as far as I know, the
> > build system currently does not generate these headers
> 
> There was such a file opm/core/version.h, but it was removed with
> commit 7df248 in pull request 912.

I'm in favour of bringing it back. This time, I propose to add such a file for 
all OPM modules and auto-generate them from dune.module and git by the build 
system. the only potentially problematic issue I can see with this is that 
these auto-generated headers must be installed, but that is already done by 
opm-parser.

> An alternative way is to probe for the functionality needed, and
> have the build system put this into *your* config.h
> 
>CHECK_CXX_SOURCE_COMPILES("
>#include 
>int main (void) { Opm::Snafu snafu; return 0; }
>" HAVE_SNAFUCATION)
> 
> It may also be that the find_dune_version macro in
> UseDuneVer.cmake can be used to probe for the version of OPM
> modules; I haven't tried that.
>
> If the feature you need is part of your API, for instance you need
> to return two different types, then things get ugly fast: I guess
> the best way would have to be to generate a header with a
> typedef.

I suppose that's too complicated: I definitely wouldn't want to be forced to do 
this in order to use Dune and neither should external user OPM users be forced 
to resort to such measures IMO.

cheers
  Andreas

-- 
Measuring programming progress by lines of code is like measuring aircraft
building progress by weight.
-- Bill Gates

signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

Re: [Opm] Version information?

[Andreas Lauser]

Hi Bernd,

On Mittwoch, 19. Oktober 2016 10:45:25 CET Bernd Flemisch wrote:
> since Opm interfaces changed without deprecation period, I must have
> different code paths to support 2016.04 and 2016.10 at the same time. Is
> there a way to do this? I don't see any Opm version information written
> into config.h.

I guess you are looking for a way for external code to detect the version of 
OPM? (the OPM modules themselves obviously know which version they are. ;))

The build system provides dune.module files, so if you're using the dune build 
system, you may be able to use these. I suppose a better way would be to 
include "opm/$MODULE/version.hpp" and define the version macros therein, but as 
far as I know, the build system currently does not generate these headers...

cheers
  Andreas

-- 
Measuring programming progress by lines of code is like measuring aircraft
building progress by weight.
-- Bill Gates

signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

[Opm] Significant changes for the opm-simulators module ahead

[Andreas Lauser]

Dear OPM community,

We are currently in the process of merging and integrating a version
of the flow simulator that uses a more cache-friendly and significantly better
performing approach to assembling the residuals and Jacobians than the 
existing one. It has been prototyped for some time in the "frankenstein" 
branch of the opm-simulators module as some of you have doubtlessly noticed, 
and it is time to merge that branch into master soon.

Since this is merge constitutes a potentially disrupting change, we would like 
to inform the wider OPM community about our plans of how to proceed. That plan 
is currently as follows:

1. (already done) Renaming of the flow binary to flow_legacy, and make flow a 
symbolic link pointing from flow to flow_legacy.
2. November 18. Merging the "frankenstein" branch into the opm-simulators 
master branch. This introduces a new simulator called "flow_ebos" and makes the 
opm-simulators module depend on the eWoms module.
3. November 18 - December 9. Testing of flow_ebos to make sure it can 
completely replace flow_legacy, running all the same cases etc.
4. When all tests are successful, the "flow" symbolic link will be changed to 
point to "flow_ebos".
5. By January 2017. Testing should ensure that MPI runs correctly with 
flow_ebos (at this point called just called "flow"), so we will remove the 
separate mpi applications.
6. By March 2017. A solvent simulator based on new flow should be ready to 
replace the current flow_solvent.
7. By April 2017. A polymer simulator based on new flow should be ready to 
replace the current flow_polymer.

Thus we hope that we will have faster simulators of all required variants in 
time for the 2017.04 release.

Kind Regards
  Andreas (writing on behalf the OPM core developers)

signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

Re: [Opm] Difference between WellState::perfRates and WellStateFullyImplicitBlackoil::perfPhaseRates

[Andreas Lauser]

On Monday, September 26, 2016 12:35:09 PM Jørgen Kvalsvik wrote:
> Quick tip on how to convert from surface rate to reservoir rate?

simple answer: forget about it ;)

complicated answer for the reservoir-to-surface rate of the oil component:

\sum i in well
r_i,o * B_o,i / rho_o,ref + r_i,g*B_g,i*R_v,i

where "r" is the reservoir rate, "B" the formation volume factor, R_v the oil 
vaporization factor and rho_o,ref the oil surface density. (note that you need 
the reservoir rates of the individual cells that penetrate the well, i.e., the 
sum of the well does not do the trick. also be aware that in the case of cross 
flow the sign of the reservoir rates for individual cells can be the opposite 
of sign of the summed up rate.)

cheers
  Andreas

> 
> From: Opm  on behalf of Atgeirr Rasmussen
>  Sent: Monday, September 26, 2016 2:19:39 PM
> To: OPM Mailing List
> Subject: Re: [Opm] Difference between WellState::perfRates and
> WellStateFullyImplicitBlackoil::perfPhaseRates
> 
> The perfRates() vector contains *reservoir volume* total rates at the
> perforations, while the perfPhaseRates() vector contain *surface volume*
> rates per phase. So it is not a direct sum.
> 
> Atgeirr
> 
> 
> 26. sep. 2016 kl. 14.10 skrev Jørgen Kvalsvik
> mailto:jo...@statoil.com>>:
> 
> Hi,
> 
> What's the difference between these two vectors? Is perfRates just the sum
> of the pair/triples in perfPhaseRates?
> 
> 
> ---
> The information contained in this message may be CONFIDENTIAL and is
> intended for the addressee only. Any unauthorised use, dissemination of the
> information or copying of this message is prohibited. If you are not the
> addressee, please notify the sender immediately by return e-mail and delete
> this message.
> Thank you
> ___
> Opm mailing list
> Opm@opm-project.org
> http://opm-project.org/cgi-bin/mailman/listinfo/opm
> 
> 
> 
> ---
> The information contained in this message may be CONFIDENTIAL and is
> intended for the addressee only. Any unauthorised use, dissemination of the
> information or copying of this message is prohibited. If you are not the
> addressee, please notify the sender immediately by return e-mail and delete
> this message.
> Thank you

-- 
Measuring programming progress by lines of code is like measuring aircraft
building progress by weight.
-- Bill Gates

signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

Re: [Opm] Calculating ROIP and RGIP

[Andreas Lauser]

Hi,

On Mittwoch, 14. September 2016 19:06:42 CEST Joakim Hove wrote:
> [ OK - this is slightly emberrassing; but I have reached the limit of my
> understanding of the black-oil model. ]
> 
> 
> When calculating the summary quantities ROIP (Region oil in place) and RGIP
> (Region gas in place) we should sum up over the correct phase, and the
> amount of oil/gas in the "other phase":
> 
> I.e. RGIP  ~ sum( SGAS + RS(?)) and ROIP = sum( (1 - sgas + swat) + RV)
> 
> But RS and RV are not in the "saturation space". So what gives?

I think these quantities are only meaning- and useful in terms of component 
mass. (alternatively, you can say "surface volume of pure phases" if you 
prefer.) So my guess for ROIP is that you need the following sum over all 
cells i in region R:

ROIP = \sum_{i \in R} PV_i * (B_o,i / rho_o,ref * S_o,i + B_g,i*R_v,i *S_g,i) 

(with PV being the pore volume of the cell, B_alpha the formation volume 
factor of phase alpha, S_alpha its saturation and rho_o,ref as the density of 
oil at surface conditions.) 

cheers
  Andreas

-- 
Measuring programming progress by lines of code is like measuring aircraft
building progress by weight.
-- Bill Gates

signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

Re: [Opm] ERT cmake problem

[Andreas Lauser]

Hi,

On Thursday, August 11, 2016 06:39:43 AM Jørgen Kvalsvik wrote:
> You need to 'cd' into the build directory:
> 
> mkdir build
> 
> cd build
> 
> cmake ../devel

the repository layout of ERT is quite weird in my opinion (in the sense that 
it is non-standard), and when I first tried to compile it, I also fell on my 
nose because of it. Question: are there objections to switch to the standard 
directory structure? (basically this means moving everything in the 'devel' 
directory to the top level of the repository.) I volunteer to do the patch.

cheers
  Andreas

> 
> From: Opm  on behalf of XiaoYun Wang
>  Sent: Thursday, August 11, 2016 7:36:50 AM
> To: opm@opm-project.org
> Subject: [Opm] ERT cmake problem
> 
> Hi
> 
> I try to install ERT.ecl in my PC, redhat 6.4 with cmake 3.6.1
> 
> After I download ert-master,
> 
> mkdir build
> cmake ../devel
> 
> there something wrong with
> [root@shltd-s1 build]# pwd
> /software/OPM/ert-master/build
> [root@shltd-s1 build]# cmake ../devel
> CMake Error at src/CMakeLists.txt:195 (set_target_properties):
>   set_target_properties called with incorrect number of arguments.
> 
> 
> fatal: Not a git repository (or any of the parent directories): .git
> CMake Warning (dev) in CMakeLists.txt:
>   No cmake_minimum_required command is present.  A line of code such as
> 
> cmake_minimum_required(VERSION 3.6)
> 
>   should be added at the top of the file.  The version specified may be
> lower if you wish to support older CMake versions for this project.  For
> more information run "cmake --help-policy CMP".
> This warning is for project developers.  Use -Wno-dev to suppress it.
> 
> -- Configuring incomplete, errors occurred!
> See also "/software/OPM/ert-master/devel/CMakeFiles/CMakeOutput.log".
> [root@shltd-s1 build]#
> 
> Would you please help me, many thanks.

-- 
Measuring programming progress by lines of code is like measuring aircraft
building progress by weight.
-- Bill Gates

signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

Re: [Opm] New opm-repo

[Andreas Lauser]

Hi,

On Tuesday, March 15, 2016 08:47:52 AM Alf Birger Rustad wrote:
> Today, writing results is a performance bottleneck flow.

as far as I can see, there is not much which can be done on that front if you 
continue to insist on using ECL compatible files for output of parallel 
simulations. (these are inherently sequential file formats and thus the only 
way to accelerate writing them is to accelerate the sequential code.)

cheers
  Andreas

> 
> From: Opm [opm-boun...@opm-project.org] on behalf of Joakim Hove
> [joakim.h...@gmail.com] Sent: Monday, March 14, 2016 6:54 PM
> To: opm@opm-project.org
> Subject: [Opm] New opm-repo
> 
> Hello;
> 
> we have just created a new repository: opm-output:
> https://github.com/OPM/opm-output - the new repository should contain
> routines for generating output from opm simulators. Currently there is zero
> actual code in the repository, but the necessary (absolute) minimum cmake
> support is in there already.
> 
> With this PR: https://github.com/OPM/opm-common/pull/86 opm-autodiff will
> depend on the new repository. I encourage you all to fork, clone and
> "build" the opm-output repo asap; then I guess we will merge build system
> change actually creating a dependency in a couple of days?
> 
> 
> The initial plan is to move the outputwriter code from opm-core, and then
> take it from there.
> 
> 
> Joakim


-- 
Another way to put it: a team full of hammers will go around looking
for nails. A team that’s a whole toolbox might figure out what really 
needs doing.
-- Havoc Pennington

signature.asc
Description: This is a digitally signed message part.
___
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

Re: [OPM] Supported DUNE versions / libtool libraries

[Andreas Lauser]

Hi,

On Tuesday 25 August 2015 11:00:35 Bård Skaflestad wrote:
> On 25/08/15 10:52, Markus Blatt wrote:
> 
> [Snip background]
> 
> > I am wondering whether we should stop supporting autotools for
> > downstream modules and stop creating *.la files. (I guess this is
> > untested in any case). This means enforcing dune >=2.3 which comes
> > with CMake.
> 
> I have no particular preference for Autotools, so I guess we at least
> have to take convenience and practicality into account.  Can OPM users
> (on Linux) *easily* obtain pre-built packages for Dune 2.3 on their
> distributions?  What is the cost/benefit ratio to the OPM project to
> continue supporting 2.2.x?  How far away is Dune 2.4 and do we have a
> reasonable upgrade path to that?

In my opinion, Dune 2.2 support should be dropped because Dune 2.3 has been 
around since 1.5 years and I consider it unlikely that anyone wants to use OPM 
2015.10 with a Dune version from mid-2012...

Also, I have a slightly off-topic question, but since this thread is about 
autotools and cmake it may fit anyway: the last time I tried to mix the Dune 
master's CMake build system with the OPM one, dunecontrol badly fell on its 
nose (i.e., you have to set USE_CMAKE=no in your .opts file). since IIRC Dune 
decided to remove their autotools system for 2.4+1, I'd like to inquire what 
the current plans for OPM are in this regard?

cheers
  Andreas

-- 
You may now understand why I made a new jug of coffee. I had torture-tested 
this with fairly much every pathology I could think of. And you've managed to 
break it with the *default* case. Congratulations. You just made me cry.
-- David Woodhouse

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

Re: [OPM] Refactoring of the fully implicit solver class

[Andreas Lauser]

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 seriously, I think that code generation is nice if everything works as 
intended, but if it doesn't, you'll have to deal with really hard to find and 
hard to debug bugs in the code generator.

cheers
  Andreas

-- 
If your text editor can defeat you at chess, it might be a bit 
overengineered.
  -- Jon Cruz, reflecting on the power of Emacs. 

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

Re: [OPM] Installation sub directories

[Andreas Lauser]

Hi,

On Thursday 21 May 2015 12:45:04 Alf Birger Rustad wrote:
> > sibling builds make it hard to have a distributed build system, i.e., that
> > every OPM module ships its own build system modules. In turn, I think
> > that this is a strict necessity for the buildsystem to be even considered
> > for external projects to be used.
>
> This sounds like a strong technical reason for abandoning the sibling build.
> However, haven't we already left the distributed model when introducing the
> opm-cmake repository, or have I misunderstood something?

Maybe it was me who misunderstood it, but my view is that the 
opm-cmake  based build system in it current form uses almost the same approach 
as the one used for the 2015.04 release. The only difference is that the build 
system is in a single centralized (and thus much more easily maintainable) 
place instead of having all its files verbatimly copied to all repositories (or 
sometimes not, which is the cause of much of the hilarity which was to be had 
with the build system before opm-cmake).

As far as I see it, opm-cmake is thus the first step of the build system 
refactoring. Step two is to make the build system federated, i.e., it becomes 
possible to ship the build system parts which are specific to an OPM module 
with only the affected repository itself, i.e., no copies would be needed 
anymore and no "central" repositories would need to be bugged if something 
changes in these parts.

If I understood Joakim correctly, the sibling build feature is the prime 
blocker for step 2. (I could be wrong, though.)

cheers
  Andreas

-- 
If your text editor can defeat you at chess, it might be a bit 
overengineered.
  -- Jon Cruz, reflecting on the power of Emacs. 

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

Re: [OPM] Installation sub directories

[Andreas Lauser]

Hi,

On Thursday 21 May 2015 08:54:18 Alf Birger Rustad wrote:
> First of all, I also want to thank Joakim for bringing up the discussion 
> before making changes. My thoughts are as follows:
> > Currently my focus is on removing the sibling-build features.
> 
> This was discussed at the OPM meeting, and my recollection from the
> discussion on sibling builds is -a majority of developers use the feature
> -it does not add significant complexity when determining which
> libraries/binaries are actually linked -it is not a significant maintenance
> burden to keep
> With the conclusion that we keep it.

I remember this discussion a bit differently, but that probably does not matter 
too much. (as far as I remember it, the conclusion was that we remove sibling 
builds, but that some "meta-build" tool gets added before this is done.)

From my personal perspective, the main benefit of getting rid of the sibling 
build feature is that -- as far as I can see -- sibling builds make it hard to 
have a distributed build system, i.e., that every OPM module ships its own 
build system modules. In turn, I think that this is a strict necessity for the 
buildsystem to be even considered for external projects to be used. 

cheers
  Andreas

-- 
If your text editor can defeat you at chess, it might be a bit 
overengineered.
  -- Jon Cruz, reflecting on the power of Emacs. 

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

Re: [OPM] Installation sub directories

[Andreas Lauser]

Hi,

On Wednesday 20 May 2015 22:59:39 Bård Skaflestad wrote:
> What, specifically, do you mean by "remove sibling build feature"?
> 
> Will we no longer support having multiple opm-${module} directories checked
> out in a single directory, do (more or less) active development on all of
> them and have the build output in a completely separate tree?  I don't care
> if it's difficult, I care if it will be possible at all.

as far as I understood, what you need will continue to be possible by 
explicitly specifying -D${MODULE}_ROOT=$FOO to cmake for all prerequisite 
modules of the module which you want to compile. if you're too lazy to do this 
manually (like me), you can use dunecontrol.

cheers
  Andreas

-- 
If your text editor can defeat you at chess, it might be a bit 
overengineered.
  -- Jon Cruz, reflecting on the power of Emacs. 

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

Re: [OPM] Logging

[Andreas Lauser]

Hi,

On Monday 15 December 2014 17:54:15 Jørgen Kvalsvik wrote:
> On 12/14/2014 09:56 PM, Joakim Hove wrote:
> > earlier this autumn Andreas submitted a ParserLog class which has been
> > used in the Parser for some time. I would now like to promote this to a
> > general logging facility for OPM. I have thought quite a lot about it,
> > but not implemented much[1]. I will share my thoughts below, and hope
> 
> > you will comment:
> I'd just like to pitch in one more consideration: do we really need to
> roll our own logging implementation? Wouldn't boost's logging library be
> enough? It has capabilities such as multiple backends, and is far less
> for us to maintain.

I suppose this depends on whether you consider boost as a stop-gap measure for 
stuff which is not yet available in the oldest supported compiler or if you 
would like to use it as much as possible. (I'd vote for the first option, we 
had our fair share of boost-related troubles already and logging is not soo 
terribly complicated...)

cheers
  Andreas

-- 
the unix philosophy: do 90% of one thing, and barely do it adequately
-- Adam Jackson

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

Re: [OPM] Logging

[Andreas Lauser]

Hi,

On Monday 15 December 2014 12:21:23 Atgeirr Rasmussen wrote:
> 15. des. 2014 kl. 12:50 skrev Joakim Hove :
> > - In my opinion, just renaming the current ParserLog class to OpmLog (or
> > Opm::Log) is a not so smart idea, because this class' API is very much
> > tailored to the parser module (what is the filename and the line number
> > in a general purpose context? the source file location of the call? not
> > really.)
> > 
> > Well – the rename is certainly not sufficient; my idea was just to get
> > that “out of the way”  - and then the Log implementation could be changes
> > silently in the Parser for some time without inducing downstream
> > breakages – but your points are certainly valid.
> I agree that such things as line numbers (of a deck in this case) may be a
> bit specific, but there is no reason a general facility cannot support
> this, especially with a few helper functions (for simple and consistent
> message formatting for example).

I think you slightly misinterpreted me: A general logging facility is valuable 
IMO, but its sole purpose should be to distribute the messages (each with a 
priority) from any frontent to the delivery mechanisms (i.e., backends). The 
frontends and the backends can be instances or singletons or whatever you 
prefer...

> > Static message priorities make things like
> > 
> > Opm::Warning << "foo!" ;
> > 
> > easy. I cannot really see how this can be done using dynamic ones...
> > 
> > I agree that Opm::Warning would be nice – but no that is not going to
> > play. Be it dynamic or static I really think the final filtering will be
> > based on a bitmask.
> I do not see why we cannot do someting like this (perhaps
> Opm::Logger::Warning() << "foo" will be better though).
> 
> The use of Warning communicates the intent of the message sender, and the
> filtering will happen downstream in the process, when all connected
> backends are asked: "do you want to do something about a Warning message?"
> or something like that. They could even use a generalized polymorphic
> filtering mechanism as Andreas suggests (a good idea, but maybe also a bit
> of over-engineering at this point).

I agree on the over-engineering ;). The point was that this should be the 
direction to look at because good software design should try to separate 
mechanism ("backend") from policy ("filters")...

cheers
  Andreas

-- 
the unix philosophy: do 90% of one thing, and barely do it adequately
-- Adam Jackson

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

Re: [OPM] Logging

[Andreas Lauser]

Hi,

On Monday 15 December 2014 11:50:31 Joakim Hove wrote:
> - Why does the ParserLog class need to be renamed at all? I'd rather see it
> to be a frontend for the Opm::Log class which itself can be a singleton
> that acts as a plumbing layer between frontends and backends
> 
> 
> 
> A instance based frontend to the singleton?!


yep, why not? I suppose that other "singleton like" objects like std::cout do 
get use a lot by instantiated objects...

> - wouldn't it be better to wait until the Big Module Hierarchy Refactoring
> 
> (TM) is done so that the parser module does not need to host such general-
> purpose infrastructure code? I mean, the dependencies between the modules
> are already confusing enough as they are...
> 
> 
> 
> Well moving the log class out of the Parser/ subdirectory was in preparation
> for the "Big Module Hierarchy Refactoring" (BMHR). It should be absolutely
> trivial to rip the log implementation out of opm-parser and into opm-xxx.

true. the point was more that this confuses things until the refactoring has 
been started. (a period which I hope includes a release just before the 
refactoring frenzy...)
 
> Static message priorities make things like
> 
> Opm::Warning << "foo!" ;
>
> easy. I cannot really see how this can be done using dynamic ones...
> 
> 
> I agree that Opm::Warning would be nice - but no that is not going to play.
> Be it dynamic or static I really think the final filtering will be based on
> a bitmask.

yeah, but if I don't see things more complicated than strictly required, 
"dynamic log levels" and "bitmask" are mutually exclusive. to me, "dynamic 
logging" means to use something like "std::set"...

cheers
  Andreas

-- 
the unix philosophy: do 90% of one thing, and barely do it adequately
-- Adam Jackson

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

Re: [OPM] Logging

[Andreas Lauser]

Hi,

I guess it's my turn to give two and a half cents of worthless opinions: 
First, I think having a general logging facility is a good idea but I've got a 
few technical and a more philosophical issues. Technical things first:

- In my opinion, just renaming the current ParserLog class to OpmLog (or 
Opm::Log) is a not so smart idea, because this class' API is very much 
tailored to the parser module (what is the filename and the line number 
in a general purpose context? the source file location of the call? not 
really.)
- Dynamic log levels can be done, but I think if they only add a tiny bit of 
API-level inconvenience compared to static log levels, I think they are not 
worth it.
- Why does the ParserLog class need to be renamed at all? I'd rather see it to 
be a frontend for the Opm::Log class which itself can be a singleton that acts 
as a plumbing layer between frontends and backends. (the compiler guys call 
this a "middleend" but that's about the most horrible name I've ever stumbled 
upon in CS ;))

Now the non-technical concern:

- wouldn't it be better to wait until the Big Module Hierarchy Refactoring
(TM) is done so that the parser module does not need to host such general-
purpose infrastructure code? I mean, the dependencies between the modules are 
already confusing enough as they are...

The rest of my comments are inline:

On Monday 15 December 2014 10:12:21 Joakim Hove wrote:
> > 1.   The logging facility should be implemented as a singleton, i.e.
> > it should not be necessary to pass in a reference to a log class to all
> > methods/functions which might want to add a log message.
> I think this is a good idea, and in line with common usage of the singleton
> pattern. However, we should make a few things clear up front:
> 
> 1a. This is not a universal logging facility in that we want to cover every
> possible use in any possible code, but tailored to what we need in OPM.
> 
> 
> 
> Certainly - that was also part of the reason the name OpmLog gave slightly
> positive connotations.

I agree with Joakim that calling it OpmLog does not impose the impression that
it is a system-wide logging facility like journald or rsyslog...

> 1b. The logging facility should not be used for all communication with the
> user, only warnings/errors etc. I think that regular output should not be a
> part of this, even though that prompts more questions,
> 
> 
> 
> Why not - that is my ambition? At least in a production setting the
> simulator will be run in queue system and all output must/will be
> redirected to a file. By having multiple backends we can send messages many
> places, including stdout with a common use pattern in the client code. My
> (maybe unrealistic ??) hope is that the logging system is so good that Joe
> Developer will rather sprinkle the code with a couple of
> "Log::addMessage()" instead "std::cout" while debugging/developing.

I think you both have different points: As far as I understand Arne does not 
want
it to be used for interactive user communication or a non-interactive which the
user *must* read (i.e., fatal errors)...

> > 3.   The log levels, i.e. Warning, Error and so on should be dynamic;
> > and each backend should have it's own loglevel.
> I do not quite understand what you mean by these being dynamic, and I do not
> think different backends should define their own. These levels are to be
> used in client code (simulators) where I can imagine such a thing as
> "Newton failure, report this at Warning level" is something the client
> would like to do. If the way to specify a Warning changes with the backend
> then there is no polymorphism here, so I fail to see how that could be
> done.
> 
> 
> 
> What I mean; (which might still be a bad idea ?) is :
> 
> 
> 
> 1.   The global log handler manages a set of log levels (i.e. Warning,
> Error, Message, ) dynamically. The default will of course be built in,
> but it should be possible from clientcode to say something like:
>
> size_t message_id = Log::addMessageType();
> 
> ...
> 
> ...
> 
> Log::addMessage(message_id , "This message is tagged with the new message_id
> tag");


Static message priorities make things like

Opm::Warning << "foo!" ;

easy. I cannot really see how this can be done using dynamic ones...


> 2.   When a backend is instantiated it is instantiated with a mask of
> the message types it accepts, i.e.
> 
> 
> 
> ErrorBackend backend( Log.ERROR );
> 
> MessageBackend backend( Log.ERROR || Log.MESSAGE || message_id );// Will 
> include the new message type

That should probably better be the job of "filters" which could be simple 
classes
which exhibit an method

bool acceptMessage(int priority, LogFrontend *frontend, const std::string &msg);

combining arbitrary filters with arbitrary backends is quite simple in this 
scheme...

> Each backend will make it's own decision whether to include
> the message.

that would make the backends quite convoluted as some bac

Re: [OPM] About defaults ...

[Andreas Lauser]

Hi,

On Wednesday, December 10, 2014 13:23:38 Joakim Hove wrote:
> Since I confess to be guilty of having started this, I guess
> you should be aware of my position as well:
> 
> 
> 
> Good - thank you.
> 
> 
> 
> I think that it is beneficial to catch errors which are caused by trying to
> assign a default value to non-defaultable items as soon as the issue is
> detected. My main points are that this makes the code more robust (because
> the binary won't crash after possibly hours of execution if it suddenly
> tries do accessing such an invalid item) and it makes the higher level code
> simpler and easier to maintain (because it can rely on the fact that all
> non-defaultable items are present after the deck has been successfully
> parsed).
> 
> 
> 
> The phrase: "because the binary won't crash after possibly hours of
> execution if it suddenly tries do accessing such an invalid item" is quite
> misleading for my position; if an item without default is missing it should
> raise an exception when forming the EclipseState - i.e. a long time before
> any simulation has started.> However - the underlying assumption behind that
> argument (which I had frankly forgotten) is of course that all higher level
> code is accessing the deck properties through the EclipseState object and
> not the deck directly. That is certainly the direction I want to move
> things - but we are not there yet.

yep, 100% agreement from my side :)

cheers
  Andreas

-- 
the unix philosophy: do 90% of one thing, and barely do it adequately
-- Adam Jackson

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

Re: [OPM] About defaults ...

[Andreas Lauser]

Hi,

Since I confess to be guilty of having started this, I guess you should be 
aware of my position as well: I think that it is beneficial to catch errors 
which are caused by trying to assign a default value to non-defaultable items 
as soon as the issue is detected. My main points are that this makes the code 
more robust (because the binary won't crash after possibly hours of execution 
if it suddenly tries do accessing such an invalid item) and it makes the 
higher level code simpler and easier to maintain (because it can rely on the 
fact that all non-defaultable items are present after the deck has been 
successfully parsed).

Having said that, I can also see Joakim's point of not wanting to add "bogus" 
defaults to the JSON files just to be able to terminate keywords early. As far 
as I can see, this only affects the property modifier keywords (ADD, COPY, 
MULTIPLY...) though, and I'd prefer to bite that bullet than placing an "if()" 
around every single access to items in the higher level code...

cheers
  Andreas

On Tuesday, December 09, 2014 18:33:20 Joakim Hove wrote:
> Sorry I forget one aspect:
> 
> 
> *Parser & defaults*: The default values are used in two cases:
> 
> 
>1. If the deck contains explicit default markers of the form 'n*'
>2. If a record is terminated prematurely.
> 
> If the Json configuration has a default value specified for the item(s) in
> question it is simple - the deck item is initialized with the default value
> and everything is hunka dory. However - what to do if the item does not
> have a default value specified, e.g.
> 
> 
> WELSPECS
> 
> /  --- A fully defaulted record
> 
> /   -- Keyword termination
> 
> 
> This keyword clearly does not make much sense, and Eclipse will abort
> during the parse stage. I want the parser to accept this, and then let the
> Schedule constructor throw an exception when we are trying to access the
> unitialized values of the WELSPECS keyword. For the example at hand this
> might seem a bit relaxed - and the Eclipse behaviour more sensible; however
> there many cases where the actual default value can not be used (i.e. use
> -1 to indicate no limit for ...) and the calling scope must take care in
> differentiating between a valid -1 and a defaulted -1; in addition the Json
> configuration must have many default values which can not really be used as
> such - they only serve as markers of default behaviour; I would prefer to
> avoid filling up the configuration with such invalid values.
> 
> joakim

-- 
the unix philosophy: do 90% of one thing, and barely do it adequately
-- Adam Jackson

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

Re: [OPM] New repo opm-utilities

[Andreas Lauser]

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

Re: [OPM] New repo opm-utilities

[Andreas Lauser]

Hi,

On Wednesday, November 19, 2014 16:16:02 wireless wrote:
> On 11/19/14 14:28, Andreas Lauser wrote:
> > I fully agree: For developers it is much better to keep things that are
> > doing different things separately and users are better served by `apt-get
> > install opm` (or whatever the equivalent of this is on Your Favorite
> > Distribution/OS (TM)).
> 
> Huh?  On gentoo I have these modules:

maybe. but some distributions have the concept of meta packages which pull in 
everything. (at least debian and openSUSE have them, openSUSE calls them 
"Patterns" if I'm not mistaken.)

> What you currently have is what professional software developers call
> "a kludge".

welcome to real life ;) (That's also a kludge, BTW. Starting at the DNA 
level...)

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

Re: [OPM] New repo opm-utilities

[Andreas Lauser]

Hi,

On Wednesday 19 November 2014 11:35:08 Jørgen Kvalsvik wrote:
> On 2014-11-19 11:11, Bård Skaflestad wrote:
> > On 2014-11-19 17:41, Jørgen Kvalsvik wrote:
> >> 3. Increased maintenance cost of the build system, cmake modules
> >> especially.
> > 
> > http://rolk.github.io/2013/09/23/build-system-sync/
> 
> Wouldn't it be better if this wasn't necessary?

I consider this a unfortunate design decision for the build system which was 
made about 1.5 years ago, but _not_ a fundamental problem with using separate 
repos for separate modules. What this mandates instead is a distributed build 
system akin the DUNE one, in my opinion.
 
> > Were it not for the fact that opm-core depends on opm-parser I would
> > be able to download "only" opm-core and get access to powerful grid
> > processing routines, an implementation of mimetic discretisations
> > (somewhat languishing but nevertheless working), partial support for
> > the multi-scale mixed finite-element method, time-of-flight solvers
> > based on the reordering technique, explicit and implicit solvers for
> > two-phase incompressible transport problems.  In essence, fundamental
> > tools for doing simple calculations in porous media applications.
> 
> git clone -b opm-core github.com:opm-project

... and you and up at exactly the current situation, but you have to specify 
the modules via branch names ;)
 
cheers
  Andreas

-- 
In the GNU Project, we do not "obey" standards. Rather, we take
them into account when judging what is best for the program to do.
— Richard Stallman

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

Re: [OPM] New repo opm-utilities

[Andreas Lauser]

Hi all,

On Wednesday 19 November 2014 18:11:03 Bård Skaflestad wrote:
> On 2014-11-19 17:41, Jørgen Kvalsvik wrote:
> > This is what I propose instead:
> > 
> > Remove the repositories all-together and replace with a single opm repo.
> 
> So, you're proposing to undo the (more or less) careful separation of
> responsibilities of user-facing features into autonomous but related
> modules for the sake of build-time convenience for the *very* few OPM
> developers?  That won't happen as long as I have any say in the matter.

I fully agree: For developers it is much better to keep things that are doing 
different things separately and users are better served by `apt-get install 
opm` (or whatever the equivalent of this is on Your Favorite Distribution/OS 
(TM)).

> > For reference, the Linux kernel, which is a much larger project than
> > opm, only use one repo.
> 
> Clients are expected to use the entire Linux tree as whole when doing
> anything with the Linux sources.  That assumption doesn't hold in the
> case of OPM.

Note that Jørgen's argument equally applies to the whole software stack of the 
OS: Put the kernel, the C library, the compiler, the GUI and whatnot into one 
giant repo and compiling the whole thing gets much simpler. (now, find the 
mistake. ;))

cheers
  Andreas

-- 
In the GNU Project, we do not "obey" standards. Rather, we take
them into account when judging what is best for the program to do.
— Richard Stallman

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

Re: [OPM] non isothermal multiphase flow for thermal remediation

[Andreas Lauser]

Hi Jean,

On Sunday, October 26, 2014 17:23:19 Jean Francois Leon wrote:
> Thanks for your input
> Yes we are speaking of 3 phases compositional model here
> I both read ewoms and dumux manuals and from that reading alone [ no first
> hand experience and no interaction with people using it until today..], it
> seemed to me that the compositional and non isothermal models were more
> advanced in ewoms than in dumux.
> Did I made a mistake?

Nope, you're right: Even if eWoms and Dumux emerged from the same code base, 
technically they're now more like cousins than brothers. I think for your use 
case it's possible to use both, because that was one of the initial 
applications for which these codes were written. In the following, I can only 
speak for eWoms, since I haven't done anything using Dumux for ages.


For eWoms there's not much of a problem implementing a three phase, four 
component problem including an energy equation -- you can even switch between 
the primary variable switching (PVS) and the non-linear complementarity 
problem (NCP) based model by changing a single line of code. (in fact the same 
applies if you want to enable molecular diffusion, if you want to try out 
different linear solvers or preconditioners, or use a velocity model different 
from Darcy's law like a Forchheimer approach.) In my experience, the MPI 
parallelization also works quite smoothly and you can even use thread 
parallelization based on OpenMP (thread parallelization is currently only 
available for linearization but not the linear solvers, though.)


If you want to give eWoms a shot, I'll be happy to help out, but my 
recommendation is that you use the eWoms and OPM master versions from git 
because the last OPM release (which was also the latest eWoms release) 
currently feels like it was done during the stone ages. Maybe we should 
release soon?!

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

Re: [OPM] opm-parser-git requires ert-git, but makefile does not reflect this.

[Andreas Lauser]

Hi Jørgen,

On Wednesday 03 September 2014 12:52:58 Jørgen Kvalsvik wrote:
> Building the latest master HEAD (4fa0ca9) of opm-parser without using
> ert-git breaks, and the makefile does not reflect this.
> 
> The commit in ert in question is this
> https://github.com/Ensembles/ert/commit/499587ad9608d7648f16f4f391c5ceb1b117
> dcda along with it's child commit
> https://github.com/Ensembles/ert/commit/28ea53a159b7195ff74339ff1ed6379c933a
> 9563. The corresponding change in opm-parser is this:
> https://github.com/OPM/opm-parser/commit/4debbbce94d99b614059c1ef6d157c351b7
> 50a99 which adds the bool flag to the function call.
> 
> A problem is obviously that this patch has yet to be merged into a
> release version, so checking against 1.7 won't make a difference.

The assumption is that if you use the latest master version of OPM, you also 
use the latest master version of ERT. (they are developed somewhat 
synchronously and some of the relevant people are involved in both projects.) 
This problem will disappear for the next released version...
 
> Suggestions to a solution to this? Obviously compiling ert-git would
> work, but the makefile is still in a somewhat fragile state at this
> point and would probably have to require a minimum ert version quite
> soon.

yeah, the joys of build systems seem to be unfathomable...

(the solution is probably to just wait for the next releases of the projects.)

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

Re: [OPM] Grid interface

[Andreas Lauser]

Hi,

On Wednesday 27 August 2014 11:46:48 Andreas Lauser wrote:
> you forgot an important point:
> 
> On Wednesday 27 August 2014 10:03:06 robert.kloefk...@iris.no wrote:
> > A + B) build an interface that allows for both grids (GridHelpers)
> > 
> >   pros: - everybody is happy? (fair to Norwegian standards ;-))
> >   
> > - ?
> >   
> >   cons: - maintenance for two grid implementations instead of one plus
> >   
> >   the maintenance for the interface implementation
> > 
> > - it is unlikely to come up with a better solution than the
> > 
> >   DUNE interface in a short period of time (say a year)
> 
> - the GridHelpers approach always needs to implement a smallest denominator
> API of CpGrid and UnstructuredGrid, so it would be 'worst-of-both-worlds'.
> 
> 
> While I could live with both A or B (but I personally have a preference for
> A)

sorry, typo: my preference actually is B (i.e., all in on DUNE grid interface)

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

Re: [OPM] Grid interface

[Andreas Lauser]

Hida,

you forgot an important point:

On Wednesday 27 August 2014 10:03:06 robert.kloefk...@iris.no wrote:
> A + B) build an interface that allows for both grids (GridHelpers)
>   pros: - everybody is happy? (fair to Norwegian standards ;-))
> - ?
>   cons: - maintenance for two grid implementations instead of one plus
>   the maintenance for the interface implementation
> - it is unlikely to come up with a better solution than the
>   DUNE interface in a short period of time (say a year)

- the GridHelpers approach always needs to implement a smallest denominator 
API of CpGrid and UnstructuredGrid, so it would be 'worst-of-both-worlds'.


While I could live with both A or B (but I personally have a preference for 
A), IMO it is much preferable to remove one implementation than trying to 
somehow cater both (even if the one which gets removed ends up being the DUNE 
grid)...

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

Re: [OPM] Warning - stricter default handling

[Andreas Lauser]

Hi,

On Monday 25 August 2014 16:38:51 Joakim Hove wrote:
> When: https://github.com/OPM/opm-parser/pull/289 is merged the parser is
> stricter with respect to missing defaults. If you ask for a property which
> had been defaulted/not set in the deck you will get the default value; if
> no default value is set in the Json config the Deck will throw - previously
> that used to give a "default default" - i.e. typically a representation of
> zero.

note that the same applies to

https://github.com/OPM/opm-parser/pull/288

after this, you'll get an exception from Opm::EclipseState if the deck does 
not specify a mandatory section or violate the order documented in the Eclipse 
Reference Manual...

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

Re: [OPM] Grid interface

[Andreas Lauser]

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

Re: [OPM] Rename parser?

[Andreas Lauser]

Hello, World!

On Wednesday, July 16, 2014 08:02:24 Joakim Hove wrote:
> After reviewing: https://github.com/OPM/opm-core/pull/560 I though that
> maybe the EclipseWriter stuff also should be moved to the parser? The
> parser is already a quite fat and heavy 'parser' - and maybe renaming it to
> something like EclipseInter / EclipseIO / ...; or alternatively we could
> say that Eclipse is the baseline and call it Opm-IO?

opm-io is a good name in my opinion, but it implies that the "o" part is going 
to be added. For that, I think that the current EclipseWriter class is too 
entangled with the other opm-core classes, but maybe it's fit to be moved over 
after another two or three refactorings/cleanups...

> When we really have
> plenty of time we could implement opm-core / opm-autodiff based on an
> abstract class Opm::ReservoirState - where Parser::EclipseState is derived
> from Opm::ReservoirState - but that is 2016 material I guess.
>
> Anyway - I hope the rename can be a topic of discussion for the autumn?

I concur. I also think that we should put the main focus of the next-after-
next release on redefining the scope of the individual modules and their 
relation amongst each other. (E.g. it's currently hard to explain why opm-core 
depends on opm-parser and not the other way around.)

cheers
  Andreas

-- 
Notice: "String" and "Thread" are the same thing to non-computing
people.
— Programming.com

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

Re: [OPM] FW: Boost.Regex and libstc++ debug mode

[Andreas Lauser]

Hi,

On Tuesday 08 July 2014 11:15:04 Bård Skaflestad wrote:
> On Tue, 2014-07-08 at 10:46 +0200, Andreas Lauser wrote:
> > We now get a test failure in opm-parser because of this on Arne's machine,
> 
> I too get a failure in "runIntegrationTests".  The direct cause of the
> failure is line 123 of runIntegrationTest.cpp,
> 
> > // user defined quantity. (regex needs to be used.)
> > BOOST_CHECK(parser->canParseDeckKeyword("WUFOO"));
> 
> I don't know what regular expression this is supposed to match.

The WU.+ keywords tag user-defined well quantities for output in the summary 
section. They are defined by the WELL_PROBE parser keyword.

> And as for grammars, you can select those--options being Perl 5, basic,
> and extended for Boost.Regex and ECMA, basic, extended, grep, egrep, and
> awk for std::.  None of the std:: options match Roland's pattern though.

I think for the opm-parser use case, the most simple option is sufficient. The 
only catch is that the syntax (basically where to put backslashes and where 
not) should stay the same.

cheers
  Andreas

-- 
Notice: "String" and "Thread" are the same thing to non-computing
people.
— Programming.com

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

Re: [OPM] FW: Boost.Regex and libstc++ debug mode

[Andreas Lauser]

Hi,

On Tuesday 08 July 2014 09:57:42 Roland Kaufmann wrote:
> On 2014-07-07 16:24, Joakim Hove wrote:
> > libstdc++ comes in a DEBUG version which is linked in when
> > –DGLIBCXX_DEBUG is used.
> 
> On 2014-07-07 16:33, Andreas Lauser wrote:
> > as a work-around for newish (>= GCC 4.9 ?) compilers, we could modify
> > the build system to check if std::regex is supported and if yes, use
> > that.
> 
> On 2014-07-07 17:14, Bård Skaflestad wrote:
> > Just for the record, std::regex appears to be available on GCC 4.7
> > too. I don't know how complete that support is, though.
> 
> std::regex is in GCC 4.6.3, too, sort of.

sort of, right ;)

We now get a test failure in opm-parser because of this on Arne's machine, 
which I suspect uses GCC 4.7 (right, Arne?):

http://www.opm-project.org/CDash/viewTest.php?onlyfailed&buildid=21857

I.e., I am now looking for a valid regular expression which fails on these 
oldish compilers...

> Note that Boost::regex follows Perl 5 conventions, whereas std::regex
> follows ECMAScript conventions, so there are some subtle differences
> between them, e.g.:
>
>  #include 
>  #include 
>  #include 
> 
>  int main () {
>  std::string filename = "foo.*";
>  std::string pattern  = "foo\\.\\*.*?";
>  std::regex std_rgx (pattern);
>  boost::regex boost_rgx (pattern);
>  std::cout << "std matches: " <<
>  std::regex_match (filename, std_rgx) << std::endl;
>  std::cout << "boost matches: " <<
>  boost::regex_match (filename, boost_rgx) << std::endl;
>  return 0;
>  }
> 
> which on my setup (Ubuntu 12.04, GCC 4.6.3, Boost 1.46) returns
> 
> std matches: 0
> boost matches: 1
> 
> (reportedly libc++ also have variations from libstdc++ in std::regex,
> but I don't have the Mac running here, so I'm unable to verify that),
> implying that there is possibly one more permutation to test.

feel free to add more patterns to the test, it's appreciated. Bear in mind 
though, that the primary purpose of this test is to determine if std::regex is 
usable for opm-parser and not whether it is feature complete...

cheers
  Andreas

-- 
Notice: "String" and "Thread" are the same thing to non-computing
people.
— Programming.com

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

Re: [OPM] FW: Boost.Regex and libstc++ debug mode

[Andreas Lauser]

Hi,

On Monday 07 July 2014 14:24:02 Joakim Hove wrote:
> Hmmm;
> 
> 
> 
> a minor Google exercise turned up this:
> https://svn.boost.org/trac/boost/ticket/5911 I don't really understand
> this, but it seem the boost people do not acknownledge this as Boost
> issue?? It seems that when setting D_GLIBCXX_DEBUG the full C++ stack must
> be recompiled; that mostly works since:
> 
> 
> 1.   libstdc++ comes in a DEBUG version which is linked in when
> –DGLIBCXX_DEBUG is used.
>
> 2.   The external C++ libraries we use are mostly header only; however
> Boost regex is not header only and will break due to ABI
> incompatibilities.
> 
> 
> If my argument is right the problem should be the same with Boost
> filesystem?

it could be that boost::filesystem as it is used in our code does not trigger 
the ABI incompatibility by coincidence...

as a work-around for newish (>= GCC 4.9 ?) compilers, we could modify the 
build system to check if std::regex is supported and if yes, use that. I'll 
implement it if there are no better ideas...

cheers
  Andreas

-- 
Notice: "String" and "Thread" are the same thing to non-computing
people.
— Programming.com

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

Re: [OPM] Build system updates

[Andreas Lauser]

Hi,

On Wednesday 02 July 2014 09:01:41 Alf Birger Rustad wrote:
> Exceptions tend to make things even more chaotic. Please provide as PRs, and
> we will merge quickly.

Okay, then I'll bite the sour apple...

The real fix would be to have a single place which needs to be modified for 
such 
build system changes. That means either to have a separate "build system" 
module, or to have the Find*.cmake files distributed along with their 
respective OPM modules. IMO, the latter option would be technically superior 
because there would not need to be a "central registry" for all supported 
modules but it can lead to the chicken-and-egg problem that the location of a 
Find*.cmake module must be known in order to find the location of the OPM 
module. I think though that this problem can be worked around generically with 
not too much effort...

cheers
  Andreas

-- 
Notice: "String" and "Thread" are the same thing to non-computing
people.
— Programming.com

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

Re: [OPM] Build system updates

[Andreas Lauser]

Hi,

On Wednesday 02 July 2014 06:46:39 Alf Birger Rustad wrote:
> My take on this is that build issues can happen, but then they should be
> fixed within a day or two. I do hope we can mandate building of PR's prior
> to merging on the new virtual build server soon though. If we know in
> advance that a PR is going to break building due to other pending PR's,
> then they should all be ready for merging at the same time.
>
> In this case I guess it is an oversight, as the actual breaking was probably
> caused by merging this one: https://github.com/OPM/opm-parser/pull/249
> before propagating #608 to all modules.

It is not really an oversight, but I thought that the maintainers of the 
affected modules would apply the patch to their stuff much more quickly. I 
clearly stated that it is required on a few occasions...

Since I don't really want to go through the hassle of setting up a PR for each 
module because of such a trivial change, we should possibly think about a 
"direct push exception" for build system changes that have been merged to opm-
core...

> Andreas, will you propagate #608 to the other modules? Kristian, thanks for
> catching this one.

is this a permission to push directly? if yes, no problem...

cheers
  Andreas

-- 
Notice: "String" and "Thread" are the same thing to non-computing
people.
— Programming.com

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

Re: [OPM] semantics of transmissibilty

[Andreas Lauser]

Hi,

On Monday 30 June 2014 19:11:28 Bård Skaflestad wrote:
> On Mon, 2014-06-30 at 18:07 +0200, Andreas Lauser wrote:
> > I'm currently struggling with the semantics of the transmissibilities
> 
> Let me just start by remarking that when you have an UnstructuredGrid,
> the transmissibility problem is already solved by the pair of functions
> tpfa_htrans_compute() and tpfa_trans_compute() declared in module
> opm-core's
> 
> 
> 
> header.  At least in the mode referred to as "NEWTRAN" in the
> documentation.
> 
> Secondly, ECLIPSE's TRAN[XYZ] arrays do not define transmissibilities
> across faults.  These arrays are only meaningful when discussing
> Cartesian connections (e.g., (I,J,K)-to-(I+1,J,K) for TRANX with the
> actual value stored in the cell with the smallest 'I' index).
> Transmissibility across non-neighbouring connections as generated by
> faults are generally handled elsewhere and represented differently
> (typically not exposed to the input deck).

Yes some parts of the docu make this impression, but the TD also says that the 
cell transmissibility T_j is not necessarily the logically-Cartesian neighbor 
and the figure used for illustration purposes also clearly shows a non-
conforming grid...

> What problem are you trying to solve?

the problem is that I want to include the NTG and MULT[XYZ]-? keywords in the 
transmissibility calculations and that IMHO the C code obscures what it does 
quite effectively. More relevantly though is that I'm not really sure that the 
C code does the right thing in the first place, so even if I go for a 
modification of the existing C functions, I'd like to understand why they do 
what they do and how it relates to the Eclipse documentation...

cheers
  Andreas

-- 
Notice: "String" and "Thread" are the same thing to non-computing
people.
— Programming.com

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

[OPM] semantics of transmissibilty

[Andreas Lauser]

Hi,

I'm currently struggling with the semantics of the transmissibilities, and 
given the number of Eclipse gurus on this mailing list, I thought somebody may 
know the answer: To compute the TRANSX value for a cell i, the Eclipse TD says 
that one needs to harmonically average T_i and T_j, the "half-face" x-
transmissibilities of the "interior" cell  and the "exterior" cell of a face. 
Here the problem arises: Transmissibility is a quantity which inherently only 
makes sense for cell faces in finite-volume discretizations but Eclipse 
specifies it as a cell-based quantity. Considering that because of faults the 
grid can become non-conforming and there can thus be more than one face into 
each direction, the TRANS[XYZ] keywords do not really make sense. The question 
is: What must be assumed as the "cell j"? The cell which is one index further 
in logically Cartesian coordinates? (That would not work for faults or for 
cases where those cells are not connected, though.)

cheers
  Andreas

-- 
Notice: "String" and "Thread" are the same thing to non-computing
people.
— Programming.com

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

Re: [OPM] Require Boost:regex

[Andreas Lauser]

Hi,

On Saturday, June 28, 2014 16:44:45 Atgeirr Rasmussen wrote:
> I assume that it would not increase the minimum required version we require
> of boost?

AFAICS, no. (It is available in boost 1.44.)

cheers
  Andreas

> 28. juni 2014 kl. 18:31 skrev Andreas Lauser :
> > Hi,
> > 
> > Some remarks from the offender (i.e. me) seem to be appropriate. I've
> > chosen boost::regex because:
> > 
> > - it is the library which got graduated to std:: in c++-2011, so that the
> > code changes should be minimal once GCC 4.9 is the minimum supported
> > compiler version of OPM
> > - we already use quite a few boost libraries, so adding another one to the
> > prerequisites seemed natural
> > - I did not know about regex.h (*booohhh*)
> > 
> > have a nice (remaining) weekend
> > 
> >  Andreas
> > 
> > On Saturday, June 28, 2014 15:40:55 Joakim Hove wrote:
> >> Hello;
> >> 
> >> In the PR: https://github.com/OPM/opm-parser/pull/249 Andreas has
> >> implemented support for regex matching of keywords in the deck. We need
> >> this functionality, and modulo minor fixes I intend to merge this PR.
> >> However, the PR uses Boost::regex; so going with it as it is now will
> >> introduce a Boost::regex dependeny through the whole stack. As I see it
> >> there are two possibilities:
> >> 
> >> 
> >> 1.   Take the PR as is and accept the Boost::regex dependency - that
> >> might be perfectly OK?
> >> 
> >> 2.   Use C/Posix regex.h.
> >> 
> >> Any opinions? Whatever choice we make we should preferably switch to
> >> std::regex when we switch to a sufficiently new g++ compiler.
> >> 
> >> Joakim
> 
> ___
> Opm mailing list
> Opm@opm-project.org
> http://www.opm-project.org/mailman/listinfo/opm

-- 
Notice: "String" and "Thread" are the same thing to non-computing
people.
— Programming.com

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

Re: [OPM] Require Boost:regex

[Andreas Lauser]

Hi,

Some remarks from the offender (i.e. me) seem to be appropriate. I've chosen 
boost::regex because:

- it is the library which got graduated to std:: in c++-2011, so that the code 
changes should be minimal once GCC 4.9 is the minimum supported compiler 
version of OPM
- we already use quite a few boost libraries, so adding another one to the 
prerequisites seemed natural
- I did not know about regex.h (*booohhh*)

have a nice (remaining) weekend
  Andreas

On Saturday, June 28, 2014 15:40:55 Joakim Hove wrote:
> Hello;
> 
> In the PR: https://github.com/OPM/opm-parser/pull/249 Andreas has
> implemented support for regex matching of keywords in the deck. We need
> this functionality, and modulo minor fixes I intend to merge this PR.
> However, the PR uses Boost::regex; so going with it as it is now will
> introduce a Boost::regex dependeny through the whole stack. As I see it
> there are two possibilities:
> 
> 
> 1.   Take the PR as is and accept the Boost::regex dependency - that
> might be perfectly OK?
> 
> 2.   Use C/Posix regex.h.
> 
> Any opinions? Whatever choice we make we should preferably switch to
> std::regex when we switch to a sufficiently new g++ compiler.
> 
> Joakim

-- 
Notice: "String" and "Thread" are the same thing to non-computing
people.
— Programming.com

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

Re: [OPM] issue with compiling opm-core

[Andreas Lauser]

Hi Paolo,

On Friday 27 June 2014 09:11:28 Paolo Orsini wrote:
> If this is the case, wouldn't it make sense to copy the config.h to the
> system include folder during the installation?

not really. That's because external projects may need their own configuration. 
What it boils down to is that in the end external projects either need to 
either use the same build system as OPM or put a lot of effort into making its 
own one compatible. (N.B. that the OPM build system is in the same situation 
when it comes to its DUNE requisites. We decided to put a lot of effort into 
our build system so that it does not screw up Dune.)

cheers
  Andreas

-- 
Notice: "String" and "Thread" are the same thing to non-computing
people.
— Programming.com

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

Re: [OPM] issue with compiling opm-core

[Andreas Lauser]

Hi,

Sorry for this being slightly off-topic, but I had to say something here:

On Thursday, June 26, 2014 14:55:09 Arne Morten Kvarving wrote:
> if an application uses config.h unconditionally, that is a bug.

This is not a bug for the following reason: all source files of the libraries 
are compiled with taking the macros of config.h in consideration. If you now 
try to compile with another set of values for these macros, you will get 
unexpected behavior, in particular if the headers also have some of these #ifs 
(e.g. a few attributes of the EclipseWriter class are conditional on the 
HAVE_ERT macro). In the best case this leads to a segfault and in the worst to 
very subtle runtime bugs which are also very hard to debug. This means that 
config.h is always required and that it needs to be compatible with the one 
used to compile the libraries...

cheers
  Andreas

-- 
Notice: "String" and "Thread" are the same thing to non-computing
people.
— Programming.com

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

Re: [OPM] Events in the Schedule object

[Andreas Lauser]

Hi,

On Sunday 22 June 2014 21:34:49 Joakim Hove wrote:
> I suggest that we update an integer flags mask during the Schedule parse
> process which the consumer can consult to determine which changes have
> occurred, and which simulator internal quantities must be recalculated.
> I.e. the consumer could have code like this:
> 
> 
>   if (scheduleFlags(WELL_RATES_CHANGED))
>   updateWellRates();
> 
>  if (scheduleFlags(WELL_TOPOLOGY_CHANGED))
>  updateWellTopology();
> 
>  if (scheduleFlags(WELL_COMPLETIONS_CHANGED))
> updateCompletions();
> 
> 
> In 95% of the timesteps only the first test will return True. Something to
> think about?

I think the idea is good, but I'd prefer a slightly different API:

if (eclipseState->wellRatesChanged())
updateWellRates();
// ...

plus variants of the methods which take a report step index (which may default 
to the current one if left unspecified):

if (eclipseState->wellRatesChange(/*reportStepIdx=*/5))
std::cout << "Well rates will change in the sixth report step!\n";
// ...

that said, other APIs are perfectly okay for me as well...

cheers
  Andreas

-- 
Notice: "String" and "Thread" are the same thing to non-computing
people.
— Programming.com

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

Re: [OPM] issue with compiling opm-core

[Andreas Lauser]

Hi,

On Sunday, June 22, 2014 20:28:00 Joakim Hove wrote:
> I think we all agree that OPM is (and in my opinions should remain) more on
> libraries and core functionality, and less on end user applications. But if
> that strategy is to credible it must be simple for third party developers
> like Paolo to build applications on top of the opm libraries – that is
> currently not the case. 

I agree: IMHO this is a call for a shell script which allows to easily create 
a bare-bones module (DUNE has a script called 'duneproject' for this purpose, 
but I do not know how reliable it is) and for either moving the build system 
into a separate module or making it distributed over the modules (the second 
option is the path taken by DUNE). Replicating everything to all modules is 
clearly unfeasible because, even though build system changes can be propagated 
to all "official" modules, external ones need to be left standing in the rain.

That said, if there are no miracles, this can only be done for the next-after-
next release at the earliest (i.e., next year). IMHO this should be also used 
as an opportunity to refurbish the division of functionality between the 
modules...

> To be honest I think I would have had to resort to
> Andreas suggestion myself – is this the time when I *really* should
> understand how pkg-config works?

AFAICS pkg-config does not help too much here: it makes it easier to write 
cmake/autoconf modules because it provides a (relatively) simple canonical way 
to retrieve the relevant compiler and linker flags, but it does not allow to 
get rid of the need to write such tests in the first place. I like to think of 
it as a non-cmake specific way of detecting the settings required for packages. 
(note that it trades "non-cmake specific" for "only available on UNIXoid 
systems".)

cheers
  Andreas

-- 
Notice: "String" and "Thread" are the same thing to non-computing
people.
— Programming.com

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

Re: [OPM] issue with compiling opm-core

[Andreas Lauser]

Hi Paolo,

please try to keep the conversation on the mailing list. it may be useful for
others. (and this way it will more easily be found by your favorite search
engine.)

On Sunday, June 22, 2014 09:52:50 you wrote:
> Thanks for your help.
> Since the problem seems to be with library linking, I restricted the
> testing to what it seems the simplest source file to compile
> (opm-core/tutorials/tutorial1.cpp).
> 
> First...
> tutorial1.cpp compiles and runs internally to opm-core using cmake
> I will follow your advice to add my developments within this framework,
> using cmake to compile.
> And I will be happy to share my developments using github pull requests
> when i have something worth share.

good :)

> Second 
> I would still like to understand why I was failing to call components of
> the opm library externally. Calling opm library components from external
> software can always be useful.
> When I copy tutorial1.cpp to an external directory, and i try to link it to
> the opm-core library, I get the following errors:
> 
> 
> /// /tmp/ccgpdkx6.o: In function `main':
> tutorial1.cpp:(.text+0xd2): undefined reference to
> `Opm::GridManager::GridManager(int, int, int, double, double, double)'
> tutorial1.cpp:(.text+0x115): undefined reference to
> `Opm::GridManager::c_grid() const'
> tutorial1.cpp:(.text+0x12e): undefined reference to
> `Opm::writeVtkData(UnstructuredGrid const&, std::map std::vector > const*,
> std::less, std::allocator std::vector > const*> > > const&,
> std::ostream&)'
> tutorial1.cpp:(.text+0x15b): undefined reference to
> `Opm::GridManager::~GridManager()'
> tutorial1.cpp:(.text+0x1bb): undefined reference to
> `Opm::GridManager::~GridManager()'
> collect2: error: ld returned 1 exit status
> 
> //
> 
> The command I am using to compile is:
>  g++ -std=c++11 -o test -L/home/paolo/OPM/opm-core/build/lib -lopmcore
> tutorial1.cpp

could you try with the following command?

g++ -std=c++11 -o mytest tutorial1.cpp 
/home/paolo/OPM/opm-core/build/lib/libopmcore.a

then the the errors you described should go away just to be replaced by
similar ones because of missing symbols for opm-parser and for ERT and
if you fixed those, it will go on with missing boost and UMFPack 
libraries. I think you see the pattern...

also note that using 'test' as a binary name is not a good idea because this
name is an internal command in many common shells.

> The header files included in tutorial1.cpp are located in
> "usr/local/include", and they are found during compilation.
> I copied config.h into the same folder of tutorial1.cpp

copying config.h is quite a hack, but as long as you stay on the same machine
as it was created on, it should work...

> Sorry, I am not really sure what you mean with "full linker command which
> 'make' tries to execute", is it the compiling command given above? Or the
> make I invoke to compile opm-core?

that's the g++ command you described above. :)

cheers
  Andreas

-- 
Notice: "String" and "Thread" are the same thing to non-computing
people.
— Programming.com

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

Re: [OPM] issue with compiling opm-core

[Andreas Lauser]

Hi Paolo,

On Friday, June 20, 2014 18:36:22 Paolo Orsini wrote:
> I built/installed :
> - required packages (boost-devel, etc..)
> - compile and install ERT (compiling and installing from source, from
> current github master)
> - compile and install opm-parser (did make test ... all good)
> - compile and install opm-core (did make test ... all good)
> 
> I tried to build the well example independently.

ah, that might explain it: you probably did not link your binary to libopmcore 
and to the libraries produced by opm-parser. If you did, could you please 
provide the full linker command which 'make' tries to execute?

Note that, instead of starting a project from scratch, it is probably easier 
to just clone the OPM module which is closest to what you would like to 
achieve and extend it by your stuff. The build system is pretty intricate and 
with git it is easy to do local commits and occasionally rebase them on top of 
the latest upstream version.

(finally, if you have developed stuff which might be interesting to others, 
please open a pull request on github. this makes your life much easier as you 
won't have to maintain the code after it has been accepted upstream and the 
others do not need to re-implement your changes. We don't bite on reviews, 
promised...)

> I am happy to follow the most common path to build/install ... which is?

it is that everybody should be able to do it as it pleases him most. 
Personally I usually use the dunecontrol script (from the dune project) 
because it takes care about prerequisite modules and compiles everything in 
the right order, but most other developers use cmake directly in conjunction 
with out-of-tree build directories (which are not really possible with 
dunecontrol).

cheers
  Andreas

-- 
Notice: "String" and "Thread" are the same thing to non-computing
people.
— Programming.com

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

Re: [OPM] Regarding transmissibility multipliers

[Andreas Lauser]

Hi,

On Tuesday, June 17, 2014 18:21:07 Bård Skaflestad wrote:
> On Tue, 2014-06-17 at 15:16 +, Joakim Hove wrote:
> > MULTX: This keyword is a multiplier for the transmissibility on the
> > x-face between cells (i,j,k) and (i+1,j,k).
> > MULTX-: This keyword is a multiplier for the transmissibility on the
> > x-face between cells (i-1,j,k) and (i,j,k).
> 
> With the additional provision that we use cell (i,j,k) as the reference
> cell, then yes.  That's correct.  MULTX modifies trans in positive 'X'
> (strictly speaking 'i') direction, MULTX- modifies trans in negative 'X'
> direction.

I have a (probably stupid) question here: if MULTX- is not specified, do the 
values specified in MULTX also apply for the negative direction? my intuition 
is that this is the sensible thing to do from a user's perspective, but I am 
not sure about this even after reading the manual...
 
cheers
  Andreas

-- 
Notice: "String" and "Thread" are the same thing to non-computing
people.
— Programming.com

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

Re: [OPM] Using old eclipse files with new parser.

[Andreas Lauser]

Hi,

On Friday 28 March 2014 12:29:17 Joakim Hove wrote:
>> hm, okay. does Eclipse accept that particular deck? if yes, it may be a
>> good idea to also become a bit less strict in opm-parser. (maybe we should
>> just produce a warning instead of an error?)
> 
> Forget it. Eclipse eats more or less anything; we need all the safety we
> can get. This is the documented behavior.
 
That's fun! It somehow reminds me on PL/I, https://en.wikipedia.org/wiki/PL/I 
It's a programming language which also eats anything without complaints; even 
plain IFs. For some reason, I've got doubts about whether software is _that_ 
good at mind reading  ;)

cheers
  Andreas

-- 
Never underestimate a C programmer's ability to write C code in any
language you give them.
— Jason Gorman

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

Re: [OPM] Using old eclipse files with new parser.

[Andreas Lauser]

Hi,

On Friday 28 March 2014 11:01:57 Joakim Hove wrote:
>>> I guess you could try to delete some of the keywords that create
>>> trouble, if they are unneeded and not too many.
>> 
>> Or even better: add the keyword definitions to opm-parser. They are just
>> JSON definitions and are located in opm/parser/share/keywords
> 
> In general I agree with Andreas suggestion, but for the particular case
> Markus had here the problem was that the new parser is stricter than old,
> and at least the BGAS keyword was not correctly formatted in Markus deck
> (as I understood it).

hm, okay. does Eclipse accept that particular deck? if yes, it may be a good 
idea to also become a bit less strict in opm-parser. (maybe we should just 
produce a warning instead of an error?)

cheers
  Andreas

-- 
Never underestimate a C programmer's ability to write C code in any
language you give them.
— Jason Gorman

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

Re: [OPM] Using old eclipse files with new parser.

[Andreas Lauser]

Hi,

On Friday 28 March 2014 08:18:40 Atgeirr Rasmussen wrote:
> I guess you could try to delete some of the keywords that create trouble,
> if they are unneeded and not too many.

Or even better: add the keyword definitions to opm-parser. They are just JSON 
definitions and are located in opm/parser/share/keywords

cheers
  Andreas

-- 
Never underestimate a C programmer's ability to write C code in any
language you give them.
— Jason Gorman

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

Re: [OPM] CpGrid face normals

[Andreas Lauser]

Hi,

On Thursday 27 February 2014 14:47:50 Markus Blatt wrote:
> On Thu, Feb 27, 2014 at 07:12:09AM +, Atgeirr Rasmussen wrote:
> > Your observation is correct. The normals in the UnstructuredGrid are
> > required to have length equal to the area of the corresponding face (see
> > the Doxygen doc for UnstructuredGrid).
> It was just a surprise to see such a difference and took time to
> realize it. I am probably not the last one to stumble over this. As
> currently the only place where this caused trouble was
> opm/core/pressure/tpfa/..., I worked around the problem there. The
> problem is that there are now faceNormal(const UG&, int) and
> faceNormal(const CpGrid, int) that actually return different
> things. This should probably be fixed.

can't the length of the returned vector just be undefined for faceNormal()? 
the vector can easily be normalized thereafter...

> One could adapt Cpgrid to store the scaled face normals. Or is there
> and argument against this?

By virtue of Gauss' integral theorem, I encounter more unit normals than 
scaled ones in equations. I'd prefer unit normals in CpGrid for this 
reason...

cheers
  Andreas

-- 
Who wrote this! And what was I thinking?
  — "Overheard" by Ted Gould

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

Re: [OPM] Where to put CpGrid versions of opm-cores C headers and implementations

[Andreas Lauser]

Hi Markus,

On Friday 21 February 2014 12:48:36 Markus Blatt wrote:
> Seeing the
> 
> #ifdef __cplusplus
> extern "C" {
> #endif
> 
> statements. Are some you compiling opm-core with C? Or is it always
> compiled with a C++ compiler and just some parts of the library must
> be usable from C?

If I'm not horribly wrong, everybody who does nothing special to their build
uses the C compiler for those parts:

-- snip --
and@heuristix:~/src/opm-core > make VERBOSE=1
...
[  4%] Building C object 
CMakeFiles/opmcore.dir/opm/core/grid/cpgpreprocess/uniquepoints.c.o
/usr/bin/cc ...
...
-- snap --

hope that helps...

cheers
  Andreas

-- 
Who wrote this! And what was I thinking?
  — "Overheard" by Ted Gould

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

Re: [OPM] Use of ERT in Parser?

[Andreas Lauser]

> Joakim Hove wrote:
>> Sounds like a good plan. In the not-so-distant future we might consider
>> renaming opm-parser -> opm-eclipse?

To avoid the wrath of Schlumberger, it's probably a good idea not to do 
that...

On Monday 27 January 2014 11:47:43 Alf Birger Rustad wrote:
> I am not sure that is a good idea. It depends on what we want to accomplish
> I guess, and putting restrictive names on projects may end up restricting
> it unnecessarily in practice. In this case there are two issues. One is do
> we really want to restrict opm-parser to Eclipse formats? The reason we
> implement support for Eclipse formats is because of its dominating market
> position and what that entails. Moving forward though, I do think we at
> some point want to support at least one additional input format, and I do
> believe that the current design of opm-parser is a good starting point for
> that. Secondly, I believe having basic IO routines spread out across repos
> makes no sense other than creating sandboxes for developers. I believe
> parsing belongs in a common library along with other shared functionality,
> which is not exactly what opm-core is today. Making a library optional
> fine, but I do think a simulator needs input format, and this is all we
> have, so I am not sure the solvers will be of much use without it
> currently. Hence I suggest keeping the opm-parser name for know, but that
> we set a side some time to review our repository organization later this
> year.

I agree that in the long run supporting/creating a more sane format makes 
quite a bit of sense and the name of the parser module should be more generic 
for this reason. Though I'm not sure whether the current data structures in 
opm-parser are a too good fit for something other than Eclipse, mainly because 
they have been designed to cope with the idiosyncrasies of the eclipse file 
format. Nevertheless they're probably a good starting point.

cheers
  Andreas

-- 
 Who wrote this! And what was I thinking?
  — "Overheard" by Ted Gould

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

Re: [OPM] Build system documentation

[Andreas Lauser]

Hi,

On Wednesday 22 January 2014 12:06:11 Markus Blatt wrote:
> I am currently kind of lost concerning the build system of OPM. Do you
> guys have any pointers to documentation?

Roland recently wrote quite a bit about it. You can find it here:

https://github.com/OPM/opm-core/blob/master/cmake/OPM-CMake.md

> Or answers to some of my questions:
> 
> 1. Does the _Deps variable need to list all dependencies or is
>the dependency system somewhat transient and only the immediate
>dependencies are needed?

to my knowledge it's transitive...

> 2. Changing CMake macros of one module. How does this happen? From the
>discussion on github I am under the impression that this should happen
>only in opm-core. If that is correct how do people manage their
>changes?

well, it was decided that opm-core is the central hub for build system 
changes. So if you have anything related to the build system of some module 
(except opm-parser which is currently special), please also open a PR for 
opm-core so that the maintainers of the other modules can synchronize.

>Do they do them locally in a branch of the module that they are
>changing, later they simply revert this one commit and create an
>additional branch in opm-core with the exact same build system
>changes?

no reverts required, but all changes should also go into opm-core...

cheers
  Andreas

-- 
Who wrote this! And what was I thinking?
  — "Overheard" by Ted Gould

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

Re: [OPM] Umfpack runtime dependendy is problematic

[Andreas Lauser]

On Thursday 10 October 2013 14:39:24 Alf Birger Rustad wrote:
> Generally speaking, I support dynamic linking where libs are available
> (which includes blas and lapack). Simply because I believe it is less error
> prone since it is the standard modulo of operandi for GNU/Linux
> distributions (I do agree on that Arne Morten).

I agree insofar that it is advisable to use dynamic linking for packages, as 
it is much easier to fix a bug in a library once instead of in hundreds of 
depending packages. For software like OPM which the user compiles himself 
anyway (if not uses packages and thus packaged dependencies like UMFPACK are 
not a problem and the package maintainer is supposed to make sure that the 
software works correctly), it makes sense to default to static linking to 
avoid dependency issues and take advantage of the 1% performance 
improvement...

> We encountered a similar
> situation a while back on a seismic application where it turned out that
> statically linking of atlas and cblas was broken on Debian. Ref.
> https://github.com/CRAVA/crava/pull/22

Of course, CMake should test this for each library individually before using 
it...

cheers
  Andreas

-- 
A programmer had a problem. He thought to himself, "I know, I'll solve it with 
threads!". has Now problems. two he
   -- Davidlohr Bue

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

Re: [OPM] Umfpack runtime dependendy is problematic

[Andreas Lauser]

On Thursday 10 October 2013 10:31:34 Alf Birger Rustad wrote:
> Generally speaking, I would suggest static linking by default of any
> runtime library dependency not supported by Red Hat. 

I would even go a step further and do static linking whenever possible: 
Besides avoiding the wrath of corporate IT, it also comes with small 
performance benefits, since (as far as I understood it) dynamic linking 
requires indirect function calls which basically makes any entrypoint of the 
library a virtual method...

just my 2c.

cheers
  Andreas

-- 
A programmer had a problem. He thought to himself, "I know, I'll solve it with 
threads!". has Now problems. two he
   -- Davidlohr Bueso

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

Re: [OPM] OPM eclipse parser, status and plans

[Andreas Lauser]

On Monday 07 October 2013 11:36:59 Joakim Hove wrote:
> > > I am certainly open to the possibility that opm-parser should be part of
> > > opm-core.
> > 
> > To me it seems natural that parsing input files belongs to the core
> > library.
> > I can see that keeping opm-parser and opm-core as separate repositories
> > long term can be convenient from a maintainer perspective, but I have a
> > hard time seeing that it can be beneficial from any other perspective.
> > Please enlighten me if there are important aspects here that I don't see.
> > 
> > ie, the only aspect that matters? user issues are solved through other
> > means, buildsystems are there for developers and should be optimized for
> > developer convenience. the more you can split, the less bug prone the
> > development get in my experience (though setting up a build tree is
> > slightly harder).
> > 
> > furthermore, opm-core is already bloated with tons of stuff that for my
> > eyes
> > do not appear to belong there (linear solvers, model parsing, a strategy
> > for dog walks, etc). some of the stuff is misplaced there to the extent
> > that is has been duped where it is more natural to put it (linear solver
> > interfaces are duplicated in porsol).
> 
> imnsho*, the core library should just be a set of core utilities which are
> shared between modules, not a  dump to avoid having to deal with more
> modules. parser should use core. core should not use parser. there is
> absolutely no requirement to use .grdecl files to use the rest of opm. why
> should it then sit in the core?
> 
> Well - I have very limited experience developing with opm-core, but my gut
> feeling is to agree strongly with Arne Morten. IMNSHO opm-core is way too
> large. Ultimately opm-parser should use opm-core in the sense of low level
> core routines, but the scenario where opm-parser uses opm-core is quite far
> away from the current incarnation of opm-core. I realize my weight of say
> in these matters is quite limited, but in my opinion it would be healthy
> for OPM as a whole to refactor the module organization?

Just to put my insignificant opinion into the discussion: I tend to agree. What 
I envision the purpose in opm-core to be is something akin to the dune-common 
module: A collection of useful generic utilities which do not come with a 
high/any burden if you don't use them. (In this special case, it might also be 
worth to note that one fine day, OPM will hopefully not just about reservoir 
engineering anymore and the eclipse parser would not make much sense for e.g. 
groundwater problems.)

But actually, that issue is not too important to me :)

> Well - I'll put on my asbesto underwear :)

No reason to do so: There do not seem to be too many people who care in a 
flaming way ;)
 
cheers
  Andreas

-- 
A programmer had a problem. He thought to himself, "I know, I'll solve it with 
threads!". has Now problems. two he
   -- Davidlohr Bueso

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

Re: [OPM] compiler warnings

[Andreas Lauser]

Hi,

On Thursday 26 September 2013, 14:14:32 you wrote:
> On Thu, 2013-09-26 at 13:50 +0200, Andreas Lauser wrote:
> > there are a few compiler warnings on GCC 4.8 and CLang 3.3 which I
> > 
> >  think should be fixed before the release.
>
> Thanks for setting up the automatic build service.  I'll deal with
> opm-core, opm-autodiff, dune-cornerpoint, and opm-porsol--at least to
> the extent possible.  Some of the warnings in CDash *appear* to be from
> Dune software.

Thanks for attacking this head-on! Yes, some of these warnings are not our 
fault and you should  also keep in mind that some of these warnings -- 
especially for GCC 4.4 -- are bogous or they may be just specific to my 
machine.

BTW: If anyone has additional compilers which produce warnings, just run

   make clean && ctest -D Experimental

in the OPM module to make them appear on CDash. While I can't promise too 
much, we will do what we can to fix them...

cheers
  Andreas

-- 
A programmer had a problem. He thought to himself, "I know, I'll solve it with 
threads!". has Now problems. two he
   -- Davidlohr Bueso

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

[OPM] compiler warnings

[Andreas Lauser]

Hi,

there are a few compiler warnings on GCC 4.8 and CLang 3.3 which I think 
should be fixed before the release. (I'm posting this here, because it affects 
quite a few modules.) If you don't have these compilers, you can see these 
warnings on CDash at http://www.opm-project.org/CDash

If you can, please fix them for the modules which you care for...

cheers
  Andreas

-- 
A programmer had a problem. He thought to himself, "I know, I'll solve it with 
threads!". has Now problems. two he
   -- Davidlohr Bueso

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

Re: [OPM] New maintainer: opm-upscale

[Andreas Lauser]

Hi!

On Tuesday 24 September 2013 09:35:29 Arne Morten Kvarving wrote:
> On 24/09/13 00:49, Roland Kaufmann wrote:
> > On 2013-09-23 03:12, Arne Morten Kvarving wrote:
> >> @rolk can push [build system changes] directly, once they have been
> >> reviewed and merged elsewhere
> > 
> > But I won't :-)
> > 
> > (If anyone is interested in how I did the CMake rollups, they can read a
> > write-up at . I
> > suspect there is an easier way with `git subtree split` though).

I suppose I will continue to use my own script:

for COMMIT in $LIST_OF_HASHES; do
   cd $SRC_DIR/opm-core
   rm *.patch
   git format-patch $COMMIT~1..$COMMIT

   cd $SRC_DIR/opm-$OTHER_MODULE
   git am ../opm-core/*.patch
done

this is probably not as bullet proof as Roland's way, but my simple mind 
understands it more easily ;)

> > On 2013-09-23 13:28, Arne Morten Kvarving wrote:
> >> i prefer squashed pulls. ... iow; mainline should not carry broken
> >> ...
> >> during the review process you push fixes as separate commits. they
> >> are reviewed. they are ack'd. then it's squashed up. only then is it
> >> pulled into mainline.
> > 
> > I do have to say that I disagree with this view. I *do* agree that
> > during review we could add revisions with --fixup to ease the
> > reviewing and then squash *those* into their respective targets before
> > merging.
> 
> i never meant that we'd squash the entire pull up, sorry if that was the
> impression. a pull should, as requested, be split into logic commits. as
> long as it doesn't break at any of them. i meant you use fixup to adress
> comments on the individual commits.

the problem with --fixup during review is that all consecutive patches will get 
a different hash and github will thus treat them as if they were entirely new. 
(which makes reviews harder, IMHO.) The best methodology is probably the 
following procedure:

- create a PR
- while it is reviewed, only add patches to it at the end
- _after _the review (indicated by a maintainer):
  - run `git fetch origin; git rebase origin/master` to make the Big Green 
Button (TM) re-appear. (if it disappeared in the meantime.)
  - if the patches are not yet split in a completely meaningful way, use 
`git rebase -i origin/master` to reorder and squash
  - force push the branch to the PR's repo on github (i.e., use `git push -f`)
- after that, a maintainer presses The Big Green Button

just 

cheers
  


-- 
A programmer had a problem. He thought to himself, "I know, I'll solve it with 
threads!". has Now problems. two he
   -- Davidlohr Bueso

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

Re: [OPM] New maintainer: opm-upscale

[Andreas Lauser]

Hi All,

On Monday 23 September 2013 13:28:40 Arne Morten Kvarving wrote:
> On 23/09/13 13:24, Andreas Lauser wrote:
> > Congratulations! One question: Do you prefer to rebase PRs prior to
> > merging
> > (i.e., makeing them fully bisectable) or do you to like to keep the fixup
> > patches in the commits of the PRs (for easier reviewing)?
> 
> bisectability of mainline is the main priority. so i prefer squashed pulls.
> the way i see it, the only history of interest is the history that
> impact mainline.

okay, I only asked because (in my limited understanding) Atgeirr prefers the 
second option. IMHO we should either have the same policy across all modules 
or document which module prefers which policy...

> whatever happens outside can be maintained in a separate branch should
> it ever be useful,
> it very seldom is...
> iow; mainline should not carry broken commits.

I agree. But I also see the point of easier reviews...

BTW: does anyone know if git bisect can be instructed to only bisect 
mergepoints? At least in principle, these should always compile...

cheers
  Andreas

-- 
A programmer had a problem. He thought to himself, "I know, I'll solve it with 
threads!". has Now problems. two he
   -- Davidlohr Bueso

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

Re: [OPM] New maintainer: opm-upscale

[Andreas Lauser]

Hi Arne,

Congratulations! One question: Do you prefer to rebase PRs prior to merging 
(i.e., makeing them fully bisectable) or do you to like to keep the fixup 
patches in the commits of the PRs (for easier reviewing)?

cheers
  Andreas


On Monday 23 September 2013 13:12:06 Arne Morten Kvarving wrote:
> Hi there,
> 
> I have been appointed as the maintainer for the upscaling module.
> 
> As i don't have the full overview of the entire code base, i would
> appreciate that people who feel responsible for parts of the module to
> add themself to the MAINTAINERS file in the root.
> 
> while i will handle the main load, sometimes i will have to ask since i
> do not have the full overview
> of the code, and having such a list is useful both for me and for users.
> 
> as i am the maintainer i get to set some ground rule. i have two simple
> rules:
> 
> NO direct pushes. no matter how trivial the change. i reserve the right
> to break my own rule here at my own leisure. this to do maintenance
> tasks only (cosmetics and such). you are always free to tell me if i
> overstepped my boundaries.
> 
> the only exception here is for common buildsystem changes. @rolk can
> push those directly, once they have been reviewed and merged elsewhere.
> 
> secondly, ALWAYS split your commits into logical bits. if you send a
> pull with one large "dump" commit, i will reject it no matter the
> quality of the code.
> 
> it's not to be difficult. it's out of experience. we ALL screw up at
> times, even the simplest of things. i want to catch them before they go
> in. we are never in such a hurry. and the splitting really helps keep
> the history useful. a vcs is a development tool, not a backup backend or
> a convenient way of distributing code (it's those as well but those are
> secondary). it's imperative that we can search the history and such and
> not encounter broken commits or entangled changes.
> 
> arnem

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

Re: [OPM] master branch numbering

[Andreas Lauser]

Hi,

On Tuesday 27 August 2013 14:04:23 Roland Kaufmann wrote:
> On 2013-08-27 10:02 Roland Kaufmann wrote:
> >> The "version" should be increased in a semantically coherent
> >> manner, (see e.g. http://semver.org) whereas the "label" can be
> >> whatever we wants.
> >> 
> >> So actually, we should argue about what the version number should
> >> increase to after release branching. :-)
> 
> On 2013-08-27 12:23, Andreas Lauser wrote:
> > yeah, probably. I find the "one version for the aggregate release,
> > another for the API version" scheme quite confusing BTW. Probably we
> > should use the . scheme for the libraries, too.
> 
> There is a problem with this: Is 2013.09 compatible with 2013.03? You
> cannot really tell from the numbers, whereas 1.1 is expected to be
> compatible with 1.0, but 2.0 is not. On the other hand, a version number
> like 13.2 doesn't convey any information about the state of the project
> in itself.
> 
> Thus, there is one set of versions for determining technical API
> compatibility, and one set to determine social maturity.
> 
> And the former could be advanced when we branch off to another release,
> but it cannot contain a string. Using a high number is OK, but then
> you'll have to decide if you want to make non-breaking changes (1.1
> cannot follow 1.99, and 1.0.99 is not necessarily better stability-wise
> than 1.0.1); sometimes odd/even numbers in the minor are used to
> indicate stable/unstable.

I see. One question, though: do we make any ABI compatibility guarantees 
between releases? Currently this is not the case, AFAICS...

cheers
  Andreas

-- 
A programmer had a problem. He thought to himself, "I know, I'll solve it with 
threads!". has Now problems. two he
   -- Davidlohr Bueso

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

Re: [OPM] master branch numbering

[Andreas Lauser]

Hi All,

On Tuesday 27 August 2013 10:02:27 Roland Kaufmann wrote:
> On 2013-08-26 13:38, Atgeirr Rasmussen wrote:
> >> Our version numbers are more like strings than number sets, so can
> >> we use something like (3) with a string instead of a large number?
> 
> On 2013-08-26 15:49, Andreas Lauser wrote:
> > well, the problem is that strings are hard to check in the code.
> > AFAIK there is no possibility to compare them in the preprocessor,
> > 
> > #if OPM_IS_NEWER_THAN(2013,03) // ...
> > 
>  > #endif
> > 
> > won't work...
> 
> Don't do this. Do instead:
> 
> #include 
> 
> #if DUNE_VERSION_NEWER(OPM_CORE, 1, 0)
> // ...
> #endif
> 
> Much more stable. The "version" should be increased in a semantically
> coherent manner, (see e.g. http://semver.org) whereas the "label" can be
> whatever we wants.

You are (of course) right. that was rather meant as an example which is hard 
or impossible to implement using strings...

> So actually, we should argue about what the version number should
> increase to after release branching. :-)

yeah, probably. I find the "one version for the aggregate release, another for 
the API version" scheme quite confusing BTW. Probably we should use the 
. scheme for the libraries, too. (possibly suffixed by a point 
release 
level.)

> > hm, what happens if something regresses the master branch, and the
> > person affected sends his log (which says that the version is the one
> > of the last release)? I at least would be totally confused.
> 
> Never trust anything other than the "Source code repository:" line in
> the configuration log. And pay attention to whether there is a star
> suffix (meaning: local changes).

okay, thanks for the hint. would you mind putting this info into the wiki? (of 
course only once you have a silent hour.)

cheers
  Andreas

-- 
A programmer had a problem. He thought to himself, "I know, I'll solve it with 
threads!". has Now problems. two he
   -- Davidlohr Bueso

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

Re: [OPM] C++ exception policy in opm-core (and other libs)

[Andreas Lauser]

Hi All,

On Tuesday 27 August 2013 07:12:15 Atgeirr Rasmussen wrote:
> Den 26. aug. 2013 kl. 17:20 skrev Andreas Lauser:
> > On Monday 26 August 2013 14:20:18 Atgeirr Rasmussen wrote:
> >> Den 23. aug. 2013 kl. 12:06 skrev Andreas Lauser:
> >> [...]
> >> (for example, a Newton solver not converging is not an exceptional
> >> thing).
> >> 
> >> That's a thing I see quite differently. The reason is that there are
> >> about a million things which could go wrong that make the newton solver
> >> diverge. If any and all of this cases is protected by a classical
> >> "if(error) return error;" guard, you take quite a performance hit (by
> >> means of the guards themselfs and by means of missed optimization
> >> opportunities). On the other hand, C++ exceptions do not negatively
> >> impact performance (for details, see
> >> http://stackoverflow.com/questions/13835817/are-exceptions-in-c-really-s
> >> low ).
> >> 
> >> Semantics first: a Newton solver failing to converge is something that
> >> should be expected, and to a large extent any reasonable software must
> >> handle the possibility. Therefore it is not exceptional, and the event
> >> should not be hidden from the API.
> > 
> > well, i think that it is exceptional in the sense that this only occurs
> > once about every fifty million invocations of the assembler for the local
> > jacobian of an element. (and each single invocation of the local jacobian
> > would require quite a few ifs in the traditional method.)  IMHO that's
> > exactly the use case for C++ exceptions.
> 
> For something that happens every 5e7 invocation, I can agree that exceptions
> are fine. Maybe I picked a bad example, but in my experience one needs to
> handle non-converging Newton iterations more often than that, but for the
> systems you solve it may not be true.

non-convergence should be quite rare compared to convergence, though. I also 
agree that only throwing exceptions on the toplevel of the newton loop is a 
bad idea. The problem is that a problem may occur at any evaluation of the 
local residual (and these are a _lot_).

> I certainly interpreted you that way, I must have misunderstood your
> intentions. It really comes down to where the boundary between expected and
> exceptional behaviour is drawn, and that certainly would depend on error
> frequency etc.

yeah, I now slowly start to understand that you thought that the exception is 
only thrown in the event that the maximum number of Newton iterations is 
reached. If this was the case, I would totally agree with you.

> I do not argue in favour of traditional error-handling, only in favour of
> reporting file, line and error to the terminal so the user can send a
> semi-useful message to the developer.

I agree, so this was also a misunderstanding :).

> >> That is why the macro prints file
> >> and line number. On the other hand, the receiving end is rarely
> >> implemented
> >> (other than, perhaps at a very high level), and would not be able to use
> >> this information anyway.
> > 
> > Why this is an argument against using exceptions (an exception object may
> > also carry that information and it can be printed by the exception
> > handler)…
> This is not an argument against exceptions, which I am very much in favour
> of. Although I do not want to require:
> a. That exceptions carry this info (file, line).
> b. That all programs must catch all exceptions, to print the info.
> Far simpler then, to keep the existing use of a macro for the error (and
> throwing).

agreed, see above.

> >> This might be true for opm-core and opm-porsol, but eWoms catches
> >> 'NumericalException' and tries again with a smaller timestep. As you can
> >> imagine, is a relatively common case.
> >> 
> >> This may be a performance bomb, see above. Even if it turns out to not
> >> be,
> >> it is in my opinion abusing the exception concept, since it is an
> >> unexceptional event.
> > 
> > only if this would happen frequently, see above.
> 
> I assumed it would -- if it does not, we do not really disagree much, I
> think.

yep :)

> >> Finally, if you really want to use a specific
> >> exception for this, it should be something like NewtonFailureMaxIter or
> >> something like that.
> > 
> > well, we can talk about the naming, but in my experience, most of these
> > errors occur in the assembly stage because the newton method decided to
> > use an intermediate value which is out-of-range for the material
> > relations. IMO, th

Re: [OPM] C++ exception policy in opm-core (and other libs)

[Andreas Lauser]

Hi All,

On Monday 26 August 2013 14:20:18 Atgeirr Rasmussen wrote:
> Den 23. aug. 2013 kl. 12:06 skrev Andreas Lauser:
> [...]
> (for example, a Newton solver not converging is not an exceptional thing).
> 
> That's a thing I see quite differently. The reason is that there are about a
> million things which could go wrong that make the newton solver diverge. If
> any and all of this cases is protected by a classical "if(error) return
> error;" guard, you take quite a performance hit (by means of the guards
> themselfs and by means of missed optimization opportunities). On the other
> hand, C++ exceptions do not negatively impact performance (for details, see
> http://stackoverflow.com/questions/13835817/are-exceptions-in-c-really-slow
> ).
> 
> Semantics first: a Newton solver failing to converge is something that
> should be expected, and to a large extent any reasonable software must
> handle the possibility. Therefore it is not exceptional, and the event
> should not be hidden from the API.

well, i think that it is exceptional in the sense that this only occurs once 
about every fifty million invocations of the assembler for the local jacobian 
of an element. (and each single invocation of the local jacobian would require 
quite a few ifs in the traditional method.)  IMHO that's exactly the use case 
for C++ exceptions.

I agree that this case must be handled, but why is it so bad to do this in an 
exception handler? Besides being more performant and more maintainable (the 
code is not cluttered by ifs and you can use the function return values for 
something useful), it is IMHO also conceptionally clearer to do it this way 
than the traditional way.

I also agree that the possibility of an exception thrown should not be hidden, 
but I think that's rather a documentation problem. (BTW, judging from the 
number of Linux kernel bugs, error code paths are also rarely tested if using 
the traditional way.)

> Performance: only when not being thrown can C++ exceptions have no overhead.

true, but if this gets thrown only once for every 50 million invocations and 
if every invocation only requires a single "if" statement for error detection, 
then c++ exceptions are still approximately one to 2.5 million times faster 
than the traditional approach...

> Modern compilers will emit code that cause no performance penalty when
> nothing is thrown, but if an exception is thrown it will have major
> performance consequences.

true: according to the stackoverflow article from above, the overhead of a 
thrown exception is equivalent to about 20 to 50 ifs. (plus cache effects, so 
let's make this a thousand ifs at worst.)

> This is quite all right usually, but it means
> that any code that uses exceptions for non-exceptional things, as
> alternative control flow, is going to be slow.

This is certainly also true. Although I did not argue for using exceptions for 
this case, right?

> So over time I gravitated towards the approach followed now in most of the
> software I have made -- report errors with the THROW(something) macro from
> ErrorMacros.hpp. This just sends file and line number plus the 'something'
> part to std::cerr, and throws a pure, unadorned std::exception.
> 
> I also have a slightly different opinion about that. IMHO it is okay to
> encode some information in what the error was within the exception object.
> I think of this as a modern version of the old-school C 'errno' variable.
> 
> I can agree that a little context in the exception object does not hurt (I
> did characterise my approach as a somewhat extreme after all…).
> 
> 
> It could be argued that this is somewhat extreme in its lack of information
> being transmitted with the exception, but my reasoning is as follows: most
> of the time, the context of the exception is important for debugging, and
> this cannot be carried by the exception.
> 
> punching 'catch throw'  into GDB makes it break whenever an exception is
> thrown. this is a thing that is very hard to do for the traditional way.
> Also, if more complicated breakpoint conditions are required, putting
> 'raise(SIGINT);' into your code makes GDB break at this location. For these
> reasons I think think exceptions are not hard to debug. (That is, of course,
> if you don't use them as a normal return mechanism.)
> 
> This is fine for a developer, but not for an end user. Trying to explain
> debugging in gdb to someone at a client company who just encountered a
> fatal error is not a good use of either's time.

I don't understand your argument: what is the end user going to do if he gets 
his program aborted due to some function failing if the traditional approach 
is used in contrast to exceptions?
 
> That is why the macro prints f

Re: [OPM] master branch numbering

[Andreas Lauser]

Hi,

On Monday 26 August 2013 13:38:11 Atgeirr Rasmussen wrote:
> Den 26. aug. 2013 kl. 15:24 skrev Andreas Lauser:
> > this issue appeared in PR 335 for opm-core, but it is a more "political"
> > problem, so I push it to the mailing list: What version should be used for
> > the master branches? As far as I can see, there are three alternatives:
> > 
> > (1) keep the version number of the previous release for the master branch.
> > That's the current OPM approach
> > (2) after a release, immediately increase the version number of the master
> > branch to the one of the next release (the current Dune approach)
> > (3) after a release, use the version that release for the development
> > branch, but increment the point release level to something
> > unrealistically high for the normal maintenance releases (99, say). This
> > is the approach KDE takes.
> > 
> > Since (1) and (2) come with severe compatibility issues which are hard to
> > spot, I'm inclined to (3), but this is approach also has some conceptual
> > impurities (i.e., misuse of the point release level)…
> 
> Our version numbers are more like strings than number sets, so can we use
> something like (3) with a string instead of a large number?

well, the problem is that strings are hard to check in the code. AFAIK there 
is no possibility to compare them in the preprocessor, so

#if OPM_IS_NEWER_THAN(2013,03)
// ...
#endif

won't work...

> For example: 2013.09-nextrelease
> 
> Otherwise, I think what we do now (1) would be the least confusing.

hm, what happens if something regresses the master branch, and the person 
affected sends his log (which says that the version is the one of the last 
release)? I at least would be totally confused. (with option (2) the confusion 
at least only happens if the person uses an 'intermediate version', i.e. they 
did not update their local copy after the next release.)

cheers
  Andreas

-- 
A programmer had a problem. He thought to himself, "I know, I'll solve it with 
threads!". has Now problems. two he
   -- Davidlohr Bueso

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

[OPM] master branch numbering

[Andreas Lauser]

Hi,

this issue appeared in PR 335 for opm-core, but it is a more "political" 
problem, so I push it to the mailing list: What version should be used for the 
master branches? As far as I can see, there are three alternatives:

(1) keep the version number of the previous release for the master branch. 
That's the current OPM approach
(2) after a release, immediately increase the version number of the master 
branch to the one of the next release (the current Dune approach)
(3) after a release, use the version that release for the development branch, 
but increment the point release level to something unrealistically high for 
the normal maintenance releases (99, say). This is the approach KDE takes.

Since (1) and (2) come with severe compatibility issues which are hard to 
spot, I'm inclined to (3), but this is approach also has some conceptual 
impurities (i.e., misuse of the point release level)...

Are there any options? Should the current state of affairs be changed after 
2013.09?

cheers
  Andreas

-- 
A programmer had a problem. He thought to himself, "I know, I'll solve it with 
threads!". has Now problems. two he
   -- Davidlohr Bueso

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

Re: [OPM] C++ exception policy in opm-core (and other libs)

[Andreas Lauser]

Hi All,

I somewhat disagree, see below.

On Friday 23 August 2013 07:50:32 Atgeirr Rasmussen wrote:
> In the early days of standard C++, I tried
> to be rigorous about always using very specific exception classes, creating
> a large hierarchy of such. However, I gradually stopped doing this, as I
> saw very little benefit, apart from some exceptional (pun aside, meaning
> very rarely) situations. 

I agree with this practice, the class hierarchy for exceptions should be 
small, and -- foremost -- flat.

> [...]
> (for example, a Newton solver not converging is not an exceptional thing).

That's a thing I see quite differently. The reason is that there are about a 
million things which could go wrong that make the newton solver diverge. If 
any and all of this cases is protected by a classical "if(error) return 
error;" guard, you take quite a performance hit (by means of the guards 
themselfs and by means of missed optimization opportunities). On the other 
hand, C++ exceptions do not negatively impact performance (for details, see 
http://stackoverflow.com/questions/13835817/are-exceptions-in-c-really-slow ).

> So over time I gravitated towards the approach followed now in most of the
> software I have made -- report errors with the THROW(something) macro from
> ErrorMacros.hpp. This just sends file and line number plus the 'something'
> part to std::cerr, and throws a pure, unadorned std::exception.

I also have a slightly different opinion about that. IMHO it is okay to encode 
some information in what the error was within the exception object. I think of 
this as a modern version of the old-school C 'errno' variable.

> It could be argued that this is somewhat extreme in its lack of information
> being transmitted with the exception, but my reasoning is as follows: most
> of the time, the context of the exception is important for debugging, and
> this cannot be carried by the exception.

punching 'catch throw'  into GDB makes it break whenever an exception is 
thrown. this is a thing that is very hard to do for the traditional way. Also, 
if more complicated breakpoint conditions are required, putting 
'raise(SIGINT);' into your code makes GDB break at this location. For these 
reasons I think think exceptions are not hard to debug. (That is, of course, 
if you don't use them as a normal return mechanism.)

> That is why the macro prints file
> and line number. On the other hand, the receiving end is rarely implemented
> (other than, perhaps at a very high level), and would not be able to use
> this information anyway.

This might be true for opm-core and opm-porsol, but eWoms catches 
'NumericalException' and tries again with a smaller timestep. As you can 
imagine, is a relatively common case.

> Introducing a new exception hierarchy is of dubious value. I think that once
> you has digested the appropriate usage of the standard range_error vs.
> out_of_range_error vs. invalid_argument vs. length_error and so on (quick
> quiz: what is appropriate for an index check in an array), you will not
> feel the need to complicate any further. If one feels the need for
> specialty exceptions that is fine, but they should be defined close to
> where they are used and inherit logic_error or runtime_error.

I agree that most of these exceptions should not be caught. But i think there 
is some value in the class-name of the exception object itself. Again, that's 
similar to the errno variable of libc. (what do you want to do if this one 
gets set to ENOMEM?)

> Finally, I'll state the obvious that we do not need to discuss. Yes, we
> allow throwing exceptions. Yes, all code should satisfy the basic exception
> safety guarantee (and all developers are assumed to understand what that
> means). No, we do not require the strong gurarantee (but perhaps we
> should).

IMHO these guarantees are quite easy to fulfill if you don't use C-style 
malloc()+free() memory management. Other options are welcome ;)

cheers
  Andreas

-- 
A programmer had a problem. He thought to himself, "I know, I'll solve it with 
threads!". has Now problems. two he
   -- Davidlohr Bueso

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

Re: [OPM] Build system organization rationale

[Andreas Lauser]

Hi,

On Tuesday 13 August 2013 22:29:24 Roland Kaufmann wrote:
> I have updated the rolk/opm-build proof-of-concept repo; one should now
> be able to "install" this repo and have the others (currently only the
> "build" branch of rolk/opm-core) pick that up, or one can leave it in a
> sibling directory. You can even use dunecontrol to build them!

I just tried your branch using dunecontrol and it works as advertised, thanks 
for the work!

In general, I'm much in favor of reducing n to 1 plus epsilon times n, but I'm 
quite indifferent on the matter of starting a new module for the build system 
or piggy-backing on opm-core. (that is, as long as all modules which use the 
OPM build system continue to depend on opm-core ;))

cheers
  Andreas

-- 
A programmer had a problem. He thought to himself, "I know, I'll solve it with 
threads!". has Now problems. two he
   -- Davidlohr Bueso

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

[OPM] RFC: The opm-common module

[Andreas Lauser]

Hi,

I've recently been working on a "more fundamental" module than opm-core to 
investigate whether this is a good idea (hint: I think it is). Now it starts 
being in a shape where it works and where I would appreciate feedback. If you 
want to have a look at the code, you can find it here:

https://github.com/andlaus/opm-common

I tentatively named this module "opm-common" in order to use the DUNE 
nomenclature, but this name seems to be a bit too close to opm-core, so a 
better name is appreciated. (Alternatively, renaming opm-core to something 
else ("baselibs"?) could be an option.)

The rules for this module are quite simple:

- Everything is a header file, i.e., it does not produce a library
- No prerequisites (except, perhaps, boost)

The primary motivation for it is to allow the 'opm-material' module to be 
usable without DUNE. This could make the material module useful for projects 
which are not fond on requiring DUNE (e.g., MRST). Another thing which could 
be done is to move the bulk of the build system to this module and leave only 
a shallow layer to find it in the other modules (which would somewhat amend the 
current divergence problems with the build system).

One thing that I noticed during hacking on this module is that the OPM source-
code file name conventions are a bit inconsistent: some modules use the .hh 
suffix for their headers, some use .hpp; some use CamelCase in file names (but 
interestingly enough not for directories), other use lowercase. IMHO we should 
formalize this a bit. I also volunteer to do the renaming if there is an 
consensus on this issue.

Looking forward to your comments
  Andreas

-- 
A programmer had a problem. He thought to himself, "I know, I'll solve it with 
threads!". has Now problems. two he
   -- Davidlohr Bueso

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

Re: [OPM] Build opm-porsol with opm-core installed somewhere

[Andreas Lauser]

Hi,

On Thursday 25 July 2013 13:10:39 Arne Morten Kvarving wrote:
> On 07/25/2013 01:05 PM, Joakim Hove wrote:
> > A bit naïve -- but anyway: I have done some modifications to opm-core,
> > built and installed the changes[1]. Then I want to build an updated
> > version of opm-porsol which makes use of my updated opm-core. Now I
> > wonder how to tell opm-porsol where to find the custom version of
> > opm-core?
> 
> easiest is through sibling directories.
> 
> e.g.
> 
> /foo
> 
> clone as
> /foo/opm-core
> /foo/omp-porsol
> 
> if you configure on top (no build sub dirs - bad roland! ;D) opm-porsol
> will pick up the opm-core, if you have built it first.

you could also create a branch for your modified version and switch between 
branches ad-hoc. (remember that branches in git are local if you don't push 
them explicitly.)

cheers
  Andreas

-- 
If the programmers like each other, they play a game called "pair 
programming". And if not, then the game is called "peer review".
-- Anna Nachesa

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

Re: [OPM] OPM build

[Andreas Lauser]

Hi julio,

On Thursday 25 July 2013 11:22:16 Júlio Hoffimann wrote:
> Next problem is related to the opm-porsol module. When I run make -j 8, it
> eats all my 8GB RAM and I have to shutdown the computer by hand. Any hints
> in what could be the cause?

that's probably the bulltet you have to bite if you use the C++ template 
mechanism. For templated code, the runtime performance and the maintainance 
might be better, but compile time and compiler memory cosumptions skyrocket. 
I'm affraid, that the best way to "fix" this issue is to hit the next computer 
store and buy a few RAM bars. (another possibility you can try is to use the 
clang compiler from the LLVM project. compared to GCC, it compiles faster and 
uses less memory but usually produces slightly slower code and is less well 
tested in the context of OPM.)

cheers
  Andreas

-- 
If the programmers like each other, they play a game called "pair 
programming". And if not, then the game is called "peer review".
-- Anna Nachesa

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

Re: [OPM] OPM build

[Andreas Lauser]

Hi Julio,

On Wednesday 24 July 2013 11:41:04 Júlio Hoffimann wrote:
> It's my first time trying to build OPM. As far as I understood, I need to
> clone all repositories in the same directory and, assuming all dependencies
> are installed, run the dunecontrol tool at the root:
> 
> $ ./dune-common-2.2.1/bin/dunecontrol all

so far, this should be okay.

> Again, if I understood it correctly, this is just a script that will check
> for all dune modules in the current directory and run the configure/make
> accordingly.

yes. another option is to enter the directory of the the opm module you which 
want to build, and run 'cmake .' within it. In this case, you have to manually 
compile all prerequisites upfront (i.e. all required DUNE/OPM modules).

> I'm having a hard time trying to fix some linkage errors, could you please
> guide me to the most up-to-date build steps? Is the CMake build fully
> working?

you will always use cmake since the last release; the 'configure' script now is 
just a shallow compatibility layer to make dunecontrol happy.

could you be a bit more specific about which linker errors you see, and for 
which module? One possibility is that, in addition to the dune tarballs which 
manually unpacked, you installed some DUNE packages provided by your linux 
distribution. This might lead to missing symbols if opm does not link in 
libraries which were used by the distribution package.

cheers
  Andreas

-- 
If the programmers like each other, they play a game called "pair 
programming". And if not, then the game is called "peer review".
-- Anna Nachesa

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

Re: [OPM] dune policy

[Andreas Lauser]

Hi,

On Wednesday 10 July 2013 17:28:13 Arne Morten Kvarving wrote:
> On 07/10/2013 05:22 PM, Bård Skaflestad wrote:
> > On Wed, 2013-07-10 at 17:01 +0200, Arne Morten Kvarving wrote:
> >> what's the current policy with regards to dune? opm master and dune
> >> master currently do not play well together.
> > 
> > I'm not sure we even *have* a policy.  That said, I'm inclined to
> > institute something along the lines of
> > 
> >  OPM is compatible with the latest, official Release version of
> >  the Dune core modules (currently 2.2.1, published on
> >  2013-02-27).  No effort is made to be compatible with older (or
> >  newer) versions of the Dune core modules.
> > 
> > That does leave a period of transition between the time of a new Dune
> > release (e.g., the 2.3 one that's coming up) and the time we catch up to
> > it though.
> > 
> > Still, it makes no sense to chase an in-flux target in my opinion.  The
> > OPM developer resources are strained as is and I think we should really
> > concentrate on improving (and extending) our core domain feature set.  I
> > also think development that is intended to be compatible with as-yet
> > unpublished Dune core modules (i.e., what will become Dune 2.3) should
> > happen in a separate branch in each affected OPM module (e.g., something
> > along the lines of "dune-next-compatible").
> 
> while i agree in principle, it becomes a big issue when you are working
> on extending opm modules with stuff that
> requires new dune functionality. exactly the case i'm in right now. but
> i have my answer, i'll keep relying on ugly patchery for now.

hm, I thought that DUNE has the policy that all code for release N will still 
compile with release N+1 (but with deprecation warnings). Maybe they ditched 
it in the mean time, though.

cheers
  Andreas

-- 
A programmer had a problem. He thought to himself, "I know, I'll solve it with 
threads!". has Now problems. two he
   -- Davidlohr Bueso

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

Re: [OPM] Front page picture

[Andreas Lauser]

Hi,

On Friday 24 May 2013 16:17:58 Alf Birger Rustad wrote:
> Not sure how attachments work, but suggestion for new illustration for
> web-site front page is attached to this mail. It is a screenshot of the
> Norne full field model taken  with Resinsight. Comments are welcome :)

nice :)

I only have a tiny nit: it might look slightly better if it was a bit more 
"from the top". On the other hand, that might also not be the case. Anyway, 
someone should create a pull request to put it online ASAP.

cheers
  Andreas

-- 
If the programmers like each other, they play a game called "pair 
programming". And if not, then the game is called "peer review".
-- Anna Nachesa

___
Opm mailing list
Opm@opm-project.org
http://www.opm-project.org/mailman/listinfo/opm

Re: [OPM] Xml / json

[Andreas Lauser]

Hi Joakim,

On Friday 10 May 2013 14:31:13 Joakim Hove wrote:
> the Eclipse parser we are writing should be run-time extendable, and to
> achieve that we need to load semantic information from a file. Personally I
> would prefer using json, but maybe there is a strong xml presedence? Any
> opinions?

I also prefer JSON because it tends to be less cluttery. IMHO the only reason 
to use XML for new code is needing stuff which JSON is not designed for. (e.g. 
namespaces)

cheers
  Andreas

-- 
A programmer had a problem. He thought to himself, "I know, I'll solve it with 
threads!". has Now problems. two he
   -- Davidlohr Bueso

___
Opm mailing list
Opm@opm-project.org
http://www.opm-project.org/mailman/listinfo/opm

[OPM] Website and Logo(s)

[Andreas Lauser]

Hi,

With our first release almost out of the door (thanks Atgeirr!), I think that 
there finally is time to deal with some meta issues. One of these is the 
website: The website is the first impression a potential user gets of the 
project, so I think that it should be rather good. IMO its currently doing 
quite well in some respects:

- The principle design and layout is simple, nice and functional
- The main content (what OPM is, links to the mailing list, screenshot 
gallery) is already on the site

Having said this, there are a few weaknesses IMO:

- Currently there's no 'download' link (that's what most people look for at 
first glance)
- The tutorials and the wiki are still not linked (although at least the 
tutorial part will be hopefully changed before the release)
- The news section tends to be a bit stale
- There is no real logo for the project as a whole and for the individual 
modules
- Each module should probably get an individual page which describes it
- The bugtrackers are too hard to find. also, there should be an explaination 
that each module uses its own issuetracker.

Some items (e.g. a more active news section) just require a bit of additional 
awareness of the developers, for others (e.g. bugtracker links, logos)  I'm 
not really sure what to do about. Are there any plans or options? Especially: 
do we need a "real" logo and if so, how can we get it?

cheers
  Andreas

-- 
Andreas Lauser
Department of Hydromechanics and Modelling of Hydrosystems
University of Stuttgart
Pfaffenwaldring 61
D-70569 Stuttgart
Phone: (+49) 711 685-64719
Fax: (+49) 711 685-60430
www.hydrosys.uni-stuttgart.de

___
Opm mailing list
Opm@opm-project.org
http://www.opm-project.org/mailman/listinfo/opm

Re: [OPM] Issue tracking

[Andreas Lauser]

Hi All,

(sorry for the repost, now it's quoted correctly. Stupid me!)

Am Dienstag, 2. April 2013, 10:04:09 schrieb Markus Blatt:
> On Tue, Apr 02, 2013 at 07:40:48AM +, Atgeirr Rasmussen wrote:
> > I think we have set up (but not activated) Flyspray on
> > opm-project.org<http://opm-project.org>. I am reluctant to start using
> > it, since I feel that github's issue system so far has been reasonably
> > usable.
> We are using flyspray for DUNE, but I have to say that I am not very
> fond of it. It does not seem to be actively developed any more and one
> always has to use the web interface.

I think they did a release not too long ago. (although DUNE is still on the 
older version, if I'm not mistaken.) There's also an active flyspray instance 
on opm-project.org: opm-project.org/flyspray 

(it even sends mails to the mailing list if there is activity in some issue.)

But as Atgeirr already said, it was decided to use the github bug tracker 
despite its problems. (To be fair, flyspray has some issues of its own, too.)

> With the issue tracker of github I can just answer by email. The only
> thing that is lacking is setting the In-Reply-To header such that my
> mail viewer can thread the messages. The biggest drawback of course is
> the lack of attaching files to bugs. I know that one can use gists for
> this, but that is very uncomfortable.

That's also my biggest complaint. (I got into the habit of uploading files to 
my private website to mend this somewhat.)
 
> >  A drawback of using github issues is that they are associated with only a
> >  single repo (although it is easy to cross-reference).> 
> > I would not mind having another system in addition, but there are
> > questions that should be answered, such as: what issues should go
> > where? How do we keep in sync?
> 
> I think one point for tracking issues is preferable. Otherwise people
> tend to not know where to post a particulare bug/feature request. (At
> least that holds for myself).

I think so too. Some time ago, I've also changed the website for the modules 
(i.e., http://opm-project.org/modules.php ) slightly to provide links to the 
issue trackers. A single menu entry "Issues" would be better IMHO, but I don't 
care too much... 

cheers
  Andreas

-- 
Andreas Lauser
Department of Hydromechanics and Modelling of Hydrosystems
University of Stuttgart
Pfaffenwaldring 61
D-70569 Stuttgart
Phone: (+49) 711 685-64719
Fax: (+49) 711 685-60430
www.hydrosys.uni-stuttgart.de

___
Opm mailing list
Opm@opm-project.org
http://www.opm-project.org/mailman/listinfo/opm

Re: [OPM] Issue tracking

[Andreas Lauser]

On Dienstag, 2. April 2013, 12:01:35 you wrote:
> Hi All,
> 
> Am Dienstag, 2. April 2013, 10:04:09 schrieb Markus Blatt:
> > On Tue, Apr 02, 2013 at 07:40:48AM +, Atgeirr Rasmussen wrote:
> > > I think we have set up (but not activated) Flyspray on
> > > opm-project.org<http://opm-project.org>. I am reluctant to start using
> > > it, since I feel that github's issue system so far has been reasonably
> > > usable.
> > 
> > We are using flyspray for DUNE, but I have to say that I am not very
> > fond of it. It does not seem to be actively developed any more and one
> > always has to use the web interface.
> 
> I think they did a release not too long ago. (although DUNE is still on the
> older version, if I'm not mistaken.) There's also an active flyspray
> instance on opm-project.org: opm-project.org/flyspray
> 
> (it even sends mails to the mailing list if there is activity in some
> issue.)
> 
> But as Atgeirr already said, it was decided to use the github bug tracker
> despite its problems. (To be fair, flyspray has some issues of its own,
> too.)
> > With the issue tracker of github I can just answer by email. The only
> > thing that is lacking is setting the In-Reply-To header such that my
> > mail viewer can thread the messages. The biggest drawback of course is
> > the lack of attaching files to bugs. I know that one can use gists for
> > this, but that is very uncomfortable.
> 
> That's also my biggest complaint. (I got into the habit of uploading files
> to my private website to mend this somewhat.)
> 
> > >  A drawback of using github issues is that they are associated with only
> > >  a
> > >  single repo (although it is easy to cross-reference).>
> > > 
> > > I would not mind having another system in addition, but there are
> > > questions that should be answered, such as: what issues should go
> > > where? How do we keep in sync?
> > 
> > I think one point for tracking issues is preferable. Otherwise people
> > tend to not know where to post a particulare bug/feature request. (At
> > least that holds for myself).
> 
> I think so too. Some time ago, I've also changed the website for the modules
> (i.e., http://opm-project.org/modules.php ) slightly to provide links to
> the issue trackers. A single menu entry "Issues" would be better IMHO, but
> I don't care too much...
> 
> cheers
>   Andreas
-- 
Andreas Lauser
Department of Hydromechanics and Modelling of Hydrosystems
University of Stuttgart
Pfaffenwaldring 61
D-70569 Stuttgart
Phone: (+49) 711 685-64719
Fax: (+49) 711 685-60430
www.hydrosys.uni-stuttgart.de

___
Opm mailing list
Opm@opm-project.org
http://www.opm-project.org/mailman/listinfo/opm

Re: [OPM] release compilation status

[Andreas Lauser]

Hi,

On Friday 08 March 2013 19:36:42 Atgeirr Rasmussen wrote:
> I agree that things are starting to look good. BTW, opm-polymer is not a
> dune module (it only requires opm-core, although if you want to use the
> istl solver it needs dune), or at least it has not been. I guess that it
> can be treated as one now, with Roland's 'configure' trick though. Extra
> flexibility is good!

I think so too. Considering the fact that opm-polymer already features a 
dune.module file, it would also not be much work to make it buildable using 
dunecontrol. AAICT, the only thing which is still required is the 
incorperation of the build system changes which have been incorperated into 
the other modules this week.

cheers
  Andreas

> 
> Fra: opm-boun...@opm-project.org [opm-boun...@opm-project.org] på vegne
> av Andreas Lauser [andreas.lau...@iws.uni-stuttgart.de] Sendt: 8. mars 2013
> 12:39
> To: opm@opm-project.org
> Emne: [OPM] release compilation status
> 
> Hi,
> 
> I just tried to compile the current version of all modules which contain
> 'release/2013.03' branch using dunecontrol and almost succeeded. The only
> module which failed was opm-polymer. This failed only because Roland's
> recent build system fixes where not applied to the opm-polymer module for
> some reason. (probably it was just forgotten.)
> 
> Anyway, I think that things are looking quite well for the release...
> 
> cheers
>   Andreas
> 
> --
> Andreas Lauser
> Department of Hydromechanics and Modelling of Hydrosystems
> University of Stuttgart
> Pfaffenwaldring 61
> D-70569 Stuttgart
> Phone: (+49) 711 685-64719
> Fax: (+49) 711 685-60430
> www.hydrosys.uni-stuttgart.de
> 
> ___
> Opm mailing list
> Opm@opm-project.org
> http://www.opm-project.org/mailman/listinfo/opm
> 
> ___
> Opm mailing list
> Opm@opm-project.org
> http://www.opm-project.org/mailman/listinfo/opm
-- 
Be cheerful while you are alive.
-- Phathotep, 24th Century B.C.

___
Opm mailing list
Opm@opm-project.org
http://www.opm-project.org/mailman/listinfo/opm

[OPM] release compilation status

[Andreas Lauser]

Hi,

I just tried to compile the current version of all modules which contain 
'release/2013.03' branch using dunecontrol and almost succeeded. The only 
module which failed was opm-polymer. This failed only because Roland's recent 
build system fixes where not applied to the opm-polymer module for some reason.
(probably it was just forgotten.)

Anyway, I think that things are looking quite well for the release...

cheers
  Andreas

-- 
Andreas Lauser
Department of Hydromechanics and Modelling of Hydrosystems
University of Stuttgart
Pfaffenwaldring 61
D-70569 Stuttgart
Phone: (+49) 711 685-64719
Fax: (+49) 711 685-60430
www.hydrosys.uni-stuttgart.de

___
Opm mailing list
Opm@opm-project.org
http://www.opm-project.org/mailman/listinfo/opm

Re: [OPM] ECLIPSE Parser + ECLIPSE summary results

[Andreas Lauser]

Hi,

Am Montag, 4. März 2013, 14:53:32 schrieb Atgeirr Rasmussen:
> >> The EclipseGridParser class grew up from a simple keyword + data
> >> abstraction. I would say that for not-too-complex needs, it remains a
> >> valid
> >> choice. Reading .grdecl files is one such case.
> > 
> > Of what Bard wrote so far, this basic design should also be applicable to
> > all eclipse datasets if the syntactic part of the parser deals with the
> > INPUT directive and the basic representation is a list of (keyword,
> > string*) tuples.
> > 
> > In my limited dives into the EclipseGridParser code,  I got the impression
> > that its main problem is that it is trying to lump together the syntactic
> > and semantic parts of parsing.
> 
> This is true to some degree.
> 
> Still, we are only discussing an implementation detail. I would rather
> discuss what a useful interface would look like… And unless Joakim is in a
> hurry, I would like to resume that discussion after the OPM release…

Agreed. I'll also be able to help a bit with the implementation, then.

cheers
  Andreas

-- 
Andreas Lauser
Department of Hydromechanics and Modelling of Hydrosystems
University of Stuttgart
Pfaffenwaldring 61
D-70569 Stuttgart
Phone: (+49) 711 685-64719
Fax: (+49) 711 685-60430
www.hydrosys.uni-stuttgart.de

___
Opm mailing list
Opm@opm-project.org
http://www.opm-project.org/mailman/listinfo/opm