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).
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
