dolfin team mailing list archive

[A Navaei <axnavaei@xxxxxxxxxxxxxx>]

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.


-Ali

>
> --
> Anders
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkmYeL8ACgkQTuwUCDsYZdE8VACfcrQAAekRd9a7uksPYQT4Fl8X
> jAcAn0SwLyIhsmhw1nMv/vy6t/XDEml3
> =mkvK
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>
>