Excellent job, @santiago.ospina! Thanks a lot
When migrating the repository to the DUNE GitLab (#211), it might suffice to just expose the documentation from the CI job artifacts and/or upload the latest one to a suitable repository. There is no active development, so it's unlikely to change in the near future.
We will migrate DORiE to the DUNE GitLab instance at https://gitlab.dune-project.org/. It does support most of our CI pipeline jobs. The DUNE GitLab also offers Docker-in-Docker executors we would need to automatically build the environment image and deploy DORiE. But these jobs are not strictly necessary, especially since there is no active development.
Lukas Riedel (fe8e7ebf) at 17 Feb 15:26
Lukas Riedel (3c261c4a) at 30 Nov 14:07
Update genetic optimization algorithm
... and 8 more commits
Lukas Riedel (30cf041b) at 22 Nov 18:19
So, how do we proceed? Virtual inheritance would be a structurally elegant way to combine the two definitions, but it seems to me that it complicates the definition of the exception, as its constructor gets comparably verbose.
Thank you!
Lukas Riedel (5d1c8972) at 28 Oct 15:12
See !573 (merged)
This MR backports the changes from !525 into the releases/2.7
branch.
I currently update our software DORiE to PDELab v2.7 (I'm late, I know). In our code, we regularly update the allowed maximum iterations of the Newton solver. This is why I proposed !525 in the first place. While theses changes mostly make modifying the allowed iterations more comfortable, they also remove an unconditional output to cout
. The only way of stopping this output would be some weird fiddling with the output stream.
DORiE output usually (and with this MR applied):
[11:23:24.247 I] Starting DORiE
[11:23:24.247 I] Reading configuration file: /builds/dorie/dorie/build-cmake/test/ref_muphi.ini
[11:23:24.247 I] Creating a rectangular grid in 2D
[11:23:24.248 I] Opening H5 file: /builds/dorie/dorie/test/maps/muphi.h5
[11:23:24.250 I] Reading H5 dataset: field
[11:23:24.255 I] [RIC] Loading parameter data file: /builds/dorie/dorie/test/param/richards_param.yml
[11:23:24.256 I] [RIC] Loading boundary condition data file: /builds/dorie/dorie/test/bcs/infiltration.yml
[11:23:24.261 I] [RIC] Setup complete
[11:23:25.575 I] [RIC] Time Step 0: 0.00e+00 + 1.00e+01 -> 1.00e+01
[11:23:26.906 I] [RIC] Time Step 1: 1.00e+01 + 1.50e+01 -> 2.50e+01
[11:23:28.253 I] [RIC] Time Step 2: 2.50e+01 + 2.25e+01 -> 4.75e+01
[11:23:29.650 I] [RIC] Time Step 3: 4.75e+01 + 3.38e+01 -> 8.12e+01
[11:23:31.097 I] [RIC] Time Step 4: 8.12e+01 + 5.06e+01 -> 1.32e+02
The DORiE output with current releases/2.7
is cluttered with the maxIteration
output:
[11:23:24.247 I] Starting DORiE
[11:23:24.247 I] Reading configuration file: /builds/dorie/dorie/build-cmake/test/ref_muphi.ini
[11:23:24.247 I] Creating a rectangular grid in 2D
[11:23:24.248 I] Opening H5 file: /builds/dorie/dorie/test/maps/muphi.h5
[11:23:24.250 I] Reading H5 dataset: field
[11:23:24.255 I] [RIC] Loading parameter data file: /builds/dorie/dorie/test/param/richards_param.yml
[11:23:24.256 I] [RIC] Loading boundary condition data file: /builds/dorie/dorie/test/bcs/infiltration.yml
40
[11:23:24.261 I] [RIC] Setup complete
9
[11:23:25.575 I] [RIC] Time Step 0: 0.00e+00 + 1.00e+01 -> 1.00e+01
9
[11:23:26.906 I] [RIC] Time Step 1: 1.00e+01 + 1.50e+01 -> 2.50e+01
8
[11:23:28.253 I] [RIC] Time Step 2: 2.50e+01 + 2.25e+01 -> 4.75e+01
8
[11:23:29.650 I] [RIC] Time Step 3: 4.75e+01 + 3.38e+01 -> 8.12e+01
7
[11:23:31.097 I] [RIC] Time Step 4: 8.12e+01 + 5.06e+01 -> 1.32e+02
7
Closes #167
See merge request !525
(cherry picked from commit 98fc0ca8)
Lukas Riedel (5d1c8972) at 28 Oct 14:44
Merge branch '167-newtonmethod-should-support-in-place-parameter-ch...
... and 27 more commits
The usual thing to backport is indeed to cherry-pick the merge commit, but GitLab can handle this. I'll give it a try.
It's alright
@rhess you want to have LineSearchError
and TerminateError
defined in linesearch.hh
and terminate.hh
, respectively. I can do that. But note that this still requires the include of newtonerrors.hh
because otherwise NewtonError
is not defined. Should I still implement your proposal?
I guess during rewriting the idea was to make the classes independent of Newton since you could also use them in other contexts (eg line search in other optimization algorithms).
This makes sense, but so far not the interfaces but only the derived classes throw these errors. And although the derived classes are templates, they assume the interface of the (Newton) solver. This means that terminate/line search algorithms for other uses probably need new derived class implementations, which could use their own exception types.
Would it be possible to merge this also into the releases/2.7
branch?
@rhess (not sure if that's your responsibility, so feel free to mention somebody else)
Well, one has to decide whether reaching the maximum iteration count without converging or a failure of the line search method is considered an error or a regular function of the objects. In my perception, E.2 and E.3 from the CppCoreGuidelines apply here. I think exceptions are the correct thing here because the functions cannot perform their assigned tasks and need to communicate this as an error.
Fix several issues arising from new Python versions and package updates:
base64.decodestring()
was previously deprecated and recently removed in favor of decodebytes()
.loader
argument when loading.numpy.dtype
only understands lowercase type strings now.No.
CHANGELOG.md
Assignee: If the Squash option is set, check/update the commit message right before merging!
No issue raised yet.
This fixes the issue that pipelines are not run for branches with a single commit.