Dear Felix,<br><br>Thank you so much for your information. <br>I just updated to latest version of all dune modules and <br>the problem seems to be disappear now. <br>Once again thank you very much for great help and fast bug fix.<br>
<br>Best Regards<br>Nagaiah<br><br><div class="gmail_quote">On Mon, Jan 17, 2011 at 5:32 PM, Felix Heimann <span dir="ltr"><<a href="mailto:felix.heimann@iwr.uni-heidelberg.de">felix.heimann@iwr.uni-heidelberg.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Dear Nagaiah,<br>
<br>
I was just informed, that a significant Bug-fix concerning ghost<br>
elements was added in revision 795. If you are working with an older<br>
revision, you might want to update.<br>
<br>
Best Regards,<br>
Felix<br>
<br>
Am Montag, den 17.01.2011, 17:25 +0100 schrieb Felix Heimann:<br>
> Dear Nagaiah,<br>
><br>
> you are right. The grid operator space is supposed to set the correct<br>
> constraints for the ghost elements automatically. However, to my<br>
> knowledge, the parallel mechanisms were not thoroughly tested for<br>
> multi-component grid function spaces. Therefore, it is quite possible,<br>
> that there are still some bugs in the implementation, resulting in a<br>
> wrong identification of the constrained dofs. However, the<br>
> implementation of set_trivial_row() itself appears to be sound.<br>
><br>
> By the way, I just found a bug concerning the constraints. It is rather<br>
> specific to instationary applications using a istl vector backend of<br>
> block size > 1, but may be it is of interest to you.<br>
><br>
> I recommend to set up a simple small example problem and then to<br>
> manually check the constraints container which is passed to<br>
> set_trivial_row(). It should contain the flat indices of the ghost<br>
> elements and the Dirichlet elements. If this is not the case, then<br>
> please file a bug report at<br>
><br>
> <a href="http://users.dune-project.org/projects/dune-pdelab" target="_blank">http://users.dune-project.org/projects/dune-pdelab</a><br>
><br>
> and please follow the guidelines of bug reporting as given at<br>
><br>
> <a href="http://users.dune-project.org/projects/main-wiki/wiki/Guides_bug_reporting" target="_blank">http://users.dune-project.org/projects/main-wiki/wiki/Guides_bug_reporting</a><br>
><br>
> Best Regards,<br>
> Felix<br>
><br>
><br>
> Am Freitag, den 14.01.2011, 23:11 +0100 schrieb Nagaiah Chamakuri:<br>
> > Dear Felix Heimann,<br>
> > Thank you for your response. I am sorry to say that I did not give<br>
> > complete details.<br>
> > you are right. I am referring vector valued solution which can be<br>
> > represented by PowerGridFunctionSpace in PDELab.<br>
> > I know only that we can set physical boundary conditions (Neumann or<br>
> > Dirichlet BC's)<br>
> > using Dune::PDELab::constriants() function. I do not know that we can<br>
> > impose<br>
> > constraints (artificial BC) for ghost elements as well. Also, I am not<br>
> > sure how to set the constraints<br>
> > for ghost elements in this constraints() function.<br>
> ><br>
> > Is it a good idea to set artificial boundary conditions for ghost<br>
> > elements<br>
> > in non overlapping grids case using Dune::PDELab::constraints(..)?<br>
> > I would expect that these atrificial boundary conditions should be<br>
> > automatically taken care by<br>
> > gridoperator function routines. am I stupid here or did not understand<br>
> > parallel pdelab routines properly?<br>
> ><br>
> > Thank you in advance.<br>
> ><br>
> > Best Regards<br>
> > Nagaiah<br>
> ><br>
> ><br>
> ><br>
> > On Fri, Jan 14, 2011 at 4:46 PM, Felix Heimann<br>
> > <<a href="mailto:felix.heimann@iwr.uni-heidelberg.de">felix.heimann@iwr.uni-heidelberg.de</a>> wrote:<br>
> > Dear Nagaiah,<br>
> ><br>
> > I am not sure, what exactly you mean by "more than one<br>
> > solution<br>
> > component". If you refer to e.g. a vector valued solution,<br>
> > then this<br>
> > should be represented by e.g. a PowerGridFunctionSpace. In<br>
> > such a case,<br>
> > the set_trivial_row() function will work correctly as long as<br>
> > the<br>
> > indices in the constraints container are consistent to the<br>
> > indices of<br>
> > the grid function space (this should be guaranteed if you set<br>
> > up the<br>
> > container with the Dune::PDELab::constraints(..) function).<br>
> ><br>
> > However, this functionality is the same for all trivially<br>
> > constrained<br>
> > dofs, independent of whether they result from a ghost cell in<br>
> > a domain<br>
> > decomposed non-overlapping application or a Dirichlet boundary<br>
> > in a<br>
> > standard application. Hence, I do not see the connection to<br>
> > the specific<br>
> > grid i.e. application and may not have grasped your problem.<br>
> > May be you<br>
> > can clarify...<br>
> ><br>
> > Best Regards,<br>
> > Felix Heimann<br>
> ><br>
> ><br>
> ><br>
> > Am Mittwoch, den 12.01.2011, 22:57 +0100 schrieb Nagaiah<br>
> > Chamakuri:<br>
> ><br>
> > > Dear dune-pdelab,<br>
> > ><br>
> > > I have a question about "set_trivial_row" function in<br>
> > > new_gridoperatorspace.hh at line 885 (precisely I am using<br>
> > Jacobian<br>
> > > function routine to construct matrices) and defined in<br>
> > > gridoperatorspaceutilities.hh at line 971.<br>
> > > Mainly I am using non overlapping grid (UG grid) and<br>
> > diagonal elements<br>
> > > of the ghost nodes are set to zero in the global matrix<br>
> > > in case of more than one solution component presents.<br>
> > > This function routine works well in case of one solution<br>
> > component<br>
> > > presents in the problem.<br>
> > ><br>
> > ><br>
> > > right answer should look like as follows (up to my<br>
> > knowledge):<br>
> > ><br>
> > > for j=1 to no.of.comp<br>
> > > B::clear_row(i+j,globalcontainer)<br>
> > ><br>
> > > B::access(globalcontainer,i+j,i+j) = 1,<br>
> > ><br>
> > ><br>
> > ><br>
> > > Is it right? or didn't I understand correctly?<br>
> > ><br>
> > > Thanks & Regards<br>
> > > Nagaiah<br>
> ><br>
> > > _______________________________________________<br>
> > > dune-pdelab mailing list<br>
> > > <a href="mailto:dune-pdelab@dune-project.org">dune-pdelab@dune-project.org</a><br>
> > > <a href="http://lists.dune-project.org/mailman/listinfo/dune-pdelab" target="_blank">http://lists.dune-project.org/mailman/listinfo/dune-pdelab</a><br>
> ><br>
> > --<br>
> > Felix Heimann<br>
> > Universität Heidelberg<br>
> > Interdisziplinäres Zentrum für Wissenschaftliches Rechnen<br>
> > Arbeitsgruppe Paralleles Rechnen<br>
> > IWR 368, Raum 422<br>
> > Tel: 06221 / 54 8881<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > dune-pdelab mailing list<br>
> > <a href="mailto:dune-pdelab@dune-project.org">dune-pdelab@dune-project.org</a><br>
> > <a href="http://lists.dune-project.org/mailman/listinfo/dune-pdelab" target="_blank">http://lists.dune-project.org/mailman/listinfo/dune-pdelab</a><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Dr. Chamakuri Nagaiah<br>
> > Institute of Mathematics and Scientific Computing<br>
> > Heinrichstrasse-36, University of Graz,<br>
> > A-8010, Graz, Austria. Ph(office) : (0043) 316 380 5063<br>
> ><br>
> > _______________________________________________<br>
> > dune-pdelab mailing list<br>
> > <a href="mailto:dune-pdelab@dune-project.org">dune-pdelab@dune-project.org</a><br>
> > <a href="http://lists.dune-project.org/mailman/listinfo/dune-pdelab" target="_blank">http://lists.dune-project.org/mailman/listinfo/dune-pdelab</a><br>
><br>
<font color="#888888"><br>
--<br>
Felix Heimann<br>
Universität Heidelberg<br>
Interdisziplinäres Zentrum für Wissenschaftliches Rechnen<br>
Arbeitsgruppe Paralleles Rechnen<br>
IWR 368, Raum 422<br>
Tel: 06221 / 54 8881<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Dr. Chamakuri Nagaiah<br>Institute of Mathematics and Scientific Computing<br>Heinrichstrasse-36, University of Graz,<br>A-8010, Graz, Austria. Ph(office) : (0043) 316 380 5063<br>
<br>