[dune-pdelab] localfunctionspace.hh -> globalIndex

[Christian Engwer]

Dear Christian,

I checked the dune-parsolve module. I assume you are refereing to
dune-parsolve/uebungen/uebung07/geometric_multigrid_components.hh 

The important fact is:
* pdelab has felxible infrastructure to support different LA
  implementations
* you are hard-coding to a flat BCRSMatrix.

I think you will have to rewrite significant parts of this particular
header file. In general I would suggest a different approach... write
a custom assembler, which uses the usual backand interfaces to store
your data in the BCRSMatrix.

If you want to stick to your current implementation you will have to
mimic the appropriate backend infrastructure. The problem in this case
is that you have to pray that the spaces and backends fit to your
assumed structure.

Ciao
Christian


On Tue, Sep 02, 2014 at 11:19:17AM +0200, Christian Kaltenecker wrote:
> 
> Dear Dune,
> 
> I am sorry for my last E-Mail, where a lot of information was missing.
> 
> My problem is the missing globalIndex - method in the localfunctionspace.
> 
> The code is as follows(this is another part of the code, where the
> globalIndex-method was used than in the last E-Mail):
> 
>   typedef std::set<size_type> IndexSet;
>   typedef std::vector<IndexSet> Graph;
> (...)
>     // gfs and matrix graph
>     const GFS& gfsf = gfsh_.getGFS(level);  // fine gfs
>     const GFS& gfsc = gfsh_.getGFS(level-1);// coarse gfs
>     Graph graph(gfsf.globalSize());                        // matrix graph
> 
>     // make local function spaces
>     typedef Dune::PDELab::LocalFunctionSpace<GFS> LFS;
>     LFS lfsf(gfsf);
>     LFS lfsc(gfsc);
> (...)
>     // interpolation weights are values of coarse grid basis
> functions at fine grid points
>     for (typename LFS::Traits::SizeType i=0; i<lfsf.size(); i++)
>       {
>         typedef typename LFS::Traits::FiniteElementType::
>           Traits::LocalBasisType::Traits::RangeType RangeType;
>         std::vector<RangeType> phi(lfsc.size());
> lfsc.finiteElement().localBasis().evaluateFunction(local_position_in_father[i],phi);
>         for (typename LFS::Traits::SizeType j=0; j<lfsc.size(); j++)
>           {
>         if (phi[j]>1E-6)
>           graph[lfsf.globalIndex(i)].insert(lfsc.globalIndex(j));
>           }
>       }
> 
> This is the original code. Because of the globalIndex(i) a compiler
> error occurs.
> I have tried a few days ago to fix that. The compiler error was
> fixed by replacing:
> graph[lfsf.globalIndex(i)].insert(lfsc.globalIndex(j));
> with
> for (typename LFS::Traits::SizeType k=0;
> k<lfsf.dofIndex(i).entityIndex().size(); k++) {
> graph[lfsf.dofIndex(i).entityIndex()[k]].insert(lfsf.dofIndex(i).entityIndex()[k]);
> }
> but I think that this is not the right solution at all, is it?
> 
> I have also searched for the LFSIndexCache you have mentioned
> regarding the multi index, but don't know how I should use that.
> 
> Thank you for your help so far!
> 
> Regards,
> Christian Kaltenecker
> 
> Am 01.09.2014 um 09:52 schrieb Christian Kaltenecker:
> >Dear Dune,
> >
> >I am trying to port the program dune-parsolve from the lecture
> >"Parallele Lösung großer Gleichungssysteme" in order to run the
> >program with the DUNE 2.3.1 modules.
> >
> >The code is as follows:
> >    // interpolation weights are values of coarse grid basis
> >functions at fine grid points
> >    for (typename LFS::Traits::SizeType i=0; i<lfsf.size(); i++)
> >      {
> >        typedef typename LFS::Traits::FiniteElementType::
> >          Traits::LocalBasisType::Traits::RangeType RangeType;
> >        std::vector<RangeType> phi(lfsc.size());
> >lfsc.finiteElement().localBasis().evaluateFunction(local_position_in_father[i],phi);
> >
> >        for (typename LFS::Traits::SizeType j=0; j<lfsc.size(); j++)
> >          if (phi[j]>1E-6)
> >            (*this)[lfsf.globalIndex(i)][lfsc.globalIndex(j)] = phi[j];
> >      }
> >
> >----------------------------------
> >
> >Any other compiler error is fixed so far, so this one is the last
> >one I have to fix.
> >
> >What would you recommend to do in this case?
> >
> >I can also send the whole file containing the code above.
> >
> >Thanks in advance!
> >
> >Regards,
> >Christian Kaltenecker
> >
> >Am 29.08.2014 um 15:05 schrieb Christian Engwer:
> >>Dear Christian,
> >>
> >>On Fri, Aug 29, 2014 at 02:32:46PM +0200, Christian Kaltenecker wrote:
> >>>Hello Dune,
> >>>
> >>>Thanks for your help regarding my last E-Mail. It was very helpful.
> >>>
> >>>Now my next and last problem is concerning the removed globalIndex.
> >>>In Dune version 2.2 the globalIndex of the localfunctionspace was
> >>>accessed this way:
> >>>lfsf.globalIndex(i)
> >>>but now in the version 2.3.1 the globalIndex-method is missing.
> >>>I guess that it has something to do with the class DOFIndexContainer.
> >>>
> >>>Is there a way to get something like the global index?
> >>usually it should not be necessary to do so... it would help us to
> >>learn more about your particular use-case.
> >>
> >>The general idea is that we introduce different types of mappings:
> >>
> >>DOF -> multi index (this is what you get from the function space)
> >>     the multi index is a hierarchic index, which store things like
> >>     entity type, entity index, position in the function-space
> >>     tree. This hierarchy does not necessarily comply to the the
> >>     hierarchy induced by your GFS tree structure, but you can reorder
> >>     it using the ordering tags.
> >>
> >>The second component is a mapping
> >>
> >>multi index -> container index
> >>     this is computed by the ordering and is accessible via the
> >>     lfsindexcache. This class maps from the generic multi index to a
> >>     (multi) index type which is suitable for your particular container
> >>     backend. If you are using a flat container, this is only a
> >>     number. If you are using a blockmatrix this is really a
> >>     multi-index.
> >>
> >>I hope this helps already. For anything else, please explain a little
> >>bit more about what you need. Usually you should not have to access
> >>this information yourself.
> >>
> >>Ciao
> >>Christian
> >>
> >
> >
> >_______________________________________________
> >dune-pdelab mailing list
> >dune-pdelab at dune-project.org
> >http://lists.dune-project.org/mailman/listinfo/dune-pdelab
> 
> 

-- 
Prof. Dr. Christian Engwer 
Institut für Numerische und Angewandte Mathematik
Fachbereich Mathematik und Informatik der Universität Münster
Einsteinstrasse 62
48149 Münster

E-Mail	christian.engwer at uni-muenster.de
Telefon	+49 251 83-35067
FAX		+49 251 83-32729