dolfin team mailing list archive

[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()

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