dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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 <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?

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