On Jul 23, 2008, at 1:50 PM, Tony S Yu wrote:
I was playing around with concatenating meshes, and I noticed that
the concatenation code was quite slow for me. All the magic seemed
to happen in mesh._getAddedMeshValues, so I messed around with the
code a bit:
I flattened a couple of nested loops (at the cost of memory; I don't
know if this is an issue) and the performance improved a bit. I also
changed the code to iterate only over exterior vertices to check for
vertex matching (I imagine that's the only place you want to check
for mesh correlation, but I could be wrong). There's probably a few
more things that can be done, but I decided I don't need to
concatenate meshes (for now, at least) so I shouldn't put anymore
time into it. If you're interested, I've included a patch. All tests
pass (except some small numpy 1.1 issues which existed previously)
on my computer, but it should probably be tested on numpy 1.0.4.
These all sound like reasonable changes (we never made any effort at
efficiency in mesh concatenation, in the theory that it only happens
once, before you start iterating; I won't argue that it can get
tedious while you're troubleshooting, though).
I'll look over your patch and apply it in the next day or two. Thanks
very much for the contribution.
Unfortunately, some numpy methods I wanted to use weren't available
in tools.numerix so I added an import numpy statement to the top of
`mesh.py`.
???
(almost) The first thing fipy.numerix does is `from numpy import *`,
so all these functions are available and identical:
>>> import numpy
>>> from fipy import numerix
>>> numpy.unique
<function unique at 0xd7e6b0>
>>> numerix.unique
<function unique at 0xd7e6b0>
>>> numpy.hstack
<function hstack at 0xd71970>
>>> numerix.hstack
<function hstack at 0xd71970>
>>> numpy.expand_dims
<function expand_dims at 0xd71830>
>>> numerix.expand_dims
<function expand_dims at 0xd71830>
>>> numpy.where
<built-in function where>
>>> numerix.where
<built-in function where>
>>> numpy.sort
<function sort at 0xbebfb0>
>>> numerix.sort
<function sort at 0xbebfb0>
>>> numpy.all
<function all at 0xbfe4b0>
>>> numerix.all
<function all at 0xbfe4b0>
The only purpose of fipy.numerix is to override behavior of NumPy that
we don't like or need to augment (and to give us some insulation when
they decide that Numeric, numarray, and numpy aren't enough and they
need to release another, virtually identical library with a different
name). In all other respects, fipy.numerix *is* numpy.
