, at the time of writing, is
20.04 LTS (Dune 2.6) and 22.04 LTS (Dune 2.8). In my opinion it is bringing
more recent versions of Dune into the mix that will create an undue maintenance
burden.
Best Regards,
Bård Skaflestad
SINTEF Digital, Mathematics & Cybernetics
Computational Geosciences g
-simulators/issues/2889).
Best Regards,
Bård Skaflestad
SINTEF Digital, Mathematics & Cybernetics, Computational Geosciences group
Release Manager OPM 2020.10 Release
Release Notes for OPM 2020.10 Release
Since the OPM 2020.04 release in May 2020 we have worked on many asp
t; package repositories to your package sources and update the
packages using 'apt'.
Specifically, the following commands will bring in the new package references
sudo add-apt-repository ppa:opm/testing
sudo apt-get update
Please report any issues you see to the mailing list.
Best Rega
the final release tags on Thursday 5th November, around
noon CET, and then the final packages will be available within 24 hours of
those tags being created.
Best Regards,
Bård Skaflestad
___
Opm mailing list
Opm@opm-project.org
https://opm-proje
arring any late-minute issues
discovered during testing however we don't anticipate any additional release
candidates before the final release.
Best Regards,
Bård Skaflestad
SINTEF Digital, Mathematics & Cybernetics Computational Geosciences group
Release Manager for OPM 2
pm/testing
sudo apt-get update
Please report any issues you see to the mailing list.
Best Regards,
Bård Skaflestad
SINTEF Digital, Mathematics & Cybernetics
Computational Geosciences group
Release Manager for OPM 2020.10 Release
___
Opm mailin
, and as previously
advertised, no new features merged into the "master" branches from now on will
be part of the 2020.10 release.
We will post a new message once binary packages of the first release candidate
are available.
Best Regards,
Bård Skaflestad
Release Manager, OPM 2020.
testing and bugfixing if needed
* Final release Thursday 29th of October
To the developers: Please prepare any in-progress work that is scheduled for
the 2020.10 release to be in a mergeable state by the feature freeze deadline.
Sincerely,
Bård Skaflestad
SINTEF Digital, Mathematics
s is a bug in OPM Flow and we're tracking it in OPM-Common Issue 694
(https://github.com/OPM/opm-common/issues/694).
Best Regards,
Bård Skaflestad
SINTEF Digital, Mathematics & Cybernetics
Computational Geosciences group
-Original Message-
From: Opm On Behalf Of Nikolai Andrianov
y e-mail.
By the way, are you running a release version of Flow (e.g., 2020.04) or did
you compile the master sources from GitHub yourself?
Best Regards,
Bård Skaflestad
SINTEF Digital, Mathematics & Cybernetics
Computational Geosciences group
-Original Message-
From: Opm On Behalf O
if that solves--or at least
alleviates--the problem?
Best Regards,
Bård Skaflestad
SINTEF Digital, Mathematics & Cybernetics
Computational Geosciences group
-Original Message-
From: Opm On Behalf Of Yogi Pandey
Sent: Thursday, March 12, 2020 6:14 PM
To: Joakim Hove ; opm
restrictions. In that case you
typically don't need the strict WELLDIMS parsing. Off the top of my head I
don't recall exactly how to turn it off, but the relevant keys are
RUNSPEC_*
Joakim Hove is the project's expert on how to tune those parser settings.
Regards,
Bård Skaflestad
SINTEF Digital
be sized
according to the maximum group size (number of child wells or child groups).
I hope this helps. In the short term we're not going to be able to change
this, so I suggest raising the fourth item of WELLDIMS in this model.
Regards,
Bård Skaflestad
SINTEF Digital, Mathematics & C
--Google Test might be an alternative--it is going to require some
work to rewrite the tests.
That said, raising the minimum C++ language version to C++17 will allow us to
replace most of our other usage of Boost; notably regular expressions and
Boost.Filesystem.
Regards,
Bård Skaflestad
ibecl" in master.
Thank you again to Torbjørn Skille and Arne Morten Kvarving for getting us to
this point.
To reiterate, I recommend a full rebuild of all modules to ensure you have a
consistent set of executable files.
Best Regards,
Bård Skaflestad
SINTEF Digital, Mathematics &am
this point, and especially
to Arne Morten Kvarving for the build system assistance.
Best Regards,
Bård Skaflestad
SINTEF Digital, Mathematics & Cybernetics
Computational Geosciences group
___
Opm mailing list
Opm@opm-project.org
https://opm-proje
Yay!
Thanks a lot Arne Morten. This is really greatly appreciated!
Bård
-Original Message-
From: Opm On Behalf Of Arne Morten Kvarving
Sent: Thursday, June 13, 2019 10:16 AM
To: opm@opm-project.org
Subject: [Opm] jenkins - reboot
Hi community,
as you probably have noticed, the
I'll echo the sentiments of the others.
Herculean efforts people!
Regards,
Bård
-Original Message-
From: Opm On Behalf Of Markus Blatt
Sent: Wednesday, May 8, 2019 11:18 AM
To: Arne Morten Kvarving
Cc: opm@opm-project.org
Subject: Re: [Opm] 2019.04 release plan
Hi,
Great! Thanks a
Just out of curiosity: If there are any builds running at that time, will they
be allowed to complete or terminated?
Bård
From: Opm [opm-boun...@opm-project.org] on behalf of Arne Morten Kvarving
[arne.morten.kvarv...@sintef.no]
Sent: 27 June 2016 14:59
is above some maximum threshold.
Sincerely,
--
Bård Skaflestad <bard.skafles...@sintef.no>
SINTEF ICT, Applied Mathematics
From: Opm [opm-boun...@opm-project.org] on behalf of David Ogbe
[do...@aust.edu.ng]
Sent: 15 June 2016 19:00
To: Atgeirr Rasmussen
Cc: O
is Dune 2.4 and do we have a
reasonable upgrade path to that?
Sincerely,
--
Bård Skaflestad bard.skafles...@sintef.no
SINTEF ICT, Applied Mathematics
___
Opm mailing list
Opm@opm-project.org
http://www.opm-project.org/mailman/listinfo/opm
On 09/06/15 01:04, Roland Kaufmann wrote:
On 8th June 2015 at 20:29, Bård Skaflestad wrote:
module opm-upscaling [...] has explicit bindings to Fortran libraries
(notably LAPACK and the BLAS).
The last time I checked Ninja did not support Fortran and was not
able to define a working
Complexity in the build system is certainly worth addressing.
That said, I don't understand what the ramifications of this change will be so
I'll ask some questions to help assess the situation. This will be from the
point of view of a developer.
Suppose that I'm using and making changes
Thanks a lot for those answers.
They mesh more or less perfectly with the gist of my initial assessment. I
will think about the implications a bit more before I make any further comments
except on one technical comment concerning sibling builds. Sibling build trees
do not need to be in a
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
On 2014-11-19 17:41, Jørgen Kvalsvik wrote:
On 2014-11-19 07:27, Alf Birger Rustad wrote:
Hello everybody,
I am guilty of creating yet another repository in opm. [...]
Honestly, I don't think it's that good an idea to have separate
repositories at all [...]
Noted.
3. Increased
On Mon, 2014-07-07 at 16:33 +0200, Andreas Lauser wrote:
it could be that boost::filesystem as it is used in our code does not
trigger the ABI incompatibility by coincidence...
That's certainly possible. I don't know.
as a work-around for newish (= GCC 4.9 ?) compilers, we could modify
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
On Mon, 2014-06-30 at 19:28 +0200, Andreas Lauser wrote:
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...
Like I said, fault transmissibilities
There is no such method in class GridManager.
However, if you just need an UnstructuredGrid that doesn't observe ACTNUM you
can accomplish the task manually by extracting the grid information through
Method GridManager::createGrdecl(), assign a null pointer to grdecl::actnum and
then form
On Fri, 2014-06-20 at 11:49 +0200, Andreas Lauser wrote:
[i]f MULTX- is not specified, do the values specified in MULTX also
apply for the negative direction?
No, they do not. If MULTX- is not explicitly defined in the input, the
format requires that MULTX- be implicitly assigned an all-ones
the 'well_example' as part of building opm-core
or as an independent executable?
Sincerely,
--
Bård Skaflestad bard.skafles...@sintef.no
SINTEF ICT, Applied Mathematics
___
Opm mailing list
Opm@opm-project.org
http://www.opm-project.org/mailman/listinfo/opm
On Wed, 2014-06-18 at 10:16 +, Joakim Hove wrote:
On the other hand, if 'MULTFLT' is used in *EDIT* (or, shudder,
*SCHEDULE*), then it modifies the trans values directly.
The SCHEDULE section I think is unrealistic to support initially;
Agreed.
as for the EDIT section my
On Tue, 2014-06-17 at 15:16 +, Joakim Hove wrote:
Following the closed PR: https://github.com/OPM/opm-parser/pull/241 I
have tried to read and understand how the MULT([XYZ])-? and
FAULTS/MULTFLT keywords interact.
Much appreciated. This is intricate material.
MULTX: This keyword is a
of twenty minutes per module). What
diagnostics, if any, do you get from CMake during configuration?
Best regards,
--
Bård Skaflestad
From: Opm [opm-boun...@opm-project.org] on behalf of Júlio Hoffimann
[julio.hoffim...@gmail.com]
Sent: 05 March 2014 15:31
,
--
Bård Skaflestad
From: Júlio Hoffimann [julio.hoffim...@gmail.com]
Sent: 05 March 2014 16:24
To: Bård Skaflestad
Cc: opm@opm-project.org
Subject: Re: [OPM] [opm-core] DUNE dependency
What diagnostics, if any, do you get from CMake during configuration
of any traces of previous build
attempts?
Bård
From: Júlio Hoffimann [julio.hoffim...@gmail.com]
Sent: 05 March 2014 18:59
To: Bård Skaflestad
Cc: opm@opm-project.org
Subject: Re: [OPM] [opm-core] DUNE dependency
Problem solved. Latest commit without opm
On Thu, Feb 27, 2014 at 03:01:32PM +0100, Andreas Lauser wrote:
[snip]
The choices in opm-core were made for reasons of convenience. Having normals
whose (Euclidian) norm equals the corresponding interface area means that the
formulae for (mimetic) inner products become simpler. See function
On Fri, 2013-11-15 at 16:06 +0100, Alf Birger Rustad wrote:
Fine, then I do not really care about version. Debian stable ships
with version 1.49 these days. If Joakim takes on setting up new boost
installations, then feel free to set 1.49 as minimum version as far as
I am concerned. Generally
39 matches
Mail list logo
