PreconditionBlockJacobi

[Astor Piaz]

Hello All,

I'm using deal.ii version 8.5.0-pre and I'm setting up a block Jacobi preconditioner as the smoother of a geometric multigrid preconditioner in the following way:

dealii::Triangulation<dim> triangulation ;
dealii::DoFHandler<dim> dof_handler ;

dealii::MGSmootherPrecondition<dealii::SparseMatrix<double>,
                               dealii::PreconditionBlockJacobi<dealii::SparseMatrix<double> >,
                               dealii::Vector<double> > mg_smoother;

dealii::MGLevelObject<dealii::SparseMatrix<double> > mg_matrix ;

 ...

typename dealii::PreconditionBlockJacobi<dealii::SparseMatrix<double> >::AdditionalData

   smoother_data(dof_handler.block_info().local().block_size(0));

mg_smoother.initialize(mg_matrix, smoother_data);

GCC (v4.9.2) complains about 'class dealii::PreconditionBlock<...>::AdditionalData' being inaccessible, which it actually is, as 'class dealii::PreconditionBlockJacobi<...>' is privately derived from 'class dealii::PreconditionBlock<...>'.

Making 'class dealii::PreconditionBlockJacobi<...>' a publicly derived class of 'class dealii::PreconditionBlock<...>' is the workaround I'm using.

I wonder then:

What is the intended way to initialize a 'dealii::MGSmootherPrecondition<...,dealii::PreconditionBlockJacobi<...>,...>' object using 'dealii::MGLevelObject<dealii::SparseMatrix<double> >' and 'class dealii::PreconditionBlock<...>::AdditionalData' objects?

Best,
--

Astor

[Astor Piaz]

Inserting

public: using typename PreconditionBlock<MatrixType,inverse_type>::AdditionalData;

in the declaration of 'class dealii::PreconditionBlockJacobi<...>' being maybe a more elegant workaround.

But still a workaround...?

Best,

--

Astor

[Wolfgang Bangerth]

On 02/27/2016 12:31 PM, Astor Piaz wrote:
>
> What is the intended way to initialize a
> 'dealii::MGSmootherPrecondition<...,dealii::PreconditionBlockJacobi<...>,...>'
> object using'dealii::MGLevelObject<dealii::SparseMatrix<double> >' and 'class
> dealii::PreconditionBlock<...>::AdditionalData' objects?

The way you do it, but for that an AdditionalData member needs to be
accessible. Both of your workarounds work just fine in this regard.

You get in trouble because you use private inheritance, which is frequently a
mistake. Inheritance is used to indicate an "is a" relationship, in which case
it makes sense to derive publicly. Why do you want to derive privately?

Best
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@math.tamu.edu
www: http://www.math.tamu.edu/~bangerth/

[Astor Piaz]

Hello Wolfgang and many thanks for your answer,

I can only agree with you but the inheritance architecture is not my own design, it is deal.ii's design.

I don't want to derive publicly, nor I want to derive privately, I am only exploring the present architecture and I wonder what is the intended way to make use of it.

Should I understand from your answer that the present architecture is somewhat incorrect and all private inheritances in <deal.II/lac/precondition_block.h> must be public?

Thanks again.

Best,
--

Astor

Best
 W.

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
--- You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dealii+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Guido Kanschat]

Dear Astor,

thanks for pointing this out. The private inheritance is indeed deliberate, in spite of Wolfgang's comment, since the base class provides te implementation, but not the interface. Your second workaround, namely redeclaring AdditionalData public in the derived class, is the correct way of handling this. Do you want to check how this is handled in the other derivatives of PreconditionBlock and submit a pull request?

Best,

Guido

--

Prof. Dr. Guido Kanschat
Interdisziplinäres Zentrum für Wissenschaftliches Rechnen
Universität Heidelberg
Im Neuenheimer Feld 368, 69120 Heidelberg

[Astor Piaz]

Dear Guido,

Understood. Pull request done. Problem solved. Thank you.

Best,

--

Astor