dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

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 <johan.hake@xxxxxxxxx>
> > 
> > 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?

Johan

> --
> Anders