On Thu, Oct 17, 2013 at 1:00 PM, James Snyder <[email protected]> wrote: > I guess I have part of my answer from an older question I asked last year: > http://permalink.gmane.org/gmane.comp.python.fipy/2353 > > In there Jonathan mentioned: >> >> The issue is that flux is a FaceVariable and although we define a >> globalValue for FaceVariables, it >> doesn't look like it has a clear meaning. The issue is that there are >> cells and faces that overlap multiple >> processors. The globalValue for a CellVariable properly accounts for the >> ghost cells, but >> FaceVariables do not. There hasn't been any internal need to and we >> suspect that clearing it up will be a >> mess (there is an ambiguity with faces that doesn't exist with cells; some >> faces are shared between >> processors even for non-overlapping cells). We do need to examine whether >> globalValue should even be >> defined for anything besides CellVariables.
Thanks for bringing this up again, we should move "globalValue" and "_getGlobalVaue" method to "CellVariable" and out of "_MeshVariable". As explained, a global face variable is hard to calculate in the general case. > Since what I'm trying to do is just get face centers so I can make a convex > hull around what is essentially an internal "hole" in the mesh. If I just > want to merge the face centers from each process should I use MPI comm > primitives to pull them together or is there a cleaner way to get this > within the existing framework? I'm not really sure what you are trying to do here. What is the purpose? Maybe there is another way. > Also, congrats on getting 3.1 out, especially in terms of timing :-) Thanks very much. How are you findining using FiPy in parallel? What sort of speed ups are you getting? -- Daniel Wheeler _______________________________________________ fipy mailing list [email protected] http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
