[dune-pdelab] bug/problem in set_trivial_row function routine(dune-pdelab)

[Felix Heimann]

Dear Nagaiah,

you are right. The grid operator space is supposed to set the correct
constraints for the ghost elements automatically. However, to my
knowledge, the parallel mechanisms were not thoroughly tested for
multi-component grid function spaces. Therefore, it is quite possible,
that there are still some bugs in the implementation, resulting in a
wrong identification of the constrained dofs. However, the
implementation of set_trivial_row() itself appears to be sound.

By the way, I just found a bug concerning the constraints. It is rather
specific to instationary applications using a istl vector backend of
block size > 1, but may be it is of interest to you.

I recommend to set up a simple small example problem and then to
manually check the constraints container which is passed to
set_trivial_row(). It should contain the flat indices of the ghost
elements and the Dirichlet elements. If this is not the case, then
please file a bug report at

http://users.dune-project.org/projects/dune-pdelab

and please follow the guidelines of bug reporting as given at

http://users.dune-project.org/projects/main-wiki/wiki/Guides_bug_reporting

Best Regards,
Felix


Am Freitag, den 14.01.2011, 23:11 +0100 schrieb Nagaiah Chamakuri:
> Dear Felix Heimann,
> Thank you for your response. I am sorry to say that I did not give
> complete details.
> you are right. I am referring vector valued solution which can be
> represented by PowerGridFunctionSpace in PDELab.
> I know only that we can set physical boundary conditions (Neumann or
> Dirichlet BC's)
> using Dune::PDELab::constriants() function. I do not know that we can
> impose 
> constraints (artificial BC) for ghost elements as well. Also, I am not
> sure how to set the constraints 
> for ghost elements in this constraints() function. 
> 
> Is it a good idea to set artificial boundary conditions for ghost
> elements 
> in non overlapping grids case using Dune::PDELab::constraints(..)?
> I would expect that these atrificial boundary conditions should be
> automatically taken care by
> gridoperator function routines. am I stupid here or did not understand
> parallel pdelab routines properly?
> 
> Thank you in advance.
> 
> Best Regards
> Nagaiah
> 
> 
> 
> On Fri, Jan 14, 2011 at 4:46 PM, Felix Heimann
> <felix.heimann at iwr.uni-heidelberg.de> wrote:
>         Dear Nagaiah,
>         
>         I am not sure, what exactly you mean by "more than one
>         solution
>         component". If you refer to e.g. a vector valued solution,
>         then this
>         should be represented by e.g. a PowerGridFunctionSpace. In
>         such a case,
>         the set_trivial_row() function will work correctly as long as
>         the
>         indices in the constraints container are consistent to the
>         indices of
>         the grid function space (this should be guaranteed if you set
>         up the
>         container with the Dune::PDELab::constraints(..) function).
>         
>         However, this functionality is the same for all trivially
>         constrained
>         dofs, independent of whether they result from a ghost cell in
>         a domain
>         decomposed non-overlapping application or a Dirichlet boundary
>         in a
>         standard application. Hence, I do not see the connection to
>         the specific
>         grid i.e. application and may not have grasped your problem.
>         May be you
>         can clarify...
>         
>         Best Regards,
>         Felix Heimann
>         
>         
>         
>         Am Mittwoch, den 12.01.2011, 22:57 +0100 schrieb Nagaiah
>         Chamakuri:
>         
>         > Dear dune-pdelab,
>         >
>         > I have a question about "set_trivial_row" function in
>         > new_gridoperatorspace.hh at line 885  (precisely I am using
>         Jacobian
>         > function routine to construct matrices) and defined in
>         > gridoperatorspaceutilities.hh at line 971.
>         > Mainly I am using non overlapping grid (UG grid) and
>         diagonal elements
>         > of the ghost nodes are set to zero in the global matrix
>         > in case of more than one solution component presents.
>         > This function routine works well in case of one solution
>         component
>         > presents in the problem.
>         >
>         >
>         > right answer should look like as follows (up to my
>         knowledge):
>         >
>         > for j=1 to no.of.comp
>         > B::clear_row(i+j,globalcontainer)
>         >
>         > B::access(globalcontainer,i+j,i+j) = 1,
>         >
>         >
>         >
>         > Is it right? or  didn't I understand correctly?
>         >
>         > Thanks & Regards
>         > Nagaiah
>         
>         > _______________________________________________
>         > dune-pdelab mailing list
>         > dune-pdelab at dune-project.org
>         > http://lists.dune-project.org/mailman/listinfo/dune-pdelab
>         
>         --
>         Felix Heimann
>         Universität Heidelberg
>         Interdisziplinäres Zentrum für Wissenschaftliches Rechnen
>         Arbeitsgruppe Paralleles Rechnen
>         IWR 368, Raum 422
>         Tel: 06221 / 54 8881
>         
>         
>         _______________________________________________
>         dune-pdelab mailing list
>         dune-pdelab at dune-project.org
>         http://lists.dune-project.org/mailman/listinfo/dune-pdelab
> 
> 
> 
> -- 
> Dr. Chamakuri Nagaiah
> Institute of Mathematics and Scientific Computing
> Heinrichstrasse-36, University of Graz,
> A-8010, Graz, Austria. Ph(office) : (0043) 316 380 5063
> 
> _______________________________________________
> dune-pdelab mailing list
> dune-pdelab at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-pdelab

-- 
Felix Heimann
Universität Heidelberg
Interdisziplinäres Zentrum für Wissenschaftliches Rechnen
Arbeitsgruppe Paralleles Rechnen
IWR 368, Raum 422
Tel: 06221 / 54 8881