From Atgeirr.Rasmussen at sintef.no Tue Mar 1 09:34:02 2016 From: Atgeirr.Rasmussen at sintef.no (Atgeirr Rasmussen) Date: Tue, 1 Mar 2016 09:34:02 +0000 Subject: [Opm] A note on upgrading Dune (and possibly other third-party packages) Message-ID: <776D0FD1-58CD-4AF9-A927-75171D9D9848@sintef.no> Dear OPM community, Yesterday a new version of Dune was released (2.4.1) and I had some problems compiling OPM after updating. However, the fix is simple: delete your build directories (for opm modules depending on Dune modules, which are almost all opm modules except opm-common and opm-parser) and reconfigure them with cmake. After that, everything should be working with the new Dune version. The underlying issue is that the config.h files that are generated by cmake in your build directories must be updated, so that the version constants in those files becomes correct. Atgeirr From joakim.hove at gmail.com Mon Mar 14 17:54:17 2016 From: joakim.hove at gmail.com (Joakim Hove) Date: Mon, 14 Mar 2016 18:54:17 +0100 Subject: [Opm] New opm-repo Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abir at statoil.com Tue Mar 15 08:47:52 2016 From: abir at statoil.com (Alf Birger Rustad) Date: Tue, 15 Mar 2016 08:47:52 +0000 Subject: [Opm] New opm-repo In-Reply-To: References: Message-ID: <3FF3DEAF482AE047BE357963DF9C4F8AAD96B5A5@WS319.statoil.net> Thanks for the announcement! There is one issue that I hope everybody with informed opinions can contribute to. Today, writing results is a performance bottleneck flow. Hence, we should find a way for flow to write results asynchronously, i.e., the simulator should not need to wait computing the next timestep while the results are written. It has been suggested to split out the writing in a separate process to accomplish this, but I am not sure how this could be done in a good way. Implementing the writer as a server seems like over-engineering, and we probably do not want to mandate MPI to run the simulator. The simplest option I can think of is splitting the writing to a new thread with openmp. Your thoughts are welcome! Alf ________________________________ From: Opm [opm-bounces at opm-project.org] on behalf of Joakim Hove [joakim.hove at gmail.com] Sent: Monday, March 14, 2016 6:54 PM To: opm at 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 ------------------------------------------------------------------- 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 Tue Mar 15 10:20:46 2016 From: markus at dr-blatt.de (Markus Blatt) Date: Tue, 15 Mar 2016 11:20:46 +0100 Subject: [Opm] New opm-repo In-Reply-To: <3FF3DEAF482AE047BE357963DF9C4F8AAD96B5A5@WS319.statoil.net> References: <3FF3DEAF482AE047BE357963DF9C4F8AAD96B5A5@WS319.statoil.net> Message-ID: <20160315102046.GA9730@boromir.dr-blatt.de> Hi, On Tue, Mar 15, 2016 at 08:47:52AM +0000, Alf Birger Rustad wrote: > Thanks for the announcement! There is one issue that I hope > everybody with informed opinions can contribute to. Today, writing > results is a performance bottleneck flow. Hence, we should find a > way for flow to write results asynchronously, i.e., the simulator > should not need to wait computing the next timestep while the > results are written. It has been suggested to split out the writing > in a separate process to accomplish this, but I am not sure how this > could be done in a good way. Implementing the writer as a server > seems like over-engineering, and we probably do not want to mandate > MPI to run the simulator. The simplest option I can think of is > splitting the writing to a new thread with openmp. As I am the one who brought this up, I have to relativate this a bit. I experienced this bottleneck for a parallel run with 8 cores. The time spent for output was 31% of the total time. For a sequential run it is probably below 10% but I have not measured it. Minimizing the time for the ouput of a sequential run as proposed comes at cost, too. We need to duplicate the memory. What I am concerned about is that the output is not parallel at all which will bite us more when using more cores. Having a dedicated output core is just a first step. Ultimately, we need several cores doing output in parallel in a parallel file format. But this can wait some time, I guess. Cheers, Markus -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From roland.kaufmann at uni.no Tue Mar 15 12:19:56 2016 From: roland.kaufmann at uni.no (Roland Kaufmann) Date: Tue, 15 Mar 2016 13:19:56 +0100 Subject: [Opm] New opm-repo In-Reply-To: <3FF3DEAF482AE047BE357963DF9C4F8AAD96B5A5@WS319.statoil.net> References: <3FF3DEAF482AE047BE357963DF9C4F8AAD96B5A5@WS319.statoil.net> Message-ID: <56E7FDEC.3080406@uni.no> On 15. Mar. 2016 at 09:47, Alf Birger Rustad wrote: > Today, writing results is a performance bottleneck flow. > ... > the simulator should not need to wait computing the next timestep > while the results are written. It has been suggested to split out the > writing in a separate process to accomplish this, but I am not sure > how this could be done in a good way. From an engineering view, I would guess fork-and-dump (on Linux and BSDs) is the most practical one, but I guess you probably want the code to stay portable C++. Then probably something with putting the result in a boost::interprocess::mapped_region can apply. Otherwise, I don't quite see how IPC to another process should be significantly faster than writing the results to a disk buffer. And the relative timings that Markus gives indicate that perhaps much can be achieved by doing a profile of the output rendering code and see if there are any bottlenecks that can be addressed there first. -- Roland. From and at poware.org Tue Mar 15 13:04:39 2016 From: and at poware.org (Andreas Lauser) Date: Tue, 15 Mar 2016 14:04:39 +0100 Subject: [Opm] New opm-repo In-Reply-To: <3FF3DEAF482AE047BE357963DF9C4F8AAD96B5A5@WS319.statoil.net> References: <3FF3DEAF482AE047BE357963DF9C4F8AAD96B5A5@WS319.statoil.net> Message-ID: <3551128.AJqB4ppqRF@heuristix> 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-bounces at opm-project.org] on behalf of Joakim Hove > [joakim.hove at gmail.com] Sent: Monday, March 14, 2016 6:54 PM > To: opm at 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 -------------- 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 Robert.Kloefkorn at iris.no Tue Mar 15 13:10:39 2016 From: Robert.Kloefkorn at iris.no (Robert Kloefkorn) Date: Tue, 15 Mar 2016 14:10:39 +0100 Subject: [Opm] New opm-repo In-Reply-To: <3551128.AJqB4ppqRF@heuristix> References: <3FF3DEAF482AE047BE357963DF9C4F8AAD96B5A5@WS319.statoil.net> <3551128.AJqB4ppqRF@heuristix> Message-ID: <56E809CF.2090102@iris.no> Hi all, > 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.) I only see one way to solve this problem: Write parallel output based on the backup/restore routines that I have implemented (not ECL restart) and then have a different process or the Visualization tool collect the data from the parallel format. This is how I have done this in DUNE and it works very well. Other than that I agree with Andreas. Best, Rob From abir at statoil.com Tue Mar 15 15:42:31 2016 From: abir at statoil.com (Alf Birger Rustad) Date: Tue, 15 Mar 2016 15:42:31 +0000 Subject: [Opm] New opm-repo In-Reply-To: <20160315102046.GA9730@boromir.dr-blatt.de> References: <3FF3DEAF482AE047BE357963DF9C4F8AAD96B5A5@WS319.statoil.net>, <20160315102046.GA9730@boromir.dr-blatt.de> Message-ID: <3FF3DEAF482AE047BE357963DF9C4F8AAD96C57A@WS319.statoil.net> Thanks for the feed-back everyone! Actually, even on a serial run I have output writing accounting for 11% of the computational time on Norne. Splitting it in a separate thread with asynchronous writing should bring that down to practically zero with no extra dependencies required, and without memory duplication. Making the writing fully parallel seems like a larger undertaking which can be done for the mpi version. Cheers, Alf ________________________________________ From: Opm [opm-bounces at opm-project.org] on behalf of Markus Blatt [markus at dr-blatt.de] Sent: Tuesday, March 15, 2016 11:20 AM To: opm at opm-project.org Subject: Re: [Opm] New opm-repo Hi, On Tue, Mar 15, 2016 at 08:47:52AM +0000, Alf Birger Rustad wrote: > Thanks for the announcement! There is one issue that I hope > everybody with informed opinions can contribute to. Today, writing > results is a performance bottleneck flow. Hence, we should find a > way for flow to write results asynchronously, i.e., the simulator > should not need to wait computing the next timestep while the > results are written. It has been suggested to split out the writing > in a separate process to accomplish this, but I am not sure how this > could be done in a good way. Implementing the writer as a server > seems like over-engineering, and we probably do not want to mandate > MPI to run the simulator. The simplest option I can think of is > splitting the writing to a new thread with openmp. As I am the one who brought this up, I have to relativate this a bit. I experienced this bottleneck for a parallel run with 8 cores. The time spent for output was 31% of the total time. For a sequential run it is probably below 10% but I have not measured it. Minimizing the time for the ouput of a sequential run as proposed comes at cost, too. We need to duplicate the memory. What I am concerned about is that the output is not parallel at all which will bite us more when using more cores. Having a dedicated output core is just a first step. Ultimately, we need several cores doing output in parallel in a parallel file format. But this can wait some time, I guess. Cheers, Markus -- 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 ------------------------------------------------------------------- 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 From yanhui.zhang at tno.nl Tue Mar 22 08:43:46 2016 From: yanhui.zhang at tno.nl (Zhang, Y. (Yanhui)) Date: Tue, 22 Mar 2016 08:43:46 +0000 Subject: [Opm] Test run on two phases flow simulation Message-ID: <57AC0B92C127344FA70904B2E6AACEE90F1BB3EA@EXC-MBX02.tsn.tno.nl> Dear all, We are trying to run a two phases flow (oil and water) simulation with OPM. However, we confronted an exception like below [cid:image001.png at 01D1841F.52838A60] We would really appreciate it if anyone here could answer us this question. Thanks in advance. Best regards, Yanhui This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 16501 bytes Desc: image001.png URL: From Atgeirr.Rasmussen at sintef.no Tue Mar 22 09:34:20 2016 From: Atgeirr.Rasmussen at sintef.no (Atgeirr Rasmussen) Date: Tue, 22 Mar 2016 09:34:20 +0000 Subject: [Opm] Test run on two phases flow simulation In-Reply-To: <57AC0B92C127344FA70904B2E6AACEE90F1BB3EA@EXC-MBX02.tsn.tno.nl> References: <57AC0B92C127344FA70904B2E6AACEE90F1BB3EA@EXC-MBX02.tsn.tno.nl> Message-ID: <7739A456-1A85-4B19-81CA-63A9BCAE2737@sintef.no> Dear Yanhui, The answer is simply that Flow does not at the moment support 2-phase runs. We think this is unfortunate, and it is on our short list of things we want to fix (probably in a month's time). Meanwhile you have a few possible workarounds: 1. Add a dummy gas phase to your case (specifying trivial PVDG and SGOF tables for example). 2. Use the sim_2p_incomp_ad program instead (only valid if fluids are incompressible, and full deck support not as advanced as in Flow). I hope this is sufficient to allow you to solve your problem for the time being. Atgeirr 22. mar. 2016 kl. 09.43 skrev Zhang, Y. (Yanhui) >: Dear all, We are trying to run a two phases flow (oil and water) simulation with OPM. However, we confronted an exception like below We would really appreciate it if anyone here could answer us this question. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: