I've considered this problem a little in the case of multigrid; however, I haven't really implemented anything parallel yet. My serial implementation works for meshes where the domains are not nested by nearest-point-in-domain. The problem is a little different as I have to create an interpolation matrix rather than just interpolating between vectors. This matrix is built by doing a search-by-traversal across the two meshes in tandem, with special cases to handle when it gets lost. Processor boundaries will be one of these cases. When I parallelize the multigrid remeshing I intend to keep the domains local, but It wouldn't be such an issue to not do this as I want to be able to supply meshes to the multigrid routines as well. This would require the kind of search that you're talking about here, though.
The difference is that my interpolator doesn't have to be very accurate because I'm interpolating errors, not solutions. This means that I can take some shortcuts and/or do things by some integral averaging (a Scott-Zhang type interpolant). I had some trouble finding the interpolation routines in DOLFIN that support multiple meshes. Could you point me to them? This problem is quite important to what I'm trying to do here and I might be able to contribute something. Doing this with some matrix object might be for the best, also, as these operations tend to be fairly heavyweight. You could also use the patterns generated here to weight some redistribution of the meshes if you're doing this operation a lot. Thanks, - Peter On Mon, Aug 9, 2010 at 9:19 AM, Anders Logg <l...@simula.no> wrote: > On Mon, Aug 09, 2010 at 03:02:18PM +0100, Garth N. Wells wrote: > > On Mon, 2010-08-09 at 15:54 +0200, Ola Skavhaug wrote: > > > On Mon, Aug 9, 2010 at 3:39 PM, Garth N. Wells <gn...@cam.ac.uk> > wrote: > > > > On Mon, 2010-08-09 at 15:32 +0200, Ola Skavhaug wrote: > > > >> Hi, > > > >> > > > >> when running DOLFIN in parallel, data reduction would be a nice > thing > > > >> to have. Typically, it would be good to have something like this: > > > >> > > > >> mesh = UnitSquare(2000, 2000) > > > >> reduced_mesh = UnitSquare(200, 200) > > > >> > > > >> V = FunctionSpace(mesh, "CG", 1) > > > >> reduced_V = FunctionSpace(reduced_mesh, "CG", 1) > > > >> > > > >> u = Function(V) > > > >> > > > >> ... > > > >> > > > >> reduced_u = interpolate(u, reduced_V) > > > >> f << reduced_u > > > >> > > > >> However, the problem is that the automatic partitioning of the > meshes > > > >> constructs two different non-overlapping meshes on each local node. > I > > > >> really don't want to allow extrapolation in this case. I would be > > > >> happy to contribute fixing this problem; does anybody see how to > > > >> attack it? > > > >> > > > > > > > > We just need to have the program handle correctly the case in which a > > > > point is not found in the domain. It shouldn't be hard to fix (it may > be > > > > just a case of removing an error message ans stressing in the code > > > > comment that points must reside on the same process). > > > > > > > > Start by looking in the Function::interpolate functions. > > > > > > Isn't the issue here that since the local meshes don't overlap, we > > > need to fetch the values from one or more neighboring processes? So, > > > during interpolation in parallel, all processes send a list of > > > coordinates for the values needed that are not local, and then all > > > processes send and receive these values. Or is this too simple for > > > more advanced elements? > > > > > > > The first step of finding the cell which contains a point doesn't depend > > on the element. We don't have this in place for points which reside on > > other processes. The next step would be for the value of function to be > > evaluated and communicated. > > I suggest that when a point is found which is not inside the domain > and MPI::num_processes > 1, the point is added to a list of points > which are not inside the domain. Then all the missing points are > distributed to all processes and each process goes through the list of > points to see which points it can handle. Then the results are > communicated back. I think this is the same as what Ola suggests. > > The problem with this is that it can potentially lead to quite a lot > of communication. In the worst case, all points would be missing for > all processes and then all points would have to be passed around > between all processes. But I don't see any other way since it's not > possible for a process to know where a missing point may be located. > > -- > Anders > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAkxgDncACgkQTuwUCDsYZdG6cACdE3u0O50658K3Llr2DNLaHyU6 > 44UAn1/zql0Uh/oRuIpKnWrW6VnYwdgm > =98Vv > -----END PGP SIGNATURE----- > > _______________________________________________ > Mailing list: https://launchpad.net/~dolfin<https://launchpad.net/%7Edolfin> > Post to : dolfin@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dolfin<https://launchpad.net/%7Edolfin> > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
