2011/1/31 Jonathan Guyer <[email protected]> > > > On Jan 31, 2011, at 11:43 AM, Benny Malengier wrote: > > > I have a problem with mesh addition. Script in attachment leads to a > MemoryError in numpy for me if I use nx,ny,nz=10,80,80, and to a very slow > operation when I use nx,ny,nz=80,80,10. > > Your script wasn't attached, but I see what you're talking about when I > concatenated two nx,ny,nz=10,80,80 grids. It got up to >16GiB of VM and 2.7 > GiB of RAM before I got bored and killed it. > > To concatenate meshes, FiPy has to figure out vertex correspondences, and > because looping is never viable in Python, it does this with full-factorial > vectorized NumPy calculation (all 72171 vertices of one mesh compared with > all 72171 vertices of the other), which requires the allocation of about > 1.6e10 floats. Needless to say, this needs a *lot* of memory. Even if it > succeeds, it's going to thrash VM so much on most systems as to be not worth > it. This is not very satisfactory, but I don't see a realistic solution. > > I've followed some discussions of distance trees and the like on the SciPy > list, but they all seem to boil down to more or less what we're doing. > Probably worth another look, though. > > > > So there seems to be some axis preference? > > Probably just a fluke. I don't see anything in the code that would favor Z > over X. > > > > Is addition of 3D meshes better avoided, using gmsh instead to make a > mesh? > > FiPy's mesh construction utilities never were (and never will be) very > sophisticated. So, yes, best to use a tool like Gmsh better suited to the > task. > > > PS: I have some local changes, but they don't interfere with the things > this simple script does. > > Agreed. >
I had a local change previously that introduced a function to add meshes, where you pass in the vertices of the first mesh and the faces of the second mesh that where involved. An alternative would be a method in which the algebraic equation of the surface on which to concatenate is passed. This worked great on 2D meshes, but the changes in trunk made adding meshes in 2D just as fast as with this specific function. On 3D reintroducing such a function might be a solution. On the other hand, adding uniformgrid3d meshes, one could assume only the external boundary vertices must be compared. I'll go for gmsh for now. Thanks for having a look Benny
