On Fri, 2010-08-06 at 20:44 +0200, Anders Logg wrote: > On Fri, Aug 06, 2010 at 06:52:58PM +0100, Garth N. Wells wrote: > > On Fri, 2010-08-06 at 10:06 -0700, Johan Hake wrote: > > > On Friday August 6 2010 09:52:20 Garth N. Wells wrote: > > > > We have an issue with MixedFunctionSpace which makes incorrect usage > > > > very easy. For example, if I have > > > > > > > > V = VectorFunctionSpace(mesh, "CG", 2) > > > > Q = FunctionSpace(mesh, "CG", 1) > > > > W = V * Q > > > > > > > > The dof maps for Q and W.sub(1) are not the same. I've seen a number of > > > > users using V or Q in setting boundary conditions rather than W.sub(0) > > > > and W.sub(1). > > > > > > I have done this mistake myself :P > > > > > > I guess this problem only excist in POyDOLFIN? > > > > > > > Yes. > > > > > > When using > > > > > > > > W = MixedFunctionSpace([ V, Q]) > > > > > > > > could we create W and then inside the MixedFunctionSpace constructor set > > > > > > > > V = W.sub(0) > > > > Q = W.sub(1) > > > > > > No as you are then just changing the local references of V and Q inside > > > the > > > __init__ method. > > > > I realise this, but then at least Q and W.sub(1) will point to the same > > space. It may be confusing the creating a mixed space changes V and Q. > > I don't understand how that will work. There is no way that the call > to MixedFunctionSpace can change the meaning of V and Q. It would also > be confusing and dangerous. What we could do is change some property > of V and Q (like the offset) but that would lead to other problems > (see below). > > > > What you need is a method of FunctionSpace that transform it > > > to a SubSpace. Not sure that is possible? > > > > > > Is there a user case where V and Q are used for what they are (not > > > subspaces), > > > after a declaration of a mixed space? We will screw such a use if we turn > > > V > > > and Q into a subspaces. > > > > > > If this is not a consern, we might be able to tag V and Q as beeing used > > > to > > > create a mixed space inside the __init__ of mixedfunctionspace and issue > > > some > > > kind of warning (or exception!) whenever these are used to create a > > > Function > > > or someother FunctionSpace dependent object. This can be done purely in > > > the > > > Python layer. > > > > > > > I'm really not sure what the best approach is. > > Tagging V and Q as special because they have been used to create a > mixed function space would be bad since V and Q might very well be > used to create other functions which have no relation to the mixed > space. A simple example is a right-hand side f = Function(V) in > Stokes. > > A solution would be to let the BoundaryCondition class check that the > global size of the dofmap (of which the sub dofmaps are parts) and > compare with the vector or matrix it is manipulating. That check would > fail for V and Q but work for W.sub(0) and W.sub(1). >
Can we access the global size of W.sub(0) and W.sub(1)? Garth > -- > Anders _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp