Daniel already got to most of your questions, already, but I'll cover a few:


On Dec 30, 2011, at 9:16 PM, James Snyder wrote:

> On Tue, Dec 27, 2011 at 2:59 PM, Jonathan Guyer <[email protected]> wrote:

> In this case, I actually wanted that portion of the mesh to be empty,
> and I think that forces it to fill in.  I was sort-of intentionally
> leaving the Physical Volume there as a check to see whether or not I
> had accidentally broken something, but perhaps it will end up empty by
> default.

Ah, OK. I don't know what Gmsh thinks "Physical Volume("Pod") = 10006;" means, 
but it probably doesn't matter if you don't want these cells to come through 
anyway.


> Thanks, those seem to work quite well.  I'd also like to mask out the
> empty volume from the Grid2D in the middle, but I suppose what I can
> do there is either use the same measurements to make an unstructured
> mesh with the center hollowed out (ala the 2d example code posted), or
> somehow try and make a planar polygon out of the hollow section and
> use something like matplotlib's points_inside_poly:
> http://matplotlib.sourceforge.net/api/nxutils_api.html#matplotlib.nxutils.points_inside_poly

Either approach would work. The 'slab' technique I showed will only include 
points that are actually in your mesh (without the hollowed out center), but 
it's not too useful for visualization, if that's what you're after. In general, 
Mayavi cut planes and other visualization tools are probably going to be more 
satisfactory.

> Say if I'm using these
> types of terms of terms for current computation:
> topflux =(flux*mesh.physicalFaces['EcBack']).dot(projections).sum()
> 
> then getting: topflux.getNumericValue()
> 
> I see there's a getGlobalValue, but that doesn't apply to something
> that's a constructed operation.

I do the exact same calculation in some of my own work and have apparently 
never tried to run it in parallel. 

It's not that globalValue doesn't apply to a "constructed operation" (what we 
call an OperatorVariable). 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.

At least in this case, I don't think any changes to FaceVariable are necessary. 
I believe that this will do what you want:

topflux = (-flux*mesh.physicalFaces['EcBack']).divergence.cellVolumeAverage * 
mesh.globalNumberOfCells


_______________________________________________
fipy mailing list
[email protected]
http://www.ctcms.nist.gov/fipy
  [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]

Reply via email to