move a few more classes into the Dune::Solvers namespace

dune/solvers/common/numproc.hh

@@ -5,6 +5,9 @@
 
 #include <dune/common/exceptions.hh>
 
+namespace Dune {
+namespace Solvers {
+
 /** \brief Exception thrown by solvers */
 class SolverError : public Dune::Exception {};
 
@@ -48,6 +51,11 @@ class SolverError : public Dune::Exception {};
         return lhs;
     }
 
+} /* namespace Solvers */
+} /* namespace Dune */
 
+// For backward compatibility: will be removed eventually
+using Dune::Solvers::SolverError;
+using Dune::Solvers::NumProc;
 
 #endif

dune/solvers/iterationsteps/amgstep.hh

@@ -12,6 +12,9 @@
 #include <dune/solvers/iterationsteps/lineariterationstep.hh>
 #include <dune/istl/paamg/amg.hh>
 
+namespace Dune {
+namespace Solvers {
+
 /** \brief A wrapper class for the ISTL AMG implementation
  */
 template <class MatrixType, class VectorType>
@@ -106,4 +109,10 @@ void AMGStep<MatrixType,VectorType>::iterate()
     amg_->apply(*this->x_, residual_);
 }
 
+} /* namespace Solvers */
+} /* namespace Dune */
+
+// For backward compatibility: will be removed eventually
+using Dune::Solvers::AMGStep;
+
 #endif

dune/solvers/norms/energynorm.hh

@@ -10,6 +10,9 @@
 #include <dune/solvers/norms/norm.hh>
 #include <dune/solvers/iterationsteps/lineariterationstep.hh>
 
+namespace Dune {
+namespace Solvers {
+
     /** \brief Vector norm induced by linear operator
      *
      *  \f$\Vert u \Vert_A = (u, Au)^{1/2}\f$
@@ -119,4 +122,10 @@
 
     };
 
+} /* namespace Solvers */
+} /* namespace Dune */
+
+// For backward compatibility: will be removed eventually
+using Dune::Solvers::EnergyNorm;
+
 #endif

dune/solvers/norms/norm.hh

 // -*- tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 4 -*-
 // vi: set et ts=8 sw=4 sts=4:
-#ifndef NORM_HH
-#define NORM_HH
+#ifndef DUNE_SOLVERS_NORMS_NORM_HH
+#define DUNE_SOLVERS_NORMS_NORM_HH
+
+namespace Dune {
+namespace Solvers {
 
 //! Abstract base for classes computing norms of discrete functions
 template <class V>
@@ -30,4 +33,10 @@ class Norm {
 
 };
 
+} /* namespace Solvers */
+} /* namespace Dune */
+
+// For backward compatibility: will be removed eventually
+using Dune::Solvers::Norm;
+
 #endif

dune/solvers/solvers/solver.hh

@@ -5,6 +5,9 @@
 
 #include <dune/solvers/common/numproc.hh>
 
+namespace Dune {
+namespace Solvers {
+
 /**  \brief struct to store result related information such as for example number of iterations etc.
   *
   *  \warning The interface and implementation is so far highly experimental and will change without further notice!
@@ -67,4 +70,12 @@ class Solver : public NumProc
     private:
         SolverResult result;
 };
+
+} /* namespace Solvers */
+} /* namespace Dune */
+
+// For backward compatibility: will be removed eventually
+using Dune::Solvers::Solver;
+using Dune::Solvers::SolverResult;
+
 #endif

[pipping]

While I welcome 99% of this change, I’m not sure if SolverResult should be part of the new namespace - it’s exactly the kind of thing one would hope to be able to leave behind this way, I think.

[Ansgar Burchardt]

@pipping: I think deprecating stuff is orthogonal to moving stuff into a new namespace.

At the time the using Dune::Solvers::... compatability bit gets removed, one should probably sort out deprecated objects to avoid unnecessary work.

[pipping]

I think in the agnumpde modules deprecatation warnings are not used quite as often as in the core modules because it’s easier to determine if anyone’s actually using something (and we don’t pretend to be quite as stable).

But again my understanding was that the new namespace was supposed to be a chance to start from a cleaner interface again, too. This might be worth discussing with a larger audience.

[maxka]

I second Elias' proposal to not move anything unpleasant to the Dune::Solvers namespace in the first place.

[Ansgar Burchardt]

@maxka: Do we have a list of "anything unpleasant"?

[pipping]

@burchardt_at_igpm.rwth-aachen.de Although this does not answer your question: dune/solvers/common/preconditioner.hh seems related to the discussion. here, we have an old interface and a new one; the new one is in the namespace while the old one is not and in fact, since they have the same name, the old one couldn't even be made available there (under that name).

Edit: Okay, the different template parameter signatures should make it okay; either way, it illustrates something somehow I think.

[pipping]

Some classes that are unpleasant, I think, are:

• BlockGSStep, TruncatedBlockGSStep (which are already deprecated)
• StaticMatrix, GenericVector (which I think should be moved entirely to dune-matrix-vector if they're actually still necessary)

[maxka]

But again my understanding was that the new namespace was supposed to be a chance to start from a cleaner interface again, too. This might be worth discussing with a larger audience.

This is what I feel like as well. I think that the comment

\warning The interface and implementation is so far highly experimental and will change without further notice!

hints that SolverResult might be something to be reconsidered for a cleaner interface. Actually, I would prefer the entire numproc.hh and solver.hh not to be in the new namespace for now.

With CriterionIterationSolver there already was some kind of proposal how to tackle the issues around these classes (and the LoopSolver), but maybe it held too many changes at the same time to be well-received.

[graeser]

For me "anything unpleasant" e.g. means any class with public member variables. Theses are very prone for user errors and a real pain to maintain. I strongly support to only move stuff that has been cleaned up and carefully reviewed to the namespace.

[maxka]

@burchardt_at_igpm.rwth-aachen.de Would you mind if I partially reverted your commit for the discussed reason?

[Ansgar Burchardt]

@maxka: No, I think SolverResult, numproc.hh and solver.hh are only things I use indirectly. So I don't mind where they are.

[maxka]

AMGStep exhibits the public member variables SmootherArgs and Criterion and therefore falls into @graeser 's unwanted list. @burchardt_at_igpm.rwth-aachen.de how do you feel about reverting this as well?

The protected members in EnergyNorm seem to be fine (to me).

[akbib]

Or how about we make these members private and add setters and getters?