Problem using sub-spaces

[Garth Wells]

Hi,

I have trouble using MixedFunctionSpace. Basically I want to project a function to a subspace of a MixedFunctionSpace:

   from dolfin import *
   mesh=UnitInterval(10)
   U = FunctionSpace(mesh, "CG", 1)
   V = FunctionSpace(mesh, "CG", 1)
   W=U*V
   f1=Function(W.sub(0))
   f1.vector()[:]=1.0
   #f2=project(f1, V) # This works!
   f2=project(f1, W.sub(1)) # This doesn't!

The output of that script is attached to the end of this question. Now, the confusing thing is that the projection works fine if one projects to V instead of W.sub(1), although they are mathematically the same spaces.

I hope I haven't missed a similar question already reported.

Best wishes,

Simon

[0]PETSC ERROR: ------------------------------------------------------------------------
[0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably memory access out of range
[0]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger
[0]PETSC ERROR: or see http://www.mcs.anl.gov/petsc/petsc-as/documentation/troubleshooting.html#Signal[0]PETSC ERROR: or try http://valgrind.org on GNU/linux and Apple Mac OS X to find memory corruption errors
[0]PETSC ERROR: configure using --with-debugging=yes, recompile, link, and run
[0]PETSC ERROR: to get more information on the crash.
[0]PETSC ERROR: --------------------- Error Message ------------------------------------
[0]PETSC ERROR: Signal received!
[0]PETSC ERROR: ------------------------------------------------------------------------
[0]PETSC ERROR: Petsc Release Version 3.1.0, Patch 3, Fri Jun 4 15:34:52 CDT 2010
[0]PETSC ERROR: See docs/changes/index.html for recent updates.
[0]PETSC ERROR: See docs/faq.html for hints about trouble shooting.
[0]PETSC ERROR: See docs/index.html for manual pages.
[0]PETSC ERROR: ------------------------------------------------------------------------
[0]PETSC ERROR: Unknown Name on a linux-gnu named doodson by sf1409 Thu Nov 25 13:17:44 2010
[0]PETSC ERROR: Libraries linked from /build/buildd/petsc-3.1.dfsg/linux-gnu-c-opt/lib
[0]PETSC ERROR: Configure run at Fri Sep 10 04:57:14 2010
[0]PETSC ERROR: Configure options --with-shared --with-debugging=0 --useThreads 0 --with-clanguage=C++ --with-c-support --with-fortran-interfaces=1 --with-mpi-dir=/usr/lib/openmpi --with-mpi-shared=1 --with-blas-lib=-lblas --with-lapack-lib=-llapack --with-umfpack=1 --with-umfpack-include=/usr/include/suitesparse --with-umfpack-lib="[/usr/lib/libumfpack.so,/usr/lib/libamd.so]" --with-spooles=1 --with-spooles-include=/usr/include/spooles --with-spooles-lib=/usr/lib/libspooles.so --with-hypre=1 --with-hypre-dir=/usr --with-scotch=1 --with-scotch-include=/usr/include/scotch --with-scotch-lib=/usr/lib/libscotch.so --with-hdf5=1 --with-hdf5-dir=/usr
[0]PETSC ERROR: ------------------------------------------------------------------------
[0]PETSC ERROR: User provided function() line 0 in unknown directory unknown file
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
with errorcode 59.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------

[Garth Wells (garth-wells)]

Could the problem be that W.sub(1) is a view into W? E.g., its dofmap does not start at zero, but is offset by the dimension of W.sub(0)?

[Anders Logg (logg)]

On Sun, Nov 28, 2010 at 08:55:11PM -0000, Garth Wells wrote:
> Could the problem be that W.sub(1) is a view into W? E.g., its dofmap
> does not start at zero, but is offset by the dimension of W.sub(0)?

Yes, I'm sure that's the problem.

--
Anders

[Johan Hake (johan-hake)]

I suggest we make it impossible to create a Function from dolfin.SubSpace. If a user want a sub function he should use one of:

  u.split(0)
  u.split(0, True)
  u[0]

Is a Subspace used for anything else than in the construction of DirichletBC? Also is the class FunctionSpaceFromCpp used for anything else that the construction of a SubSpace in the method FunctionSpace.sub?

[Mikael Mortensen (mikael-mortensen)]

Please don't.

The subspace functionality is used for example to compute the streamfunction, where the subspace of the velocity VectorFunctionSpace is used. I also use the subspace functionality to assemble into parts of the Navier-Stokes coefficient matrix componentwise. For example

uc = TrialFunction(V.sub(0))
vc = TestFunction(V.sub(0))
a = assemble(inner(grad(uc), grad(vc))*dx)

and then I can copy this 'small' matrix to the three diagonal slots of the 3*3 Laplacian matrix that makes up for the whole velocity vectorfield. I understand this is not the regular way of assembling, but it is much faster than switching V.sub(0) above to V and assembling the whole thing by itself.

[Garth Wells (garth-wells)]

On 29/11/10 08:35, Mikael Mortensen wrote:
> Please don't.
>
> The subspace functionality is used for example to compute the
> streamfunction, where the subspace of the velocity VectorFunctionSpace
> is used. I also use the subspace functionality to assemble into parts of
> the Navier-Stokes coefficient matrix componentwise. For example
>
> uc = TrialFunction(V.sub(0))
> vc = TestFunction(V.sub(0))
> a = assemble(inner(grad(uc), grad(vc))*dx)
>

I expect that this code is not safe. It relies on a particular dof
numbering, which cannot be relied on to remain fixed, and definitely
doesn't hold in parallel.

> and then I can copy this 'small' matrix to the three diagonal slots of
> the 3*3 Laplacian matrix that makes up for the whole velocity
> vectorfield. I understand this is not the regular way of assembling, but
> it is much faster than switching V.sub(0) above to V and assembling the
> whole thing by itself.
>

[Mikael Mortensen (mikael-mortensen)]

I don't know if it's safe, but as for now it works, and for NS it can give you speed-up of more than an order of magnitude. It does not work in parallel of course.

Anyway, just wanted you to know that people are using the subfunction functionality for more than setting boundary conditions:)

[Anders Logg (logg)]

On Mon, Nov 29, 2010 at 09:15:18AM -0000, Mikael Mortensen wrote:
> I don't know if it's safe, but as for now it works, and for NS it can
> give you speed-up of more than an order of magnitude. It does not work
> in parallel of course.
>
> Anyway, just wanted you to know that people are using the subfunction
> functionality for more than setting boundary conditions:)

Would it work just as well (fast) to assemble into a smaller blocks
and them add them together?

--
Anders

[Mikael Mortensen (mikael-mortensen)]

On 29 November 2010 10:46, Anders Logg <email address hidden> wrote:

> On Mon, Nov 29, 2010 at 09:15:18AM -0000, Mikael Mortensen wrote:
> > I don't know if it's safe, but as for now it works, and for NS it can
> > give you speed-up of more than an order of magnitude. It does not work
> > in parallel of course.
> >
> > Anyway, just wanted you to know that people are using the subfunction
> > functionality for more than setting boundary conditions:)
>
> Would it work just as well (fast) to assemble into a smaller blocks
> and them add them together?
>
>
Not quite sure what you mean. The main reason it's much faster componentwise
is that the velocity components are uncoupled and thus the sparsity pattern
on each row is (for 3D flows) 3 times smaller than when assembling the whole
thing. If you could have a way of telling FFC that your velocity components
in the VectorFunctionSpace are uncoupled then you might obtain the same
thing I guess. And you would get rid of a large number of zeros in the
sparse matrix structure.

