← Back to team overview

dolfin team mailing list archive

Re: A minimal c++ Function test and some bugs

 

2009/2/19 Johan Hake <hake@xxxxxxxxx>:
> On Thursday 19 February 2009 14:46:18 A Navaei wrote:
>> 2009/2/19 Garth N. Wells <gnw20@xxxxxxxxx>:
>> > A Navaei wrote:
>> >> 2009/2/19 Johan Hake <hake@xxxxxxxxx>:
>> >>> The previous email was sent a bit premature...
>> >>>
>> >>> [snip]
>> >>>
>> >>>>> I have also thought of this :)
>> >>>>>
>> >>>>> Then you can take an ordered mesh, iterate over the vertices, and use
>> >>>>> the
>> >>>>> present implementation of the eval function (which in its present
>> >>>>> shape is a piecewise constant interpolator isn't it?), to fill the
>> >>>>> new _vector,
>> >>>>> all done in the constructor. Then you have a discrete function in the
>> >>>>> first place :)
>> >>>>
>> >>>> Is it possible to set the pointer to _vector data directly where we
>> >>>> can pass the pointer to image data? If this works, no loop will be
>> >>>> involve in data conversion and it will be super fast.
>> >>>
>> >>> Yes but you do not know how the mesh is ordered.
>> >>
>> >> Consider a 2D image data mapped on a structured grid, with size
>> >> (number of nodes in each direction) of (sx, sy), the value of image
>> >> brightness at coordinate (i, j) is given by I(k), where:
>> >>
>> >> k = i + sx * j
>> >>
>> >> Is this not enough information to create the mesh?
>> >>
>> >>>> It seems _vector.set()
>> >>>>
>> >>>> (http://www.fenics.org/pub/documents/dolfin/dolfin-progr-reference/d6/
>> >>>>da4/c
>> >>>> lassdolfin_1_1GenericVector.html#bc4ecede55f2846ecadae02426df8f63)
>> >>>> accepts
>> >>>> the pointer to each row, is that right?
>> >>>
>> >>> There is no such thing as a row in a vector. It stores the data in a
>> >>> contigouos way (if not distributed).
>> >>
>> >> No idea why it says rows: virtual void dolfin::GenericVector::set
>> >> (const double *block, const uint *num_rows, const uint *const *
>> >>        rows).
>> >
>> > You can set as few or as many entries as you wish at once. 'block'
>> > contains the values you want to set, 'num_rows' are the number of entries
>> > you wish to set, and 'rows' are the positions into which the entries
>> > should be inserted.
>>
>> I hate to say this, but _vector is private!
>
> ... and perfectly accesable through vector()

... and perfectly read-only through vector()


-Ali

>
> Johan
>
>>
>> -Ali
>>
>> > Garth
>> >
>> >>>> Is there a better way of assigning the whole data at once?
>> >>>
>> >>> Maybe but you then have to be sure that your data is arrange in exact
>> >>> same
>> >>> manner as the mesh.
>> >>
>> >> As long as we work with complete rectangular images, which is the
>> >> frequently used case, it should be fine. Given this, how is it
>> >> possible to directly assign the image data pointer to _vector?
>> >>
>> >>>>> Note that this will only work for a piecewise linear lagrange
>> >>>>> FunctionSpace.
>> >>>>
>> >>>> It should be ok, it would be equivalent of having the image function
>> >>>> initialised with Lagrange element, but much more faster.
>> >>>>
>> >>>>> But haveing this in place you can always interpolate to other
>> >>>>> FunctionSpaces. However these interpolations will only be linear of
>> >>>>> course.
>> >>>>
>> >>>> It is not possible to interpolate a function to another space using
>> >>>> non-linear interpolators?
>> >>>
>> >>> If your raw image data is represented by a linear FunctionSpace any
>> >>> interpolation using this space would be linear.
>> >>
>> >> Right, that's yet another problem.
>> >>
>> >>
>> >> -Ali
>> >>
>> >>> Johan
>> >>>
>> >>>> To Anders: Do you think if this is more practical and efficient than
>> >>>> the other discussed approach? Would this be general enough to work
>> >>>> with an arbitrary PDE of any finite element type?
>> >>>>
>> >>>>
>> >>>> -Ali
>> >>>>
>> >>>>> Johan
>> >>>>>
>> >>>>>> -Ali
>> >>>>>>
>> >>>>>>> -Ali
>> >>>>>>>
>> >>>>>>>>>>> Another way of doing this could be by the use of an existing
>> >>>>>>>>>>> FunctionSpace:
>> >>>>>>>>>>>
>> >>>>>>>>>>>  UnitSquare dummy_mesh(1, 1);
>> >>>>>>>>>>>  PoissonFunctionSpace V(dummy_mesh);
>> >>>>>>>>>>>  ImageFunction v(image, V);
>> >>>>>>>>>>>
>> >>>>>>>>>>> Then, in the constructor of ImageFunction, V.element and
>> >>>>>>>>>>> V.dofmap can be used to create another FunctionSpace which has
>> >>>>>>>>>>> a mesh created using image:
>> >>>>>>>>>>>
>> >>>>>>>>>>>  ImageToFunction(Image image, const FunctionSpace& V)
>> >>>>>>>>>>>  {
>> >>>>>>>>>>>    // Create the function space
>> >>>>>>>>>>>    UnitSquare mesh(image.get_size()[0] - 1, image.get_size()[1]
>> >>>>>>>>>>> - 1); FunctionSpace IV(mesh, V.element(), V.dofmap());
>> >>>>>>>>>>>
>> >>>>>>>>>>>    // ...
>> >>>>>>>>>>>  };
>> >>>>>>>>>>>
>> >>>>>>>>>>> The problem with this approach is that it involves the use of a
>> >>>>>>>>>>> dummy mesh.
>> >>>>>>>>>>>
>> >>>>>>>>>>> A mesh-independent constructor added to FunctionSpace could
>> >>>>>>>>>>> help. Alternatively, if a (protected) default (empty)
>> >>>>>>>>>>> constructor is added to FunctionSpace,
>> >>>>>>>>>>> ImageFunctionSpace:FunctionSpace can have a mesh-independent
>> >>>>>>>>>>> constructor. However, the FFC-generated function spaces, eg
>> >>>>>>>>>>> PoissonFunctionSpace, still need a mesh.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Hope this makes the problem more clear now.
>> >>>>>>>>>>
>> >>>>>>>>>> Create the mesh and the FunctionSpace subclass inside the
>> >>>>>>>>>> ImageFunction constructor. Neither the mesh nor the function
>> >>>>>>>>>> space need to be visible outside.
>> >>>>>>>>>
>> >>>>>>>>> Again, there is no mesh-free ctor for FunctionSpace, and it
>> >>>>>>>>> doesn't come with a default ctor so that the subclass can
>> >>>>>>>>> implement a mesh-free ctor. I quote the above again:
>> >>>>>>>>
>> >>>>>>>> You don't need a mesh-free constructor for FunctionSpace, see
>> >>>>>>>> above.
>> >>>>>>>>
>> >>>>>>>>> ' A mesh-independent constructor added to FunctionSpace could
>> >>>>>>>>> help. Alternatively, if a (protected) default (empty) constructor
>> >>>>>>>>> is added to FunctionSpace, ImageFunctionSpace:FunctionSpace can
>> >>>>>>>>> have a mesh-independent constructor.'
>> >>>>>>>>
>> >>>>>>>> It's not needed if you do as I suggest.
>> >>>>>>>>
>> >>>>>>>> --
>> >>>>>>>> Anders
>> >>>>>>>>
>> >>>>>>>> -----BEGIN PGP SIGNATURE-----
>> >>>>>>>> Version: GnuPG v1.4.9 (GNU/Linux)
>> >>>>>>>>
>> >>>>>>>> iEYEARECAAYFAkmdMN8ACgkQTuwUCDsYZdGnOQCdFBJSD4FymLnVPbheRt63aJJa
>> >>>>>>>> yyoAn3KDuOmwd8ZX5YR1KucbafvieNBc
>> >>>>>>>> =lpyI
>> >>>>>>>> -----END PGP SIGNATURE-----
>> >>>>>>>>
>> >>>>>>>> _______________________________________________
>> >>>>>>>> DOLFIN-dev mailing list
>> >>>>>>>> DOLFIN-dev@xxxxxxxxxx
>> >>>>>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> DOLFIN-dev mailing list
>> >>>>>> DOLFIN-dev@xxxxxxxxxx
>> >>>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>> >>
>> >> _______________________________________________
>> >> DOLFIN-dev mailing list
>> >> DOLFIN-dev@xxxxxxxxxx
>> >> http://www.fenics.org/mailman/listinfo/dolfin-dev
>
>
>


Follow ups

References