Skip to content
Snippets Groups Projects
Commit 1741ca28 authored by Ansgar Burchardt's avatar Ansgar Burchardt
Browse files

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

parent 724aaeaf
Branches
No related tags found
No related merge requests found
Pipeline #
......@@ -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
......@@ -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
......@@ -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
// -*- 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
......@@ -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;
  • Contributor

    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 @burchardt_at_igpm.rwth-aachen.de ·
    Author Maintainer

    @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.

  • Contributor

    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.

  • Owner

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

  • Ansgar Burchardt @burchardt_at_igpm.rwth-aachen.de ·
    Author Maintainer

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

  • Contributor

    @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.

    Edited by pipping
  • Contributor

    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)
    Edited by pipping
  • Owner

    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.

  • Please register or sign in to reply
#endif
  • Owner

    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.

  • Owner

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

  • Ansgar Burchardt @burchardt_at_igpm.rwth-aachen.de ·
    Author Maintainer

    @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 @maxka

    mentioned in commit 16fdcb27

    ·

    mentioned in commit 16fdcb27

    Toggle commit list
  • maxka @maxka

    mentioned in commit 166fa881

    ·

    mentioned in commit 166fa881

    Toggle commit list
  • Owner

    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).

    Edited by maxka
  • Developer

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

0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment