[Top][All Lists]

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

Re: [Getfem-users] different mesh_fem definitions for different regions

From: Umut Tabak
Subject: Re: [Getfem-users] different mesh_fem definitions for different regions
Date: Wed, 29 Jul 2009 15:10:52 +0200
User-agent: Thunderbird (X11/20090409)

Renard Yves wrote:

Dear Umut,

If your region is a part of a mesh (not a boundary)
Dear Professor Renard,

Yes, there are two volumes that are mentioned in the previous mail, as the solid and fluid domains that have hexahedral meshes and the interface surface between these two domains,

, you can simply defines the mesh fem by setting a finite element method only on the element of this region.
This is what I also thought after I read the manual a bit more and looking at the code documentation.
You can also define a mesh_fem on the whole mesh but specify the region to the assembly procedures (or to the brick if you use the new bricks in Getfem++ 4.0).
This point is still not clear to me, maybe I should try on some example codes, but I think you are suggesting to assign the element properties to regions by using vectors that specify the elements in that region, and use the assembly over the whole mesh_fem but using the regions defined and since the fem_descriptors are assigned using the region information, the matrices will be assemble correctly. I guess, this is the reasonable explanation, correct me if I am wrong or if you have additions. Excuse me if there are some points there are inconsistent, I am a new user of the library eventually.

I have not read about the bricks yet, but Andriy Andreykiv, who is also using getFem++ quite often for his research and sending posts here, has pointed that bricks can be quite versatile by hiding the implementation and boundary condition application details for modelling.
The third mean is indeed to use a partial_mesh_fem object. However, the implementation in Getfem++ 3.1 is not efficient at all. The implementation
in Getfem++ 4.0 has been simplified and optimized.
I am using the svn copy for the moment, so could you make the same comment for the svn copy or should we wait for the next stable release of the library.

Best regards,

reply via email to

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