Re: [Getfem-users] Reduction problems

[Torquil Macdonald Sørensen]

Hi Yves!

Unfortunately, I'm still having a problem with this. Perhaps it is because I'm 
unsure how to define the extension matrix, which is ambiguous when the number of 
degrees of freedom is reduced.

I have now defined a reduced basis that preserves the partition of unity 
property, and which is also able to exactly represent any affine function.

I started with Q_2 on the square, and defined a reduced basis by using the two 
linear combinations

\hat{phi}_{21} + 0.5\hat{phi}_{22}
0.5\hat{phi}_{22} + \hat{phi}_{23}

instead of the three \hat{phi}_{21}, \hat{phi}_{22}, \hat{phi}_{23}. Of course, 
the other 6 basis functions with first index i != 2 are included in the reduced 
basis. So I have reduced from 9 basis functions to 8, within each square.

I'm using the notation of the the section "Classical Lagrange elements on other 
geometries" on the page

http://download.gna.org/getfem/html/homepage/userdoc/appendixA.html

Thus the reduction matrix R is defined, and I then choose an extension matrix E 
so that R*E=Id.

However, as before the solution vanishes everywhere except on the boundary, 
where it is of course fixed by the Dirichlet condition.

Perhaps there are some further important requirements on the definition of E 
other than just R*E=Id, that I am currently violating, which is not mentioned in 
the documentation? I have noticed in a different program that the calculation 
result is strongly dependent on E, even though R*E=Id in both all cases.

Are there any working examples available of the use of reduction with getfem 
that I could study?

Thanks!
Torquil

On 16/07/12 16:37, Yves Renard wrote:
> Dear Torquil,
>
>
> The resulting finite element space when you supress the dof
> corresponding to  intermediate points is not a partition of unity. So,
> it is not able to approximate the constants. Consequently, I think, it
> is normal that the solution is not well approximated. You have at least
> to care that your reduction produces a finite element space which
> reproduces the polynomial of degree less or equal to 1 to have a good
> approximation.
>
>
> Yves.
>
>
> Le 15/07/2012 15:56, Torquil Macdonald Sørensen a écrit :
> > Hi!
> >
> > I've started with the tests/laplacian.cc program, modified it a bit,
> > and implemented an example reduction scheme. But whenever I use
> > reduction, the solution is identical to zero apart from on the
> > boundary, where I use Dirichlet conditions. In addition, I've also
> > tried an approach using the Laplacian model, with the same incorrect
> > results.
> >
> > In more detail, I have a square 2d domain and the mesh is:
> >
> > getfem::regular_unit_mesh(mesh, ref, bgeot::parallelepiped_geotrans(2,
> > 1));
> >
> > On this mesh, I'm using FEM_QK(2,2) for both parts of the equation,
> > and IM_GAUSS_PARALLELEPIPED(2,k) for k=3, but I've also tried k=4 and 5.
> >
> > The reduction scheme consists of using only the DOFs at the corners of
> > the squares, and not the DOFs at the intermediate points along the
> > edges or the central point of the square. I thought I'd try this as a
> > simple example of reduction. The extention matrix E is the transpose
> > of the reduction matrix R, and I do test that R*E is the identity, so
> > that part should be OK.
> >
> > When using reduction, I make sure to use the "general Dirichlet"
> > method in laplacian.cc, since the simplified approach won't work in
> > that case.
> >
> > The program runs fine without error messages with and without
> > reduction enabled, but as I mentioned, the solution is incorrect when
> > using reduction (zero everywhere apart from the boundary).
> >
> > Any ideas about why this is so? Perhaps my reduction scheme is
> > mathematically invalid for some reason, there is some bug in
> > connection with reduction, or I've done something wrong?
> >
> > Best regards,
> > Torquil Sørensen
> >
> >
> > _______________________________________________
> > Getfem-users mailing list
> > address@hidden
> > https://mail.gna.org/listinfo/getfem-users