getfem-users
[Top][All Lists]

## Re: [Getfem-users] Reduction problems

 From: Torquil Macdonald Sørensen Subject: Re: [Getfem-users] Reduction problems Date: Sat, 11 Aug 2012 19:58:09 +0200 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6

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



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
https://mail.gna.org/listinfo/getfem-users








reply via email to