Mikael

> --
> Anders
>
> --
> Problem using sub-spaces
> https://bugs.launchpad.net/bugs/681415
> You received this bug notification because you are a member of DOLFIN
> Team, which is subscribed to DOLFIN.
>
> Status in DOLFIN: Confirmed
>
> Bug description:
> Hi,
>
> I have trouble using MixedFunctionSpace. Basically I want to project a
> function to a subspace of a MixedFunctionSpace:
>
> from dolfin import *
> mesh=UnitInterval(10)
> U = FunctionSpace(mesh, "CG", 1)
> V = FunctionSpace(mesh, "CG", 1)
> W=U*V
> f1=Function(W.sub(0))
> f1.vector()[:]=1.0
> #f2=project(f1, V) # This works!
> f2=project(f1, W.sub(1)) # This doesn't!
>
>
> The output of that script is attached to the end of this question. Now, the
> confusing thing is that the projection works fine if one projects to V
> instead of W.sub(1), although they are mathematically the same spaces.
>
> I hope I haven't missed a similar question already reported.
>
> Best wishes,
>
> Simon
>
>
> [0]PETSC ERROR:
> ------------------------------------------------------------------------
> [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation,
> probably memory access out of range
> [0]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger
> [0]PETSC ERROR: or see
> http://www.mcs.anl.gov/petsc/petsc-as/documentation/troubleshooting.html#Signal[0]PETSCERROR: or try
> http://valgrind.org on GNU/linux and Apple Mac OS X to find memory
> corruption errors
> [0]PETSC ERROR: configure using --with-debugging=yes, recompile, link, and
> run
> [0]PETSC ERROR: to get more information on the crash.
> [0]PETSC ERROR: --------------------- Error Message
> ------------------------------------
> [0]PETSC ERROR: Signal received!
> [0]PETSC ERROR:
> ------------------------------------------------------------------------
> [0]PETSC ERROR: Petsc Release Version 3.1.0, Patch 3, Fri Jun 4 15:34:52
> CDT 2010
> [0]PETSC ERROR: See docs/changes/index.html for recent updates.
> [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting.
> [0]PETSC ERROR: See docs/index.html for manual pages.
> [0]PETSC ERROR:
> --------------------------...

[Johan Hake (johan-hake)]

On Monday November 29 2010 00:35:27 Mikael Mortensen wrote:
> Please don't.
>
> The subspace functionality is used for example to compute the
> streamfunction, where the subspace of the velocity VectorFunctionSpace
> is used. I also use the subspace functionality to assemble into parts of
> the Navier-Stokes coefficient matrix componentwise. For example
>
> uc = TrialFunction(V.sub(0))
> vc = TestFunction(V.sub(0))
> a = assemble(inner(grad(uc), grad(vc))*dx)
>
> and then I can copy this 'small' matrix to the three diagonal slots of
> the 3*3 Laplacian matrix that makes up for the whole velocity
> vectorfield. I understand this is not the regular way of assembling, but
> it is much faster than switching V.sub(0) above to V and assembling the
> whole thing by itself.

What hinders you to do:

  Vs = FunctionSpace(mesh, "CG", 1)
  V = MixedFunctionSpace([Vs]*3)
  ...
  uc = TrialFunction(Vs)
  vc = TestFunction(Vs)
  a = assemble(inner(grad(uc), grad(vc))*dx)

Johan

[Mikael Mortensen (mikael-mortensen)]

On 29 November 2010 17:06, Johan Hake <email address hidden> wrote:

> On Monday November 29 2010 00:35:27 Mikael Mortensen wrote:
> > Please don't.
> >
> > The subspace functionality is used for example to compute the
> > streamfunction, where the subspace of the velocity VectorFunctionSpace
> > is used. I also use the subspace functionality to assemble into parts of
> > the Navier-Stokes coefficient matrix componentwise. For example
> >
> > uc = TrialFunction(V.sub(0))
> > vc = TestFunction(V.sub(0))
> > a = assemble(inner(grad(uc), grad(vc))*dx)
> >
> > and then I can copy this 'small' matrix to the three diagonal slots of
> > the 3*3 Laplacian matrix that makes up for the whole velocity
> > vectorfield. I understand this is not the regular way of assembling, but
> > it is much faster than switching V.sub(0) above to V and assembling the
> > whole thing by itself.
>
> What hinders you to do:
>
> Vs = FunctionSpace(mesh, "CG", 1)
> V = MixedFunctionSpace([Vs]*3)
> ...
> uc = TrialFunction(Vs)
> vc = TestFunction(Vs)
> a = assemble(inner(grad(uc), grad(vc))*dx)
>

Nothing really. I used to do that. However, I want to be able to grab the
velocity subpace when I'm computing the streamfunction as I want to use the
same functionspace for the streamfunction as a velocity-component to avoid
any interpolation. I understand that it's not strictly necessary, it's just
a nice functionality the way I see it and I can use the same
streamfunction-code for all velocity-functionspaces.

Mikael

>
> Johan
>
> --
> Problem using sub-spaces
> https://bugs.launchpad.net/bugs/681415
> You received this bug notification because you are a member of DOLFIN
> Team, which is subscribed to DOLFIN.
>
> Status in DOLFIN: Confirmed
>
> Bug description:
> Hi,
>
> I have trouble using MixedFunctionSpace. Basically I want to project a
> function to a subspace of a MixedFunctionSpace:
>
> from dolfin import *
> mesh=UnitInterval(10)
> U = FunctionSpace(mesh, "CG", 1)
> V = FunctionSpace(mesh, "CG", 1)
> W=U*V
> f1=Function(W.sub(0))
> f1.vector()[:]=1.0
> #f2=project(f1, V) # This works!
> f2=project(f1, W.sub(1)) # This doesn't!
>
>
> The output of that script is attached to the end of this question. Now, the
> confusing thing is that the projection works fine if one projects to V
> instead of W.sub(1), although they are mathematically the same spaces.
>
> I hope I haven't missed a similar question already reported.
>
> Best wishes,
>
> Simon
>
>
> [0]PETSC ERROR:
> ------------------------------------------------------------------------
> [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation,
> probably memory access out of range
> [0]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger
> [0]PETSC ERROR: or see
> http://www.mcs.anl.gov/petsc/petsc-as/documentation/troubleshooting.html#Signal[0]PETSCERROR: or try
> http://valgrind.org on GNU/linux and Apple Mac OS X to find memory
> corruption errors
> [0]PETSC ERROR: configure using --with-debugging=yes, recompile, link, and
> run
> [0]PETSC ERROR: to get more information on the crash.
> [0]PETSC ERROR: --------------------- Error Message
> ------------...

[Johan Hake (johan-hake)]

On Monday November 29 2010 10:23:43 Mikael Mortensen wrote:
> On 29 November 2010 17:06, Johan Hake <email address hidden> wrote:
> > On Monday November 29 2010 00:35:27 Mikael Mortensen wrote:
> > > Please don't.
> > >
> > > The subspace functionality is used for example to compute the
> > > streamfunction, where the subspace of the velocity VectorFunctionSpace
> > > is used. I also use the subspace functionality to assemble into parts
> > > of the Navier-Stokes coefficient matrix componentwise. For example
> > >
> > > uc = TrialFunction(V.sub(0))
> > > vc = TestFunction(V.sub(0))
> > > a = assemble(inner(grad(uc), grad(vc))*dx)
> > >
> > > and then I can copy this 'small' matrix to the three diagonal slots of
> > > the 3*3 Laplacian matrix that makes up for the whole velocity
> > > vectorfield. I understand this is not the regular way of assembling,
> > > but it is much faster than switching V.sub(0) above to V and
> > > assembling the whole thing by itself.
> >
> > What hinders you to do:
> > Vs = FunctionSpace(mesh, "CG", 1)
> > V = MixedFunctionSpace([Vs]*3)
> > ...
> > uc = TrialFunction(Vs)
> > vc = TestFunction(Vs)
> >
> > a = assemble(inner(grad(uc), grad(vc))*dx)
>
> Nothing really. I used to do that. However, I want to be able to grab the
> velocity subpace when I'm computing the streamfunction as I want to use the
> same functionspace for the streamfunction as a velocity-component to avoid
> any interpolation. I understand that it's not strictly necessary, it's just
> a nice functionality the way I see it and I can use the same
> streamfunction-code for all velocity-functionspaces.

Ok.

What if we keep the original subspaces (without offset) in a protected list.

  _spaces = [Vs0, Vs1, Vs2]

Then we add a kwarg: 'with_offset=True' to the 'sub' method. If 'with_offset'
is False we just return the "original" subspace without offset. You then need
to change your code to:

  uc = TrialFunction(V.sub(0, False))
  vc = TestFunction(V.sub(0, False))
  a = assemble(inner(grad(uc), grad(vc))*dx)

Then we make it impossible to instantiate a Function, TrialFunction,
TestFunction with a FunctionSpace including an offset.

How do I read out from a FunctionSpace that it includes a ufc offset?

This will diverge the C++ and Python implementation more...

Johan

> Mikael
>
> > Johan
> >
> > --
> > Problem using sub-spaces
> > https://bugs.launchpad.net/bugs/681415
> > You received this bug notification because you are a member of DOLFIN
> > Team, which is subscribed to DOLFIN.
> >
> > Status in DOLFIN: Confirmed
> >
> > Bug description:
> > Hi,
> >
> > I have trouble using MixedFunctionSpace. Basically I want to project a
> >
> > function to a subspace of a MixedFunctionSpace:
> > from dolfin import *
> > mesh=UnitInterval(10)
> > U = FunctionSpace(mesh, "CG", 1)
> > V = FunctionSpace(mesh, "CG", 1)
> > W=U*V
> > f1=Function(W.sub(0))
> > f1.vector()[:]=1.0
> > #f2=project(f1, V) # This works!
> > f2=project(f1, W.sub(1)) # This doesn't!
> >
> > The output of that script is attached to the end of this question. Now,
> > the confusing thing is that the projection works fine if one projects to
>...

[Garth Wells (garth-wells)]

On 29/11/10 18:50, Johan Hake wrote:
> On Monday November 29 2010 10:23:43 Mikael Mortensen wrote:
>> On 29 November 2010 17:06, Johan Hake<email address hidden> wrote:
>>> On Monday November 29 2010 00:35:27 Mikael Mortensen wrote:
>>>> Please don't.
>>>>
>>>> The subspace functionality is used for example to compute the
>>>> streamfunction, where the subspace of the velocity VectorFunctionSpace
>>>> is used. I also use the subspace functionality to assemble into parts
>>>> of the Navier-Stokes coefficient matrix componentwise. For example
>>>>
>>>> uc = TrialFunction(V.sub(0))
>>>> vc = TestFunction(V.sub(0))
>>>> a = assemble(inner(grad(uc), grad(vc))*dx)
>>>>
>>>> and then I can copy this 'small' matrix to the three diagonal slots of
>>>> the 3*3 Laplacian matrix that makes up for the whole velocity
>>>> vectorfield. I understand this is not the regular way of assembling,
>>>> but it is much faster than switching V.sub(0) above to V and
>>>> assembling the whole thing by itself.
>>>
>>> What hinders you to do:
>>> Vs = FunctionSpace(mesh, "CG", 1)
>>> V = MixedFunctionSpace([Vs]*3)
>>> ...
>>> uc = TrialFunction(Vs)
>>> vc = TestFunction(Vs)
>>>
>>> a = assemble(inner(grad(uc), grad(vc))*dx)
>>
>> Nothing really. I used to do that. However, I want to be able to grab the
>> velocity subpace when I'm computing the streamfunction as I want to use the
>> same functionspace for the streamfunction as a velocity-component to avoid
>> any interpolation. I understand that it's not strictly necessary, it's just
>> a nice functionality the way I see it and I can use the same
>> streamfunction-code for all velocity-functionspaces.
>
> Ok.
>
> What if we keep the original subspaces (without offset) in a protected
> list.
>
> _spaces = [Vs0, Vs1, Vs2]
>
> Then we add a kwarg: 'with_offset=True' to the 'sub' method. If 'with_offset'
> is False we just return the "original" subspace without offset. You then need
> to change your code to:
>
> uc = TrialFunction(V.sub(0, False))
> vc = TestFunction(V.sub(0, False))
> a = assemble(inner(grad(uc), grad(vc))*dx)
>
> Then we make it impossible to instantiate a Function, TrialFunction,
> TestFunction with a FunctionSpace including an offset.
>
> How do I read out from a FunctionSpace that it includes a ufc offset?
>

I've tried to eliminate 'ufc offsets' in the code - it's a recipe for
disaster with renumbering.

What we want to to know whether we have stand-alone function space or a
view into another space. This can't be checked at the moment. We should
be able to add a member function to FunctionaSpace to do this, but I
need to think about whether or not it will be robust. We could check if
a space is stand-alone or a view in the constructor of a Function.

It would be nice to mirror the design that we have for Function, where
we have deep and shallow copies. The idea would then be that only deep
copies could be used to create Functions.

Garth

> This will diverge the C++ and Python implementation more...
>
> Johan
>
>> Mikael
>>
>>> Johan
>>>
>>> --
>>> Problem using sub-spaces
>>> https://bugs.launchpad.net/bugs/681415
>>> You received this bug notification because ...

[Johan Hake (johan-hake)]

On Monday November 29 2010 11:08:16 Garth Wells wrote:
> On 29/11/10 18:50, Johan Hake wrote:
> > On Monday November 29 2010 10:23:43 Mikael Mortensen wrote:
> >> On 29 November 2010 17:06, Johan Hake<email address hidden> wrote:
> >>> On Monday November 29 2010 00:35:27 Mikael Mortensen wrote:
> >>>> Please don't.
> >>>>
> >>>> The subspace functionality is used for example to compute the
> >>>> streamfunction, where the subspace of the velocity VectorFunctionSpace
> >>>> is used. I also use the subspace functionality to assemble into parts
> >>>> of the Navier-Stokes coefficient matrix componentwise. For example
> >>>>
> >>>> uc = TrialFunction(V.sub(0))
> >>>> vc = TestFunction(V.sub(0))
> >>>> a = assemble(inner(grad(uc), grad(vc))*dx)
> >>>>
> >>>> and then I can copy this 'small' matrix to the three diagonal slots of
> >>>> the 3*3 Laplacian matrix that makes up for the whole velocity
> >>>> vectorfield. I understand this is not the regular way of assembling,
> >>>> but it is much faster than switching V.sub(0) above to V and
> >>>> assembling the whole thing by itself.
> >>>
> >>> What hinders you to do:
> >>> Vs = FunctionSpace(mesh, "CG", 1)
> >>> V = MixedFunctionSpace([Vs]*3)
> >>> ...
> >>> uc = TrialFunction(Vs)
> >>> vc = TestFunction(Vs)
> >>>
> >>> a = assemble(inner(grad(uc), grad(vc))*dx)
> >>
> >> Nothing really. I used to do that. However, I want to be able to grab
> >> the velocity subpace when I'm computing the streamfunction as I want to
> >> use the same functionspace for the streamfunction as a
> >> velocity-component to avoid any interpolation. I understand that it's
> >> not strictly necessary, it's just a nice functionality the way I see it
> >> and I can use the same
> >> streamfunction-code for all velocity-functionspaces.
> >
> > Ok.
> >
> > What if we keep the original subspaces (without offset) in a protected
> > list.
> >
> > _spaces = [Vs0, Vs1, Vs2]
> >
> > Then we add a kwarg: 'with_offset=True' to the 'sub' method. If
> > 'with_offset' is False we just return the "original" subspace without
> > offset. You then need
> >
> > to change your code to:
> > uc = TrialFunction(V.sub(0, False))
> > vc = TestFunction(V.sub(0, False))
> > a = assemble(inner(grad(uc), grad(vc))*dx)
> >
> > Then we make it impossible to instantiate a Function, TrialFunction,
> > TestFunction with a FunctionSpace including an offset.
> >
> > How do I read out from a FunctionSpace that it includes a ufc offset?
>
> I've tried to eliminate 'ufc offsets' in the code - it's a recipe for
> disaster with renumbering.

Ok.

> What we want to to know whether we have stand-alone function space or a
> view into another space. This can't be checked at the moment. We should
> be able to add a member function to FunctionaSpace to do this, but I
> need to think about whether or not it will be robust. We could check if
> a space is stand-alone or a view in the constructor of a Function.

Agree. If such method is exposed to DOLFIN we can then add a check for Test
and Trial-Functions in the PyDOLFIN layer.

> It would be nice to mirror the design that we have for Function, where
> we have deep and shall...

[Anders Logg (logg)]

On Mon, Nov 29, 2010 at 07:08:16PM -0000, Garth Wells wrote:
>
> On 29/11/10 18:50, Johan Hake wrote:
> > On Monday November 29 2010 10:23:43 Mikael Mortensen wrote:
> >> On 29 November 2010 17:06, Johan Hake<email address hidden> wrote:
> >>> On Monday November 29 2010 00:35:27 Mikael Mortensen wrote:
> >>>> Please don't.
> >>>>
> >>>> The subspace functionality is used for example to compute the
> >>>> streamfunction, where the subspace of the velocity VectorFunctionSpace
> >>>> is used. I also use the subspace functionality to assemble into parts
> >>>> of the Navier-Stokes coefficient matrix componentwise. For example
> >>>>
> >>>> uc = TrialFunction(V.sub(0))
> >>>> vc = TestFunction(V.sub(0))
> >>>> a = assemble(inner(grad(uc), grad(vc))*dx)
> >>>>
> >>>> and then I can copy this 'small' matrix to the three diagonal slots of
> >>>> the 3*3 Laplacian matrix that makes up for the whole velocity
> >>>> vectorfield. I understand this is not the regular way of assembling,
> >>>> but it is much faster than switching V.sub(0) above to V and
> >>>> assembling the whole thing by itself.
> >>>
> >>> What hinders you to do:
> >>> Vs = FunctionSpace(mesh, "CG", 1)
> >>> V = MixedFunctionSpace([Vs]*3)
> >>> ...
> >>> uc = TrialFunction(Vs)
> >>> vc = TestFunction(Vs)
> >>>
> >>> a = assemble(inner(grad(uc), grad(vc))*dx)
> >>
> >> Nothing really. I used to do that. However, I want to be able to grab the
> >> velocity subpace when I'm computing the streamfunction as I want to use the
> >> same functionspace for the streamfunction as a velocity-component to avoid
> >> any interpolation. I understand that it's not strictly necessary, it's just
> >> a nice functionality the way I see it and I can use the same
> >> streamfunction-code for all velocity-functionspaces.
> >
> > Ok.
> >
> > What if we keep the original subspaces (without offset) in a protected
> > list.
> >
> > _spaces = [Vs0, Vs1, Vs2]
> >
> > Then we add a kwarg: 'with_offset=True' to the 'sub' method. If 'with_offset'
> > is False we just return the "original" subspace without offset. You then need
> > to change your code to:
> >
> > uc = TrialFunction(V.sub(0, False))
> > vc = TestFunction(V.sub(0, False))
> > a = assemble(inner(grad(uc), grad(vc))*dx)
> >
> > Then we make it impossible to instantiate a Function, TrialFunction,
> > TestFunction with a FunctionSpace including an offset.
> >
> > How do I read out from a FunctionSpace that it includes a ufc offset?
> >
>
> I've tried to eliminate 'ufc offsets' in the code - it's a recipe for
> disaster with renumbering.
>
> What we want to to know whether we have stand-alone function space or a
> view into another space. This can't be checked at the moment. We should
> be able to add a member function to FunctionaSpace to do this, but I
> need to think about whether or not it will be robust. We could check if
> a space is stand-alone or a view in the constructor of a Function.
>
> It would be nice to mirror the design that we have for Function, where
> we have deep and shallow copies. The idea would then be that only deep
> copies could be used to create Functions.
>
> Garth

We had a discussion a while back ...

[Johan Hake (johan-hake)]

On Monday November 29 2010 12:59:55 Anders Logg wrote:
> On Mon, Nov 29, 2010 at 07:08:16PM -0000, Garth Wells wrote:
> > On 29/11/10 18:50, Johan Hake wrote:
> > > On Monday November 29 2010 10:23:43 Mikael Mortensen wrote:
> > >> On 29 November 2010 17:06, Johan Hake<email address hidden>
wrote:
> > >>> On Monday November 29 2010 00:35:27 Mikael Mortensen wrote:
> > >>>> Please don't.
> > >>>>
> > >>>> The subspace functionality is used for example to compute the
> > >>>> streamfunction, where the subspace of the velocity
> > >>>> VectorFunctionSpace is used. I also use the subspace functionality
> > >>>> to assemble into parts of the Navier-Stokes coefficient matrix
> > >>>> componentwise. For example
> > >>>>
> > >>>> uc = TrialFunction(V.sub(0))
> > >>>> vc = TestFunction(V.sub(0))
> > >>>> a = assemble(inner(grad(uc), grad(vc))*dx)
> > >>>>
> > >>>> and then I can copy this 'small' matrix to the three diagonal slots
> > >>>> of the 3*3 Laplacian matrix that makes up for the whole velocity
> > >>>> vectorfield. I understand this is not the regular way of
> > >>>> assembling, but it is much faster than switching V.sub(0) above to
> > >>>> V and assembling the whole thing by itself.
> > >>>
> > >>> What hinders you to do:
> > >>> Vs = FunctionSpace(mesh, "CG", 1)
> > >>> V = MixedFunctionSpace([Vs]*3)
> > >>> ...
> > >>> uc = TrialFunction(Vs)
> > >>> vc = TestFunction(Vs)
> > >>>
> > >>> a = assemble(inner(grad(uc), grad(vc))*dx)
> > >>
> > >> Nothing really. I used to do that. However, I want to be able to grab
> > >> the velocity subpace when I'm computing the streamfunction as I want
> > >> to use the same functionspace for the streamfunction as a
> > >> velocity-component to avoid any interpolation. I understand that it's
> > >> not strictly necessary, it's just a nice functionality the way I see
> > >> it and I can use the same
> > >> streamfunction-code for all velocity-functionspaces.
> > >
> > > Ok.
> > >
> > > What if we keep the original subspaces (without offset) in a protected
> > > list.
> > >
> > > _spaces = [Vs0, Vs1, Vs2]
> > >
> > > Then we add a kwarg: 'with_offset=True' to the 'sub' method. If
> > > 'with_offset' is False we just return the "original" subspace without
> > > offset. You then need
> > >
> > > to change your code to:
> > > uc = TrialFunction(V.sub(0, False))
> > > vc = TestFunction(V.sub(0, False))
> > > a = assemble(inner(grad(uc), grad(vc))*dx)
> > >
> > > Then we make it impossible to instantiate a Function, TrialFunction,
> > > TestFunction with a FunctionSpace including an offset.
> > >
> > > How do I read out from a FunctionSpace that it includes a ufc offset?
> >
> > I've tried to eliminate 'ufc offsets' in the code - it's a recipe for
> > disaster with renumbering.
> >
> > What we want to to know whether we have stand-alone function space or a
> > view into another space. This can't be checked at the moment. We should
> > be able to add a member function to FunctionaSpace to do this, but I
> > need to think about whether or not it will be robust. We could check if
> > a space is stand-alone or a view in the constructor of a Function.
> >
> > It wou...

[Anders Logg (logg)]

On Mon, Nov 29, 2010 at 09:13:11PM -0000, Johan Hake wrote:
> On Monday November 29 2010 12:59:55 Anders Logg wrote:
> > On Mon, Nov 29, 2010 at 07:08:16PM -0000, Garth Wells wrote:
> > > On 29/11/10 18:50, Johan Hake wrote:
> > > > On Monday November 29 2010 10:23:43 Mikael Mortensen wrote:
> > > >> On 29 November 2010 17:06, Johan Hake<email address hidden>
> wrote:
> > > >>> On Monday November 29 2010 00:35:27 Mikael Mortensen wrote:
> > > >>>> Please don't.
> > > >>>>
> > > >>>> The subspace functionality is used for example to compute the
> > > >>>> streamfunction, where the subspace of the velocity
> > > >>>> VectorFunctionSpace is used. I also use the subspace functionality
> > > >>>> to assemble into parts of the Navier-Stokes coefficient matrix
> > > >>>> componentwise. For example
> > > >>>>
> > > >>>> uc = TrialFunction(V.sub(0))
> > > >>>> vc = TestFunction(V.sub(0))
> > > >>>> a = assemble(inner(grad(uc), grad(vc))*dx)
> > > >>>>
> > > >>>> and then I can copy this 'small' matrix to the three diagonal slots
> > > >>>> of the 3*3 Laplacian matrix that makes up for the whole velocity
> > > >>>> vectorfield. I understand this is not the regular way of
> > > >>>> assembling, but it is much faster than switching V.sub(0) above to
> > > >>>> V and assembling the whole thing by itself.
> > > >>>
> > > >>> What hinders you to do:
> > > >>> Vs = FunctionSpace(mesh, "CG", 1)
> > > >>> V = MixedFunctionSpace([Vs]*3)
> > > >>> ...
> > > >>> uc = TrialFunction(Vs)
> > > >>> vc = TestFunction(Vs)
> > > >>>
> > > >>> a = assemble(inner(grad(uc), grad(vc))*dx)
> > > >>
> > > >> Nothing really. I used to do that. However, I want to be able to grab
> > > >> the velocity subpace when I'm computing the streamfunction as I want
> > > >> to use the same functionspace for the streamfunction as a
> > > >> velocity-component to avoid any interpolation. I understand that it's
> > > >> not strictly necessary, it's just a nice functionality the way I see
> > > >> it and I can use the same
> > > >> streamfunction-code for all velocity-functionspaces.
> > > >
> > > > Ok.
> > > >
> > > > What if we keep the original subspaces (without offset) in a protected
> > > > list.
> > > >
> > > > _spaces = [Vs0, Vs1, Vs2]
> > > >
> > > > Then we add a kwarg: 'with_offset=True' to the 'sub' method. If
> > > > 'with_offset' is False we just return the "original" subspace without
> > > > offset. You then need
> > > >
> > > > to change your code to:
> > > > uc = TrialFunction(V.sub(0, False))
> > > > vc = TestFunction(V.sub(0, False))
> > > > a = assemble(inner(grad(uc), grad(vc))*dx)
> > > >
> > > > Then we make it impossible to instantiate a Function, TrialFunction,
> > > > TestFunction with a FunctionSpace including an offset.
> > > >
> > > > How do I read out from a FunctionSpace that it includes a ufc offset?
> > >
> > > I've tried to eliminate 'ufc offsets' in the code - it's a recipe for
> > > disaster with renumbering.
> > >
> > > What we want to to know whether we have stand-alone function space or a
> > > view into another space. This can't be checked at the moment. We should
> > > be able to add a member function to FunctionaSpace t...

[Johan Hake (johan-hake)]

On Monday November 29 2010 14:39:33 Anders Logg wrote:
> On Mon, Nov 29, 2010 at 09:13:11PM -0000, Johan Hake wrote:
> > On Monday November 29 2010 12:59:55 Anders Logg wrote:
> > > On Mon, Nov 29, 2010 at 07:08:16PM -0000, Garth Wells wrote:
> > > > On 29/11/10 18:50, Johan Hake wrote:
> > > > > On Monday November 29 2010 10:23:43 Mikael Mortensen wrote:
> > > > >> On 29 November 2010 17:06, Johan Hake<email address hidden>
> >
> > wrote:
> > > > >>> On Monday November 29 2010 00:35:27 Mikael Mortensen wrote:
> > > > >>>> Please don't.
> > > > >>>>
> > > > >>>> The subspace functionality is used for example to compute the
> > > > >>>> streamfunction, where the subspace of the velocity
> > > > >>>> VectorFunctionSpace is used. I also use the subspace
> > > > >>>> functionality to assemble into parts of the Navier-Stokes
> > > > >>>> coefficient matrix componentwise. For example
> > > > >>>>
> > > > >>>> uc = TrialFunction(V.sub(0))
> > > > >>>> vc = TestFunction(V.sub(0))
> > > > >>>> a = assemble(inner(grad(uc), grad(vc))*dx)
> > > > >>>>
> > > > >>>> and then I can copy this 'small' matrix to the three diagonal
> > > > >>>> slots of the 3*3 Laplacian matrix that makes up for the whole
> > > > >>>> velocity vectorfield. I understand this is not the regular way
> > > > >>>> of assembling, but it is much faster than switching V.sub(0)
> > > > >>>> above to V and assembling the whole thing by itself.
> > > > >>>
> > > > >>> What hinders you to do:
> > > > >>> Vs = FunctionSpace(mesh, "CG", 1)
> > > > >>> V = MixedFunctionSpace([Vs]*3)
> > > > >>> ...
> > > > >>> uc = TrialFunction(Vs)
> > > > >>> vc = TestFunction(Vs)
> > > > >>>
> > > > >>> a = assemble(inner(grad(uc), grad(vc))*dx)
> > > > >>
> > > > >> Nothing really. I used to do that. However, I want to be able to
> > > > >> grab the velocity subpace when I'm computing the streamfunction
> > > > >> as I want to use the same functionspace for the streamfunction as
> > > > >> a velocity-component to avoid any interpolation. I understand
> > > > >> that it's not strictly necessary, it's just a nice functionality
> > > > >> the way I see it and I can use the same
> > > > >> streamfunction-code for all velocity-functionspaces.
> > > > >
> > > > > Ok.
> > > > >
> > > > > What if we keep the original subspaces (without offset) in a
> > > > > protected list.
> > > > >
> > > > > _spaces = [Vs0, Vs1, Vs2]
> > > > >
> > > > > Then we add a kwarg: 'with_offset=True' to the 'sub' method. If
> > > > > 'with_offset' is False we just return the "original" subspace
> > > > > without offset. You then need
> > > > >
> > > > > to change your code to:
> > > > > uc = TrialFunction(V.sub(0, False))
> > > > > vc = TestFunction(V.sub(0, False))
> > > > > a = assemble(inner(grad(uc), grad(vc))*dx)
> > > > >
> > > > > Then we make it impossible to instantiate a Function,
> > > > > TrialFunction, TestFunction with a FunctionSpace including an
> > > > > offset.
> > > > >
> > > > > How do I read out from a FunctionSpace that it includes a ufc
> > > > > offset?
> > > >
> > > > I've tried to eliminate 'ufc offsets' in the code - it's a recipe for
> > > > disaster with renum...

[Garth Wells (garth-wells)]

On 29/11/10 22:51, Johan Hake wrote:
> On Monday November 29 2010 14:39:33 Anders Logg wrote:
>> On Mon, Nov 29, 2010 at 09:13:11PM -0000, Johan Hake wrote:
>>> On Monday November 29 2010 12:59:55 Anders Logg wrote:
>>>> On Mon, Nov 29, 2010 at 07:08:16PM -0000, Garth Wells wrote:
>>>>> On 29/11/10 18:50, Johan Hake wrote:
>>>>>> On Monday November 29 2010 10:23:43 Mikael Mortensen wrote:
>>>>>>> On 29 November 2010 17:06, Johan Hake<email address hidden>
>>>
>>> wrote:
>>>>>>>> On Monday November 29 2010 00:35:27 Mikael Mortensen wrote:
>>>>>>>>> Please don't.
>>>>>>>>>
>>>>>>>>> The subspace functionality is used for example to compute the
>>>>>>>>> streamfunction, where the subspace of the velocity
>>>>>>>>> VectorFunctionSpace is used. I also use the subspace
>>>>>>>>> functionality to assemble into parts of the Navier-Stokes
>>>>>>>>> coefficient matrix componentwise. For example
>>>>>>>>>
>>>>>>>>> uc = TrialFunction(V.sub(0))
>>>>>>>>> vc = TestFunction(V.sub(0))
>>>>>>>>> a = assemble(inner(grad(uc), grad(vc))*dx)
>>>>>>>>>
>>>>>>>>> and then I can copy this 'small' matrix to the three diagonal
>>>>>>>>> slots of the 3*3 Laplacian matrix that makes up for the whole
>>>>>>>>> velocity vectorfield. I understand this is not the regular way
>>>>>>>>> of assembling, but it is much faster than switching V.sub(0)
>>>>>>>>> above to V and assembling the whole thing by itself.
>>>>>>>>
>>>>>>>> What hinders you to do:
>>>>>>>> Vs = FunctionSpace(mesh, "CG", 1)
>>>>>>>> V = MixedFunctionSpace([Vs]*3)
>>>>>>>> ...
>>>>>>>> uc = TrialFunction(Vs)
>>>>>>>> vc = TestFunction(Vs)
>>>>>>>>
>>>>>>>> a = assemble(inner(grad(uc), grad(vc))*dx)
>>>>>>>
>>>>>>> Nothing really. I used to do that. However, I want to be able to
>>>>>>> grab the velocity subpace when I'm computing the streamfunction
>>>>>>> as I want to use the same functionspace for the streamfunction as
>>>>>>> a velocity-component to avoid any interpolation. I understand
>>>>>>> that it's not strictly necessary, it's just a nice functionality
>>>>>>> the way I see it and I can use the same
>>>>>>> streamfunction-code for all velocity-functionspaces.
>>>>>>
>>>>>> Ok.
>>>>>>
>>>>>> What if we keep the original subspaces (without offset) in a
>>>>>> protected list.
>>>>>>
>>>>>> _spaces = [Vs0, Vs1, Vs2]
>>>>>>
>>>>>> Then we add a kwarg: 'with_offset=True' to the 'sub' method. If
>>>>>> 'with_offset' is False we just return the "original" subspace
>>>>>> without offset. You then need
>>>>>>
>>>>>> to change your code to:
>>>>>> uc = TrialFunction(V.sub(0, False))
>>>>>> vc = TestFunction(V.sub(0, False))
>>>>>> a = assemble(inner(grad(uc), grad(vc))*dx)
>>>>>>
>>>>>> Then we make it impossible to instantiate a Function,
>>>>>> TrialFunction, TestFunction with a FunctionSpace including an
>>>>>> offset.
>>>>>>
>>>>>> How do I read out from a FunctionSpace that it includes a ufc
>>>>>> offset?
>>>>>
>>>>> I've tried to eliminate 'ufc offsets' in the code - it's a recipe for
>>>>> disaster with renumbering.
>>>>>
>>>>> What we want to to know whether we have stand-alone function space or
>>>>> a view into another space. This can't be checked at the mo...

[Anders Logg (logg)]

On Tue, Nov 30, 2010 at 09:57:42AM -0000, Garth Wells wrote:
>
> On 29/11/10 22:51, Johan Hake wrote:
> > On Monday November 29 2010 14:39:33 Anders Logg wrote:
> >> On Mon, Nov 29, 2010 at 09:13:11PM -0000, Johan Hake wrote:
> >>> On Monday November 29 2010 12:59:55 Anders Logg wrote:
> >>>> On Mon, Nov 29, 2010 at 07:08:16PM -0000, Garth Wells wrote:
> >>>>> On 29/11/10 18:50, Johan Hake wrote:
> >>>>>> On Monday November 29 2010 10:23:43 Mikael Mortensen wrote:
> >>>>>>> On 29 November 2010 17:06, Johan Hake<email address hidden>
> >>>
> >>> wrote:
> >>>>>>>> On Monday November 29 2010 00:35:27 Mikael Mortensen wrote:
> >>>>>>>>> Please don't.
> >>>>>>>>>
> >>>>>>>>> The subspace functionality is used for example to compute the
> >>>>>>>>> streamfunction, where the subspace of the velocity
> >>>>>>>>> VectorFunctionSpace is used. I also use the subspace
> >>>>>>>>> functionality to assemble into parts of the Navier-Stokes
> >>>>>>>>> coefficient matrix componentwise. For example
> >>>>>>>>>
> >>>>>>>>> uc = TrialFunction(V.sub(0))
> >>>>>>>>> vc = TestFunction(V.sub(0))
> >>>>>>>>> a = assemble(inner(grad(uc), grad(vc))*dx)
> >>>>>>>>>
> >>>>>>>>> and then I can copy this 'small' matrix to the three diagonal
> >>>>>>>>> slots of the 3*3 Laplacian matrix that makes up for the whole
> >>>>>>>>> velocity vectorfield. I understand this is not the regular way
> >>>>>>>>> of assembling, but it is much faster than switching V.sub(0)
> >>>>>>>>> above to V and assembling the whole thing by itself.
> >>>>>>>>
> >>>>>>>> What hinders you to do:
> >>>>>>>> Vs = FunctionSpace(mesh, "CG", 1)
> >>>>>>>> V = MixedFunctionSpace([Vs]*3)
> >>>>>>>> ...
> >>>>>>>> uc = TrialFunction(Vs)
> >>>>>>>> vc = TestFunction(Vs)
> >>>>>>>>
> >>>>>>>> a = assemble(inner(grad(uc), grad(vc))*dx)
> >>>>>>>
> >>>>>>> Nothing really. I used to do that. However, I want to be able to
> >>>>>>> grab the velocity subpace when I'm computing the streamfunction
> >>>>>>> as I want to use the same functionspace for the streamfunction as
> >>>>>>> a velocity-component to avoid any interpolation. I understand
> >>>>>>> that it's not strictly necessary, it's just a nice functionality
> >>>>>>> the way I see it and I can use the same
> >>>>>>> streamfunction-code for all velocity-functionspaces.
> >>>>>>
> >>>>>> Ok.
> >>>>>>
> >>>>>> What if we keep the original subspaces (without offset) in a
> >>>>>> protected list.
> >>>>>>
> >>>>>> _spaces = [Vs0, Vs1, Vs2]
> >>>>>>
> >>>>>> Then we add a kwarg: 'with_offset=True' to the 'sub' method. If
> >>>>>> 'with_offset' is False we just return the "original" subspace
> >>>>>> without offset. You then need
> >>>>>>
> >>>>>> to change your code to:
> >>>>>> uc = TrialFunction(V.sub(0, False))
> >>>>>> vc = TestFunction(V.sub(0, False))
> >>>>>> a = assemble(inner(grad(uc), grad(vc))*dx)
> >>>>>>
> >>>>>> Then we make it impossible to instantiate a Function,
> >>>>>> TrialFunction, TestFunction with a FunctionSpace including an
> >>>>>> offset.
> >>>>>>
> >>>>>> How do I read out from a FunctionSpace that it includes a ufc
> >>>>>> offset?
> >>>>>
> >>>>> I've tried to eliminate 'ufc offsets' in the cod...

[Johan Hake (johan-hake)]

On Tuesday November 30 2010 01:57:42 Garth Wells wrote:
> On 29/11/10 22:51, Johan Hake wrote:
> > On Monday November 29 2010 14:39:33 Anders Logg wrote:
> >> On Mon, Nov 29, 2010 at 09:13:11PM -0000, Johan Hake wrote:
> >>> On Monday November 29 2010 12:59:55 Anders Logg wrote:
> >>>> On Mon, Nov 29, 2010 at 07:08:16PM -0000, Garth Wells wrote:
> >>>>> On 29/11/10 18:50, Johan Hake wrote:
> >>>>>> On Monday November 29 2010 10:23:43 Mikael Mortensen wrote:
> >>>>>>> On 29 November 2010 17:06, Johan Hake<email address hidden>
> >>>
> >>> wrote:
> >>>>>>>> On Monday November 29 2010 00:35:27 Mikael Mortensen wrote:
> >>>>>>>>> Please don't.
> >>>>>>>>>
> >>>>>>>>> The subspace functionality is used for example to compute the
> >>>>>>>>> streamfunction, where the subspace of the velocity
> >>>>>>>>> VectorFunctionSpace is used. I also use the subspace
> >>>>>>>>> functionality to assemble into parts of the Navier-Stokes
> >>>>>>>>> coefficient matrix componentwise. For example
> >>>>>>>>>
> >>>>>>>>> uc = TrialFunction(V.sub(0))
> >>>>>>>>> vc = TestFunction(V.sub(0))
> >>>>>>>>> a = assemble(inner(grad(uc), grad(vc))*dx)
> >>>>>>>>>
> >>>>>>>>> and then I can copy this 'small' matrix to the three diagonal
> >>>>>>>>> slots of the 3*3 Laplacian matrix that makes up for the whole
> >>>>>>>>> velocity vectorfield. I understand this is not the regular way
> >>>>>>>>> of assembling, but it is much faster than switching V.sub(0)
> >>>>>>>>> above to V and assembling the whole thing by itself.
> >>>>>>>>
> >>>>>>>> What hinders you to do:
> >>>>>>>> Vs = FunctionSpace(mesh, "CG", 1)
> >>>>>>>> V = MixedFunctionSpace([Vs]*3)
> >>>>>>>> ...
> >>>>>>>> uc = TrialFunction(Vs)
> >>>>>>>> vc = TestFunction(Vs)
> >>>>>>>>
> >>>>>>>> a = assemble(inner(grad(uc), grad(vc))*dx)
> >>>>>>>
> >>>>>>> Nothing really. I used to do that. However, I want to be able to
> >>>>>>> grab the velocity subpace when I'm computing the streamfunction
> >>>>>>> as I want to use the same functionspace for the streamfunction as
> >>>>>>> a velocity-component to avoid any interpolation. I understand
> >>>>>>> that it's not strictly necessary, it's just a nice functionality
> >>>>>>> the way I see it and I can use the same
> >>>>>>> streamfunction-code for all velocity-functionspaces.
> >>>>>>
> >>>>>> Ok.
> >>>>>>
> >>>>>> What if we keep the original subspaces (without offset) in a
> >>>>>> protected list.
> >>>>>>
> >>>>>> _spaces = [Vs0, Vs1, Vs2]
> >>>>>>
> >>>>>> Then we add a kwarg: 'with_offset=True' to the 'sub' method. If
> >>>>>> 'with_offset' is False we just return the "original" subspace
> >>>>>> without offset. You then need
> >>>>>>
> >>>>>> to change your code to:
> >>>>>> uc = TrialFunction(V.sub(0, False))
> >>>>>> vc = TestFunction(V.sub(0, False))
> >>>>>> a = assemble(inner(grad(uc), grad(vc))*dx)
> >>>>>>
> >>>>>> Then we make it impossible to instantiate a Function,
> >>>>>> TrialFunction, TestFunction with a FunctionSpace including an
> >>>>>> offset.
> >>>>>>
> >>>>>> How do I read out from a FunctionSpace that it includes a ufc
> >>>>>> offset?
> >>>>>
> >>>>> I've tried to eliminate 'ufc offsets'...

[Johan Hake (johan-hake)]

I try to summarize:

  * We need to prohibit generation of Functions using SubSpace which includes an offset into MixedSpace
  * We add possibilities to generate a deep copy of a SubSpace a la SubFunction, which returns a full fledged FunctionSpace
  * We need a way to know whether a FunctionSpace is a SubSpace with offset. Maybe add an is_view method to FunctionSpace?
  * Addition to be made:
         1) Add functionality for generating a deep copy of a SubSpace
         2) Add functionality to know whether a FunctionSpace is a view of an other.
         3) Mirror this in the Python interface so one can do:

                Vs = V.sub(0, True/False)

             To get a SubSpace

