On Tuesday 24 February 2009 21:07:43 A Navaei wrote: > 2009/2/24 Johan Hake <[email protected]>: > > On Tuesday 24 February 2009 16:17:43 A Navaei wrote: > >> 2009/2/24 Johan Hake <[email protected]>: > >> > On Tuesday 24 February 2009 01:08:11 A Navaei wrote: > >> >> Finally after all those long discussions on the best way of > >> >> architecturing variational image processing problems based on dolfin, > >> >> a minimal demo showing how to solve a classical motion estimation PDE > >> >> is available now -- thanks for all the support. Detailed explanation > >> >> is given here: > >> >> > >> >> http://code.google.com/p/debiosee/wiki/DemosOptiocFlowHornSchunck > >> >> > >> >> Currently, the c++ implementation is done and the python wrapper is > >> >> on the way. > >> > > >> > Cool! > >> > > >> >> I have tried to perform sub-classing as much as possible and leave > >> >> the rest to be implemented outside of the main classes. While this > >> >> works, there is a tiny problem which I'm not quite happy about. Here > >> >> is what's happening: > >> >> > >> >> [ITK-backend] > >> >> > >> >> v > >> >> [GenericImage]-------\ > >> >> > >> >> v | > >> >> [ImageToMesh] | > >> >> > >> >> v | > >> >> [FunctionSpace] | > >> >> > >> >> v | > >> >> [ImageFunction]<-----/ > >> >> > >> >> If you still cannot see what's happening, get a monospace font :) > >> >> What I don't like is the right branch connecting GenericImage to > >> >> ImageFunction. There should be a way of making sure that the two > >> >> branches are initiated from the same image source, or this could be a > >> >> source of error. Simply encapsulating this in a class takes away the > >> >> freedom of defining a general problem away from the user. > >> > > >> > Just a thought: > >> > > >> > Would it help to let GenericImage also be a dolfin::Mesh? Then in > >> > ITKImage you copy paste the algorithm for creating a > >> > UnitCube/UnitSquare/Rectange/Box (the algorithms are actually not very > >> > large). > >> > >> I understand that implemented algorithms are short, but maybe it's not > >> a good practice to copy/paste the code (even if it's a short code). We > >> should think of a more creative way of doing this. > > > > Sure ;) > > > > One alternative could be to inherit UnitSquare directly but then we need > > to put the creation algorithm in, e.g., an init function (protected such > > ;) ). This will then be called in the constructor, and we also need an > > empty constructor to be called by the inherited mesh, which may or may > > not make any sense at all. > > This looks like something feasible to me. What about having a virtual > Mesh::Init() called in Mesh() so that the subclasses just have to > override Init()? Then in the ImageMesh case, the parent Init() should > be also called and the extra branch in the diagram will disappear.
I have to call for comments from the other c++ hackers for such change. > In case you missed the other question, is the information about number > of cells in each dimension lost in UnitSquare or can it be retrieved? Well ... I avoided it, I had not think it through I think ;) If we should add them I guess we need to include other similare attributes from the other built in meshes too? Johan _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
