dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #19121
Re: [Branch ~dolfin-core/dolfin/main] Rev 4986: Implement named MeshFunctions in Python. Might be a better way (using SWIG
On Mon, Aug 16, 2010 at 10:28:10AM -0700, Johan Hake wrote:
> On Monday August 16 2010 10:07:41 Anders Logg wrote:
> > On Mon, Aug 16, 2010 at 09:57:26AM -0700, Johan Hake wrote:
> > > On Monday August 16 2010 05:51:24 noreply@xxxxxxxxxxxxx wrote:
> > > > ------------------------------------------------------------
> > > > revno: 4986
> > > > committer: Anders Logg <logg@xxxxxxxxx>
> > > > branch nick: dolfin-dev
> > > > timestamp: Mon 2010-08-16 14:48:44 +0200
> > > >
> > > > message:
> > > > Implement named MeshFunctions in Python. Might be a better way (using
> > > >
> > > > SWIG magic).
> > >
> > > I think it is fine. The only reason we would like to wrap it using SWIG
> > > would be to preserve the types. So one could check if a passed
> > > MeshFunction is for example a VertexFunction. But I think we should not
> > > encourage that and instead use dim.
> >
> > ok.
> >
> > > When I looked at the Python implementation I wonder if we should
> > > harmonize the data type setting with NumPy. Instead of 'int' pass either
> > > int or 'i', and so on.
> > >
> > > If you agree, do you know of any other place where we could do such a
> > > harmonizing?
> >
> > Isn't the problem that with "uint" we get the expected type (that
> > matches dolfin::uint in C++). Last time I checked, the NumPy list of
> > int types is a jungle of different options.
>
> Yes, but we have setled in the NumPy typemaps on the correct one. It is to use
> "I" or unit32 for unsigned int. This will not be any problem eitherway as
> these types are just used to instantiate the correct MeshFunctionFoo. in the
> same "switch" statement we have now.
I imagine "uint" is easier since that is used in C++, or maybe it's
simple for me because I'm working on the DOLFIN C++ code and see a lot
of "uint"...
> > > I also think it is better to implement the named MeshFunctions as
> > > inheriting from MeshFunction, instead of just beeing functions that
> > > returns. I can fix this.
> >
> > I tried but it didn't work (the constructors were not called) but I'm
> > sure you know how to fix it. :-)
>
> Just use __new__:
>
> class VertexFunction(MeshFunction):
> "Create MeshFunction of topological dimension 0 on given mesh."
> def __new__(self, value_type, mesh):
> return MeshFunction.__new__(self, value_type, mesh, 0)
Why?
--
Anders
Attachment:
signature.asc
Description: Digital signature
Follow ups
References