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

Nagaiah Chamakuri nagaiah.chamakuri at gmail.com
Tue Jan 18 09:40:57 CET 2011


Dear Felix,

Thank you so much for your information.
I just updated to latest version of all dune modules and
the problem seems to be disappear now.
Once again thank you very much for great help and fast bug fix.

Best Regards
Nagaiah

On Mon, Jan 17, 2011 at 5:32 PM, Felix Heimann <
felix.heimann at iwr.uni-heidelberg.de> wrote:

> Dear Nagaiah,
>
> I was just informed, that a significant Bug-fix concerning ghost
> elements was added in revision 795. If you are working with an older
> revision, you might want to update.
>
> Best Regards,
> Felix
>
> Am Montag, den 17.01.2011, 17:25 +0100 schrieb 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
>
>


-- 
Dr. Chamakuri Nagaiah
Institute of Mathematics and Scientific Computing
Heinrichstrasse-36, University of Graz,
A-8010, Graz, Austria. Ph(office) : (0043) 316 380 5063
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-pdelab/attachments/20110118/8efccbb3/attachment.htm>


More information about the dune-pdelab mailing list