From Atgeirr.Rasmussen at sintef.no Tue Nov 1 12:08:28 2016 From: Atgeirr.Rasmussen at sintef.no (Atgeirr Rasmussen) Date: Tue, 1 Nov 2016 12:08:28 +0000 Subject: [Opm] OPM release 2016.10 Message-ID: <4BD04108-A717-41DF-97A5-30D316C60C5D@sintef.no> Dear OPM community, We are pleased to announce the availability of OPM release 2016.10! This is the second release this year, the previous release was 2016.04. The next release is expected to be 2017.04. The release brings major improvements to the output capabilities of Flow, the fully implicit black-oil reservoir simulator. This includes improvements to summary and restart output, which is now controllable from the input deck, and also improved logging behaviour. In addition there are numerous minor feature additions and bugfixes throughout all modules. There are only minor changes to the module structure, see the updated modules page (http://opm-project.org/?page_id=274). We’d like to thank all who played a part in the release, for finding bugs, posting issues, writing code, reviewing, testing and packaging. Instructions for installation are found on our download page: http://opm-project.org/?page_id=36 Binary packages are available for Ubuntu (now) and Red Hat Enterprise Linux (tomorrow), instructions are available for building from source for any Linux variant or Mac OS X. Atgeirr Flø Rasmussen -------------- next part -------------- An HTML attachment was scrubbed... URL: From and at poware.org Mon Nov 14 11:38:29 2016 From: and at poware.org (Andreas Lauser) Date: Mon, 14 Nov 2016 12:38:29 +0100 Subject: [Opm] Significant changes for the opm-simulators module ahead Message-ID: <21757753.SgzuBSJsBj@heuristix> 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) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From joaho at statoil.com Mon Nov 14 15:01:02 2016 From: joaho at statoil.com (Joakim Hove) Date: Mon, 14 Nov 2016 15:01:02 +0000 Subject: [Opm] Travis trouble Message-ID: <20B5971397608672.133d10a3-a126-42a2-845f-30ecf0b70e09@mail.outlook.com> Hello, at the moment all Travis builds fail due to timeout. According to google Travis has a 50 minutes time limit, it is my impression that they have "suddenly?" started to enforce that limit. Joakim Få Outlook for Android ------------------------------------------------------------------- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From arne.morten.kvarving at sintef.no Mon Nov 14 15:02:41 2016 From: arne.morten.kvarving at sintef.no (Arne Morten Kvarving) Date: Mon, 14 Nov 2016 16:02:41 +0100 Subject: [Opm] Travis trouble In-Reply-To: <20B5971397608672.133d10a3-a126-42a2-845f-30ecf0b70e09@mail.outlook.com> References: <20B5971397608672.133d10a3-a126-42a2-845f-30ecf0b70e09@mail.outlook.com> Message-ID: <31f89772-bde3-fa38-051b-f11cab0fd6c9@sintef.no> On 14. nov. 2016 16:01, Joakim Hove wrote: > > Hello, > > at the moment all Travis builds fail due to timeout. According to > google Travis has a 50 minutes time limit, it is my impression that > they have "suddenly?" started to enforce that limit. > as a short-term fix i suggest not passing -DBUILD_TESTING to ewoms. it will cut down the build time considerably (at the obvious cost of not executing ewoms tests). arnem -------------- next part -------------- An HTML attachment was scrubbed... URL: From and at poware.org Mon Nov 14 16:19:46 2016 From: and at poware.org (Andreas Lauser) Date: Mon, 14 Nov 2016 17:19:46 +0100 Subject: [Opm] Version information? In-Reply-To: <580732A5.9040106@iws.uni-stuttgart.de> References: <580732A5.9040106@iws.uni-stuttgart.de> Message-ID: <246546256.Q176PggBnq@heuristix> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From Atgeirr.Rasmussen at sintef.no Mon Nov 14 17:26:59 2016 From: Atgeirr.Rasmussen at sintef.no (Atgeirr Rasmussen) Date: Mon, 14 Nov 2016 17:26:59 +0000 Subject: [Opm] Version information? In-Reply-To: <580732A5.9040106@iws.uni-stuttgart.de> References: <580732A5.9040106@iws.uni-stuttgart.de> Message-ID: Hi Bernd, This is not something we have given very much attention. Basically our assumption has been that ensuring the releases are solid is enough. However, as maturity increases in general, and people come to rely on the code we should do something more about this. The only place such information is currently written is in the build-system-generated file project-version.h, which is used from for example opm/autodiff/moduleVersion.cpp in the opm-simulators module (note inclusion with "" rather than <>, it is residing in the build tree, not the code tree). For each module, the file looks like this for debug builds: #ifndef OPM_GENERATED_OPM_VERSION_HEADER_INCLUDED #define OPM_GENERATED_OPM_VERSION_HEADER_INCLUDED #define PROJECT_VERSION_NAME "2017.04-pre" #define PROJECT_VERSION_HASH "debug" #define PROJECT_VERSION "2017.04-pre (debug)" #endif // OPM_GENERATED_OPM_VERSION_HEADER_INCLUDED … and like this for release builds: #ifndef OPM_GENERATED_OPM_VERSION_HEADER_INCLUDED #define OPM_GENERATED_OPM_VERSION_HEADER_INCLUDED #define PROJECT_VERSION_NAME "2017.04-pre" #define PROJECT_VERSION_HASH "736585e*" #define PROJECT_VERSION "2017.04-pre (736585e*)" #endif // OPM_GENERATED_OPM_VERSION_HEADER_INCLUDED The git hash is of course different from repo to repo, and we do not use it at the moment. The idea is that it can help identify exact version in case of error, but collecting it across repos is not easy so we has not done that yet. So the only part we actually use in Flow is the PROJECT_VERSION_NAME. This is generated from the dune.module file, that contains something like: Version: 2017.04-pre Label: 2017.04-pre For the release branches, we lose the "-pre" part, after the next release (2017.04) the new version will be "2017.10-pre". I hope this is enough information for you to do what you need. If you have suggestions for improvements, please tell me! Atgeirr Dear Opm, 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. Kind regards Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.kaufmann at uni.no Mon Nov 14 22:55:22 2016 From: roland.kaufmann at uni.no (Roland Kaufmann) Date: Mon, 14 Nov 2016 23:55:22 +0100 Subject: [Opm] Version information? In-Reply-To: <246546256.Q176PggBnq@heuristix> References: <580732A5.9040106@iws.uni-stuttgart.de> <246546256.Q176PggBnq@heuristix> Message-ID: <16d657df-cfa0-fbc2-38ca-b0d61a03c62b@uni.no> On 19. Oct. 2016 at 10:45, Bernd Flemisch wrote: >> 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. Personally, I like to have macros that define the version together with the interface, for just this reason. But these have to be *manually* updated according to the level of changes made, and should also be combined with adherence to semver[*]-style so-naming lest you may introduce subtle bugs if things get out of sync. 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. 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. -- Roland. [*] From and at poware.org Tue Nov 15 23:21:26 2016 From: and at poware.org (Andreas Lauser) Date: Wed, 16 Nov 2016 00:21:26 +0100 Subject: [Opm] Version information? In-Reply-To: <16d657df-cfa0-fbc2-38ca-b0d61a03c62b@uni.no> References: <580732A5.9040106@iws.uni-stuttgart.de> <246546256.Q176PggBnq@heuristix> <16d657df-cfa0-fbc2-38ca-b0d61a03c62b@uni.no> Message-ID: <3289463.yzbCzuHVtp@singularius> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part. URL: From liuming1035 at gmail.com Fri Nov 18 06:57:01 2016 From: liuming1035 at gmail.com (Ming Liu) Date: Fri, 18 Nov 2016 14:57:01 +0800 Subject: [Opm] GoodBye OPM Message-ID: Dear community, As you probably know Statoil decided to close its China R&D center, and we must leave the company. This news happened so suddenly, I even didn't have time to think about, but now I can calm down and say goodbye to the community. I know this mailing list is used to discuss the problem about any OPM issues, I considered to send mail to all the developer, but I can't access to my Statoil mailbox and can't find the mail address, so this is a good place if this email troubles you, I'm sorry. Since I joined Statoil, I only work for OPM, this is the project that I grow and learn. It was such a great time to work with all of you, I learn a lot from you! I really appreciate your help during my work. Whatever stupid codes I submit and whatever stupid mistake I made, all of you can tolerant and guide me to the right place, and even my bad English skill. :) What I learn most in this community is your professional, which impress me very much, probably you called it "nitpick", but I think that's the attitude to work. Here I don't want to say the specified names, I just want to thank all of you, for your tolerance, help, and nice communication. It was such a pleasure time to work with you, I really enjoy and appreciate. I'm very lucky to work in this community when I started my career, this is a big treasure for me. But it's time to say goodbye, I will remember all of you and pay close attention to this project. Thanks! Best regards, Liu Ming -------------- next part -------------- An HTML attachment was scrubbed... URL: From Atgeirr.Rasmussen at sintef.no Fri Nov 18 07:23:35 2016 From: Atgeirr.Rasmussen at sintef.no (Atgeirr Rasmussen) Date: Fri, 18 Nov 2016 07:23:35 +0000 Subject: [Opm] GoodBye OPM In-Reply-To: References: Message-ID: <70B11E9C-6500-4980-AC1D-E1F0AAA197F4@sintef.no> Dear Ming, I am sorry to hear that you will no longer be able to collaborate with us. It was always a pleasure to work with you! I appreciated the times we met in person, and noted your positive attitude and eagerness to learn. Good luck with your future endeavors, and I hope perhaps our paths will cross! Atgeirr From oilamah at gmail.com Mon Nov 21 10:49:27 2016 From: oilamah at gmail.com (Ilamah, Osho) Date: Mon, 21 Nov 2016 10:49:27 +0000 Subject: [Opm] RHEL7 Repository Message-ID: Hi, Firstly, thank you all for the amazing work you have been doing. I recently attempted to install the OPM simulator on RHEL machines. The instructions provided were easy to follow and worked ok for RHEL6. For RHEL7, "yum install opm-simulators-bin" failed, complaining about a missing ert library (libert_utilxx). On careful inspection of the RHEL6 and RHEL7 yum repositories, I noticed that there is a libert.ecl1-2016.10-0.x86_64.rpm package in the RHEL6 yum repository package folder that is not present in the RHEL7 repository package folder (there is libert.ecl1-2016.04-0.x86_64.rpm for 2016.04 but no libert.ecl1-2016.10-0.x86_64.rpm for 2016.10 in http://www.opm-project.org/package/redhat/7/). As a workaround, I downloaded libert.ecl1-2016.10-0.x86_64.rpm from the RHEL6 yum repository package folder, ran "yum localinstall libert.ecl1-2016.10-0.x86_64.rpm" against this downloaded rpm, on the RHEL7 machine. This makes the libert_utilxx libraries available on the RHEL7 machine. I can then suceessfully run "yum install opm-simulators-bin" to install the other packages from the RHEL7 repo on this machine. I am reporting this, in the hope that you may be able to upload libert.ecl1-2016.04-0.x86_64.rpm into the RHEL7 repository package folder to permanently resolve this issue. Thanks Osho -------------- next part -------------- An HTML attachment was scrubbed... URL: From abir at statoil.com Tue Nov 22 11:30:08 2016 From: abir at statoil.com (Alf Birger Rustad) Date: Tue, 22 Nov 2016 11:30:08 +0000 Subject: [Opm] RHEL7 Repository In-Reply-To: References: Message-ID: <3FF3DEAF482AE047BE357963DF9C4F8AC28ED81C@WS319.statoil.net> Hi Osho, Thanks for your testing and report! Glad you found a work-around, in the mean-time we will try to get the packages in place. Best, Alf From: Opm [mailto:opm-bounces at opm-project.org] On Behalf Of Ilamah, Osho Sent: 21. november 2016 11:49 To: opm at opm-project.org Subject: [Opm] RHEL7 Repository Hi, Firstly, thank you all for the amazing work you have been doing. I recently attempted to install the OPM simulator on RHEL machines. The instructions provided were easy to follow and worked ok for RHEL6. For RHEL7, "yum install opm-simulators-bin" failed, complaining about a missing ert library (libert_utilxx). On careful inspection of the RHEL6 and RHEL7 yum repositories, I noticed that there is a libert.ecl1-2016.10-0.x86_64.rpm package in the RHEL6 yum repository package folder that is not present in the RHEL7 repository package folder (there is libert.ecl1-2016.04-0.x86_64.rpm for 2016.04 but no libert.ecl1-2016.10-0.x86_64.rpm for 2016.10 in http://www.opm-project.org/package/redhat/7/). As a workaround, I downloaded libert.ecl1-2016.10-0.x86_64.rpm from the RHEL6 yum repository package folder, ran "yum localinstall libert.ecl1-2016.10-0.x86_64.rpm" against this downloaded rpm, on the RHEL7 machine. This makes the libert_utilxx libraries available on the RHEL7 machine. I can then suceessfully run "yum install opm-simulators-bin" to install the other packages from the RHEL7 repo on this machine. I am reporting this, in the hope that you may be able to upload libert.ecl1-2016.04-0.x86_64.rpm into the RHEL7 repository package folder to permanently resolve this issue. Thanks Osho ------------------------------------------------------------------- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oilamah at gmail.com Tue Nov 22 12:08:08 2016 From: oilamah at gmail.com (Ilamah, Osho) Date: Tue, 22 Nov 2016 12:08:08 +0000 Subject: [Opm] RHEL7 Repository In-Reply-To: <3FF3DEAF482AE047BE357963DF9C4F8AC28ED81C@WS319.statoil.net> References: <3FF3DEAF482AE047BE357963DF9C4F8AC28ED81C@WS319.statoil.net> Message-ID: Thanks Alf. Arne uploaded the packages yesterday. Thanks once again. Regards Osho On Tue, Nov 22, 2016 at 11:30 AM, Alf Birger Rustad wrote: > Hi Osho, > > > > Thanks for your testing and report! Glad you found a work-around, in the > mean-time we will try to get the packages in place. > > > > Best, > > Alf > > > > > > *From:* Opm [mailto:opm-bounces at opm-project.org] *On Behalf Of *Ilamah, > Osho > *Sent:* 21. november 2016 11:49 > *To:* opm at opm-project.org > *Subject:* [Opm] RHEL7 Repository > > > > Hi, > > Firstly, thank you all for the amazing work you have been doing. > > I recently attempted to install the OPM simulator on RHEL machines. The > instructions provided were easy to follow and worked ok for RHEL6. For > RHEL7, "yum install opm-simulators-bin" failed, complaining about a missing > ert library (libert_utilxx). On careful inspection of the RHEL6 and RHEL7 > yum repositories, I noticed that there is a libert.ecl1-2016.10-0.x86_64.rpm > package in the RHEL6 yum repository package folder that is not present in > the RHEL7 repository package folder (there is libert.ecl1-2016.04-0.x86_64.rpm > for 2016.04 but no libert.ecl1-2016.10-0.x86_64.rpm for 2016.10 in > http://www.opm-project.org/package/redhat/7/). > > As a workaround, I downloaded libert.ecl1-2016.10-0.x86_64.rpm from the > RHEL6 yum repository package folder, ran "yum localinstall > libert.ecl1-2016.10-0.x86_64.rpm" against this downloaded rpm, on the > RHEL7 machine. This makes the libert_utilxx libraries available on the > RHEL7 machine. I can then suceessfully run "yum install opm-simulators-bin" > to install the other packages from the RHEL7 repo on this machine. > > I am reporting this, in the hope that you may be able to upload > libert.ecl1-2016.04-0.x86_64.rpm into the RHEL7 repository package folder > to permanently resolve this issue. > > Thanks > > Osho > > > ------------------------------------------------------------------- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus at dr-blatt.de Wed Nov 23 17:02:57 2016 From: markus at dr-blatt.de (Markus Blatt) Date: Wed, 23 Nov 2016 18:02:57 +0100 Subject: [Opm] OPM release 2016.10 In-Reply-To: <4BD04108-A717-41DF-97A5-30D316C60C5D@sintef.no> References: <4BD04108-A717-41DF-97A5-30D316C60C5D@sintef.no> Message-ID: <20161123170257.GE2146@boromir.dr-blatt.de> FYI I did send out notifications to the siam cse, siam Geoscience, and na-digest list, to spread the word a bit wider. -- Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de Hans-Bunte-Str. 8-10, 69123 Heidelberg, Germany, USt-Id: DE279960836 Tel.: +49 (0) 160 97590858