If we agree on this I can implement 3) but need inputs on 1) and 2).

[Garth Wells (garth-wells)]

This is also a C++ issue, so should be addressed from that side. A solution that I thought of a while a ago is to introduce an abstract base class

  GenericFunctionSpace

and make FunctionSpace and SubSpace sub-classes of GenericFunctionSpace. We would the require a FunctionSpace when creating a Function. For boundary conditions, we can use a GenericFunctionSpace. At the moment, SubSpace is a sub-class of FunctionSpace, and this is a cause of difficulty. We can make it possible to create a FunctionSpace from a SubSpace, which would basically collapse the dofmap.

[Anders Logg (logg)]

On Mon, Mar 21, 2011 at 07:42:21PM -0000, Garth Wells wrote:
> This is also a C++ issue, so should be addressed from that side. A
> solution that I thought of a while a ago is to introduce an abstract
> base class
>
> GenericFunctionSpace
>
> and make FunctionSpace and SubSpace sub-classes of GenericFunctionSpace.
> We would the require a FunctionSpace when creating a Function. For
> boundary conditions, we can use a GenericFunctionSpace. At the moment,
> SubSpace is a sub-class of FunctionSpace, and this is a cause of
> difficulty. We can make it possible to create a FunctionSpace from a
> SubSpace, which would basically collapse the dofmap.

I think that sounds very good. Similar issues as we had before when
the Function class tried to be many things at once (like we can't get
the vector of a subspace but we can for a function space).

--
Anders

[Johan Hake (johan-hake)]

On Monday March 21 2011 13:50:54 Anders Logg wrote:
> On Mon, Mar 21, 2011 at 07:42:21PM -0000, Garth Wells wrote:
> > This is also a C++ issue, so should be addressed from that side. A
> > solution that I thought of a while a ago is to introduce an abstract
> > base class
> >
> > GenericFunctionSpace
> >
> > and make FunctionSpace and SubSpace sub-classes of GenericFunctionSpace.
> > We would the require a FunctionSpace when creating a Function. For
> > boundary conditions, we can use a GenericFunctionSpace. At the moment,
> > SubSpace is a sub-class of FunctionSpace, and this is a cause of
> > difficulty. We can make it possible to create a FunctionSpace from a
> > SubSpace, which would basically collapse the dofmap.
>
> I think that sounds very good. Similar issues as we had before when
> the Function class tried to be many things at once (like we can't get
> the vector of a subspace but we can for a function space).

Sure, but couldn't this be handled without creating a GenericFunctionSpace.
Just feels a bit overkill, when it might be handled with the present interface
with some added suger.

Johan

[Garth Wells (garth-wells)]

On 22/03/11 05:52, Johan Hake wrote:
> On Monday March 21 2011 13:50:54 Anders Logg wrote:
>> On Mon, Mar 21, 2011 at 07:42:21PM -0000, Garth Wells wrote:
>>> This is also a C++ issue, so should be addressed from that side. A
>>> solution that I thought of a while a ago is to introduce an abstract
>>> base class
>>>
>>> GenericFunctionSpace
>>>
>>> and make FunctionSpace and SubSpace sub-classes of GenericFunctionSpace.
>>> We would the require a FunctionSpace when creating a Function. For
>>> boundary conditions, we can use a GenericFunctionSpace. At the moment,
>>> SubSpace is a sub-class of FunctionSpace, and this is a cause of
>>> difficulty. We can make it possible to create a FunctionSpace from a
>>> SubSpace, which would basically collapse the dofmap.
>>
>> I think that sounds very good. Similar issues as we had before when
>> the Function class tried to be many things at once (like we can't get
>> the vector of a subspace but we can for a function space).
>
> Sure, but couldn't this be handled without creating a GenericFunctionSpace.
> Just feels a bit overkill, when it might be handled with the present interface
> with some added suger.
>

sugar -> 'hack' ;)

I think that a GenericFunctionSpace would ultimately be the simplest and
most robust solution. As Anders wrote, we've gotten into trouble in the
past by having the function classes be 'more than one thing'.

Garth

> Johan
>

[Marie Rognes (meg-simula)]

On 03/21/2011 08:42 PM, Garth Wells wrote:
> This is also a C++ issue, so should be addressed from that side. A
> solution that I thought of a while a ago is to introduce an abstract
> base class
>
> GenericFunctionSpace
>
> and make FunctionSpace and SubSpace sub-classes of GenericFunctionSpace.
> We would the require a FunctionSpace when creating a Function. For
> boundary conditions, we can use a GenericFunctionSpace. At the moment,
> SubSpace is a sub-class of FunctionSpace, and this is a cause of
> difficulty. We can make it possible to create a FunctionSpace from a
> SubSpace, which would basically collapse the dofmap.
>

I agree that some revamping of the SubSpace notion would be good. I'm
not quite sure whether I understand which mathematical abstraction
GenericFunctionSpace would represent. (Same goes for current SubSpace
class.)

Could we take one more thinking-step back: Are the current SubSpaces
used for anything else than DirichletBC?

--
Marie

[Garth Wells (garth-wells)]

On 22/03/11 10:25, Marie Rognes wrote:
> On 03/21/2011 08:42 PM, Garth Wells wrote:
>> This is also a C++ issue, so should be addressed from that side. A
>> solution that I thought of a while a ago is to introduce an abstract
>> base class
>>
>> GenericFunctionSpace
>>
>> and make FunctionSpace and SubSpace sub-classes of GenericFunctionSpace.
>> We would the require a FunctionSpace when creating a Function. For
>> boundary conditions, we can use a GenericFunctionSpace. At the moment,
>> SubSpace is a sub-class of FunctionSpace, and this is a cause of
>> difficulty. We can make it possible to create a FunctionSpace from a
>> SubSpace, which would basically collapse the dofmap.
>>
>
> I agree that some revamping of the SubSpace notion would be good. I'm
> not quite sure whether I understand which mathematical abstraction
> GenericFunctionSpace would represent. (Same goes for current SubSpace
> class.)
>

A GenericFunctionSpace would represent the same mathematical abstraction
as what we now have with FunctionSpace, but it would leave details of
the dofmap to the sub-classes. A FunctionSpace would have a complete
dofmap, and a SubSpace would provide a view into a dofmap.

> Could we take one more thinking-step back: Are the current SubSpaces
> used for anything else than DirichletBC?
>

Technically, SubSpaces are not used anywhere because they're
FunctionSpaces, which is part of the problem. If we have a SubSpace
class that is not a sub-class of FunctionSpace, there are some places
where it should be used, e.g. in

  FunctionSpace::extract_sub_space(....)

Garth

> --
> Marie
>

[Johan Hake (johan-hake)]

On Tuesday March 22 2011 00:45:01 Garth Wells wrote:
> On 22/03/11 05:52, Johan Hake wrote:
> > On Monday March 21 2011 13:50:54 Anders Logg wrote:
> >> On Mon, Mar 21, 2011 at 07:42:21PM -0000, Garth Wells wrote:
> >>> This is also a C++ issue, so should be addressed from that side. A
> >>> solution that I thought of a while a ago is to introduce an abstract
> >>> base class
> >>>
> >>> GenericFunctionSpace
> >>>
> >>> and make FunctionSpace and SubSpace sub-classes of
> >>> GenericFunctionSpace. We would the require a FunctionSpace when
> >>> creating a Function. For boundary conditions, we can use a
> >>> GenericFunctionSpace. At the moment, SubSpace is a sub-class of
> >>> FunctionSpace, and this is a cause of difficulty. We can make it
> >>> possible to create a FunctionSpace from a SubSpace, which would
> >>> basically collapse the dofmap.
> >>
> >> I think that sounds very good. Similar issues as we had before when
> >> the Function class tried to be many things at once (like we can't get
> >> the vector of a subspace but we can for a function space).
> >
> > Sure, but couldn't this be handled without creating a
> > GenericFunctionSpace. Just feels a bit overkill, when it might be
> > handled with the present interface with some added suger.
>
> sugar -> 'hack' ;)

Sure, but not nessesary. If we stick to the Function analogy, we have one
class which handles both cases, i) a full fledged Function or ii) a view into
another Function.

> I think that a GenericFunctionSpace would ultimately be the simplest and
> most robust solution.

Ok, but then we might need more time than to the next release for this bug,
and I might shift assigne to you ;)

Johan

> As Anders wrote, we've gotten into trouble in the
> past by having the function classes be 'more than one thing'.
>
> Garth
>
> > Johan

[Garth Wells (garth-wells)]

This has been 'fixed' in a simple way; an error is thrown when attempted top create a Function from a subspace. The error suggests collapsing the subspace.

Collapsing doesn't work from Python because it return a C++ FunctionSpace rather than a Python DOLFIN/UFL function space.