dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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<681415@xxxxxxxxxxxxxxxxxx>
> 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 about adding a member function that
> > could be used to compare the size (as in the number of dofs) of the
> > subspace (sub dofmap) with the size of the bigger space. Maybe that
> > could be a solution.
>
> That sounds usefull. But I cannot see how that can be used to check wether a
> FunctionSpace is a subspace (with offset) of another one.

It could if the subspace returned another value (the number of dofs)
which was smaller than the whole space.

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