On Mon, Mar 14, 2011 at 01:04:13PM -0700, Johan Hake wrote: > On Monday March 14 2011 12:57:32 Anders Logg wrote: > > On Mon, Mar 14, 2011 at 10:31:21AM -0700, Johan Hake wrote: > > > On Monday March 14 2011 10:25:10 Anders Logg wrote: > > > > On Mon, Mar 14, 2011 at 09:06:00AM -0700, Johan Hake wrote: > > > > > On Monday March 14 2011 08:44:19 Neilen Marais wrote: > > > > > > Johan, > > > > > > > > > > > > On Mon, Mar 14, 2011 at 5:21 PM, Johan Hake <[email protected]> > > > > > > wrote: > > > > > > > On Monday March 14 2011 04:36:29 Neilen Marais wrote: > > > > > > > If you have an already tetrahedralized structure, typically given > > > > > > > by a coordinate array and an array of conductivities between > > > > > > > cells and vertices, you can use MeshEditor. That is what > > > > > > > MeshEditor really is for. > > > > > > > > > > > > > > > > > > > > > I think the advice of not using MeshEditor is when you use it to > > > > > > > construct the vertices and connectivities by hand. > > > > > > > > > > > > I guess I'm just worrying about performance in python, since I > > > > > > would have to do one method call for each vertex and one for each > > > > > > tet. I may be prematurely optimising here, but IIRC even method > > > > > > calls to SWIG wrapped C++ classes have a fair amount of overhead. > > > > > > Since I already have the vertex coordinates and cell -> vertex > > > > > > connectivity data in arrays, it is obviously much faster to just > > > > > > stuff them directly into the dolfin structures? > > > > > > > > > > Sure you are right that it might come with some overhead. Not sure it > > > > > will be significant though, as this would probably be a one time > > > > > thing? > > > > > > > > > > But after reading your post one more time I realize what you asked > > > > > for > > > > > > > > > > :P, and the answer is yes! You can perfectly do what you did. > > > > > > > > > > mesh.cells() and mesh.coordinates() each return a NumPy array view of > > > > > the actuall data. Your syntax works because NumPy allows it. > > > > > > > > It works because it happens to work. It's not intended usage and it > > > > might break if we change the implementation MeshEditor, even if the > > > > interface stays the same. > > > > > > > > It would be better to add some utility function for creating a Mesh > > > > based on arrays. > > > > > > I agree. > > > > > > But as long as we store the coordinates and cells as contiguous arrays in > > > the mesh, they will be exposed to Python through NumPy and this will > > > just work. > > > > Not necessarily. The MeshEditor might postpone initializing the arrays > > until it has received all calls to add_cell etc and only then allocate > > the arrays. So the mixing of MeshEditor.open, close and array access > > only works if it is compatible with what MeshEditor does internally. > > So you are saying that if not MeshEditor get calls for add_{vertex, cell} for > all of the registered entities it wont allocate memory for these guys? I > suppose it wont be possible to call close then as it wont make any sense if > the data is not allocated?
No, I'm saying that it works now since MeshEditor happens to allocate before the calls to add_cell etc. But MeshEditor may choose to do things differently internally (like caching of the added data before allocating/flushing to the arrays) and then it won't work. So my point is it works now, but it's fragile since its outside the interface of MeshEditor. -- Anders _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
