[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Getfem-users] Number of dofs and number of points

From: Giovani
Subject: Re: [Getfem-users] Number of dofs and number of points
Date: Mon, 09 Jul 2007 12:46:35 -0300
User-agent: Thunderbird (X11/20070705)


Thank you very much! I'll try the solution!

There's another issue happening which I'd like to call your attention
to. When trying to interpolate data from a very compact mesh into a
coarse mesh, the interpolation function does not seen to be working
properly. Perhaps the solution to this issue is also to reduce the
error, as you pointed out. But since I do not know getfem's inner
mechanisms, I fell that it would be worth to call your attention to this
as well, in case it's necessary to update other places in the code.

Annexed to this email I'm sending a small program with 2 meshes, which
tries to interpolate data from the compact one into the coarse one. The
compact mesh is very similar to the one I sent you on the other mail,
however it's more "organized"; that other one had some deformations
applied to it which triggered the error in the dof calculation. In this
case, getfem can count the mesh number of dofs correctly, however the
interpolation fails for most of the dofs of the target mesh.


Yves Renard escreveu:
> Le vendredi 6 juillet 2007 14:29, vous avez écrit :
>> Fellow users:
>> This is very simple indeed, but I'm confused about it. When I use a
>> "FEM_PK(3,1)" finite element, shouldn't I have the same number of dofs
>> in the getfem_mesh_fem object that I have in the getfem_mesh?
>> I'm sending annex a short code that shows that this is not happening.
>> The original mesh has 27393 nodes, while the associated fem is having
>> 27492 dofs.
>> Where does this extra 99 dofs could be coming from? Is this normal?
> You are right, there is a problem. I think it is due to the specifities of 
> your mesh and to a non completely robust way to identify the dof in getfem.
> I will make the algorithm completely robust. For the moment, One way to fix 
> the problem in your case is to change the line 225 of
> dof_comp_(double e = 1.0E-10) : comp(e) { }
> into
> dof_comp_(double e = 1.0E-20) : comp(e) { }
> I will inform you when the modification will be done.

Attachment: interpolation.tar.gz
Description: application/gzip

reply via email to

[Prev in Thread] Current Thread [Next in Thread]