dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Feb 16, 2009 at 12:21:52AM +0000, A Navaei wrote:
> 2009/2/15 Anders Logg <logg@xxxxxxxxx>:
> > On Sat, Feb 14, 2009 at 06:44:05PM +0000, Garth N. Wells wrote:
> >>
> >>
> >> A Navaei wrote:
> >> > [snip]
> >> >>>> Function should not change the FunctionSpace (that's why FunctionSpace is
> >> >>>> const). FunctionSpace shouldn't depend on the data and its size should be
> >> >>>> defined when creating the FunctionSpace.
> >> >>> The same applies for FunctionSpace as its member variables are private
> >> >>> and the public accessors are read-only which. Consider a sub-class
> >> >>> ImageFunctionSpace:FunctionSpace, with a constructor like:
> >> >>>
> >> >>> ImageFunctionSpace(ImageType *imagePtr)
> >> >>>
> >> >>> where imagePtr is supposed to initialise FunctionSpace::_mesh using
> >> >>> the image size, and then _dofmaps itself is initialised using _mesh.
> >> >>> How would you do that considering the restrictions?
> >> >>>
> >> >> The FunctionSpace has pointers to the mesh, etc. You just need to create
> >> >> your mesh and pass it to the FunctionSpace constructor. What else you then
> >> >> do with the mesh, etc is up to you.
> >> >
> >> > That can be done _outside_ of a sub-class. A sub-class of
> >> > FunctionSpace doesn't have a control over _mesh of its own parent
> >> > FunctionSpace. The following example may make this more clear:
> >> >
> >> > template <typename TImage>
> >> > class DolfinImageFunctionSpace : public dolfin::FunctionSpace
> >> > {
> >> > public:
> >> >         // just some itk typedefs -- ignore
> >> >     typedef TImage ImageType;
> >> >     typedef typename ImageType::PixelType PixelType;
> >> >     typedef typename ImageType::SizeType SizeType;
> >> >
> >> >         // .. and some dolfin typedefs -- ignore
> >> >     typedef typename std::tr1::shared_ptr<const dolfin::Mesh> MeshConstPointerType;
> >> >     typedef typename std::tr1::shared_ptr<const dolfin::FiniteElement>
> >> > ElementConstPointerType;
> >> >     typedef typename std::tr1::shared_ptr<const dolfin::DofMap>
> >> > DofMapConstPointerType;
> >> >
> >> >         // the ctor
> >> >     DolfinImageFunctionSpace(ImageType* imageData,
> >> >                                             MeshConstPointerType mesh,
> >> >                                             ElementConstPointerType element,
> >> >                                             DofMapConstPointerType dofmap) :
> >> >     dolfin::FunctionSpace(mesh, element, dofmap)
> >> >     {
> >> >             SizeType imageSize = imageData->GetBufferedRegion().GetSize();
> >> >
> >> >                 // here, we whish to call some thing like:
> >> >                 // _mesh = UnitSquare(imageSize[0], imageSize[1]);
> >> >                 // but it's private and the accessor is read-only.
> >> >     };
> >> > }
> >> >
> >>
> >> This breaks the concept of a function space. A function space is defined
> >> in terms of a mesh (and other things). A function space does not define
> >> its mesh.
> >>
> >> It looks to me like the class that you're creating should be called
> >> something like
> >>
> >>    DolfinImageProblem,
> >>
> >> which can create its own Mesh, FunctionSpace and other objects.
> >>
> >> Garth
> >>
> >> >
> >> > -Ali
> >
> > I think what you need to do is something like this:
> >
> > 1. Create a subclass of Function
> >
> > 2. In the constructor of your Function, call the empty Function()
> > constructor
> >
> > 3. Then, still in the constructor of your Function (not
> > FunctionSpace), create everything necessary like figuring out the
> > mesh, dofmap etc and from that create a FunctionSpace
> >
> > 4. Then use that FunctionSpace (still in the constructor of your
> > Function subclass) to create a new Function v which uses your special
> > FunctionSpace in its constructor
> >
> > 5. Finally, assign this function to the created Function:
> >
> >  *this = v;
> 
> This sounds good to me. We should decide which approach to take for
> image functions. Would ImageFunction:Function be reasonable, or do we
> also need an ImageFunctionSpace:FunctionSpace? If we need the latter,
> FunctionSpace should come with a default (empty) constructor, or the
> above wouldn't work. I guess once we have the image structure in the
> discrete function form, a new class of problem, eg
> ImageProcessingProblem, as Garth suggested earlier can be developed.

I suggest you try without creating a special ImageFunctionSpace (as it
seems to be the easiest to implement). Just create the particular data
for a FunctionSpace in the ImageFunction constructor.

-- 
Anders

Attachment: signature.asc
Description: Digital signature