Yes, that is completely true. Information exchange is one of the main aspects that plagues the domain decomposition methods. But probably this is improved by the optimized Schwarz which introduces artificial boundary conditions to enhance the information exchange. I am not sure how this scales for a lot of processes. It might very well be that you would need a coarse grid preconditioner to improve the global information exchange. I think this could be interesting.
Thank you for the information on the p4est functions. I will try those out and get back to you. Regards, Pratik. On Monday, April 2, 2018 at 10:01:54 PM UTC+2, Wolfgang Bangerth wrote: > > > > Thank you for your reply. I understand that DD methods are not quite > > that popular now. But I wanted to explore the avenue keeping in mind the > > issue of scalability as well. For scalability, as you mention > > communication is probably the bottleneck. > > No, communication is not the issue. It's not a computational problem but > a mathematical one: in each DD iteration, you only transport information > from one subdomain to the next subdomain. If you split the domain into > too many subdomains, you will need a lot of iterations to transport > information across the entire domain. In other words, the reason why DD > methods are not good for large processor counts is because the number of > outer iterations grows with the number of processors you have -- it just > doesn't scale. > > A different perspective is that DD methods lack some kind of coarse grid > correction in which you exchange information globally. You could > presumably use a non-overlapping mortar method and get good parallel > scalability if you had a good preconditioner for the Schur complement > posed on the skeleton (i.e., the DoFs that are located on the interfaces > between subdomains). Of course, constructing such preconditioners has > also proven to be difficult. > > > > > It would be very helpful if you could provide me with some pointers for > > where and how to change the p4est functions in deal.II. > > All of the code that interfaces with p4est is in > source/distributed/tria.cc. We build the ghost layer in line 2532 where > we call p4est_ghost_new (through its dimension independent alias). That > function is defined here: > > > http://p4est.github.io/api/p4est__ghost_8h.html#a34a0bfb7169437f6fc2382a67c47e89d > > > You'll probably have to call p4est_ghost_expand() one or more times: > > > http://p4est.github.io/api/p4est__ghost_8h.html#ab9750fa62cbc17285a0eb5cfe13a1e28 > > > I would just stick a call to this function right after the one to > ghost_new as a trial and see what happens in a small test program that > on each processor just outputs information about what cells are locally > owned and which are ghosts. > > Best > W. > > -- > ------------------------------------------------------------------------ > Wolfgang Bangerth email: bang...@colostate.edu > <javascript:> > www: http://www.math.colostate.edu/~bangerth/ > -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
