[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ff3d-users] Re: boundaries of objects and meshes
From: |
Stephane Del Pino |
Subject: |
[ff3d-users] Re: boundaries of objects and meshes |
Date: |
Tue, 2 Dec 2003 22:18:18 +0100 |
User-agent: |
KMail/1.5.4 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 01 December 2003 15:16, Joerg R. Weimar wrote:
> Dear ff3d users and developers,
Dear Joerg.
> I am having some difficulties with ff3d when pbject have surfaces near
> a plane of the mesh. I have included a sample file which illustrates the
> problems:
>
> 1.
> In meshtest1.pov, the box coincides with the mesh dimensions, and I get
> the error
> Generating Surface Meshes
> Marching cube ...SurfaceMeshGenerator.cpp:3032: meshing object box {
> <-2, -2, -2>, <2, 2, 2>
> }
> a problem occured ...
> Check that:
> - the object is not to small compare to the background mesh
> - the object intersects the background mesh
I think that when the documentation will be finished, this will be more clear,
but I am not sure, since fictitious domains are not so intuitive than
standard FEM...
In fact, you do not need the box... This box is implicitly defined by your
mesh. So yes 2 different objects are used to define a single thing, that is
bad, but there is no better solution I think.
The code is not happy because it tries to generate the mesh of the box and
since it uses a Marching Tetrahedra like method, it needs to find vertices of
M which are inside the box and others which are outside. Here it only finds
vertices inside it...
So, do not specify the domain in the scene.
> 2. In meshtest2.pov, the mesh is slightly smaller on the zmin side.
> In this case, I get a result. Actually, shifting any one side is
> sufficient.
Yes, now some vertices are outside it near the border zmin.
> Unfortunalety, the result I get is not what I expect. This is a 3d
> version of the following 1-d problem:
> u = 0 at z=-1
> u = 10 at z=2
> Laplacian(u) = 0.
> Mesh: 5 points over z=-2..2 i.e., points -2,-1,0,1,2
> Since I implicitly use von-Neumann conditions in x and y, these should
> not change the solution.
>
> I expect a linear solution, which means that on the mesh I expect
> u1 below, but get u2:
>
> z u1 u2
> -2 0 0
> -1 0 0
> 0 3.33 5
> 1 6.66 7.5
> 2 10 10
>
> Does anyone know how to interpret this?
Yes, me ;-)
But this is not a trivial thing.
- - first, you have to remember that we are dealing with fictitious domain
methods. So, this is not as precise as standard finite elements. Usually it
is not so bad, but here, you found the worst situation.
- - second, for stability reasons, we decided in ff3d to make the behaviour of
the solver a little bit worst than that : we choose the following policy and
it may have to be improved a little because your example shows its limits.
The thing is that if an element carries the border of your domain, we compute
a coefficient that is the number of vertices inside over the number of
vertices of the element and use this coefficent in a way to modify the volume
of integration.
In your cas, the border is aligned to the border of the element and so half of
its vertices are detected being outside, so the volume of this element is
divided by two. This leads to this bad numerical approximation. Of course, if
you refine the mesh it will be much better.
I will make a bug report at
https://savannah.nongnu.org/bugs/?func=additem&group=ff3d
I will put you in copy so that you'll be informed when it is better...
In order to evaluate in a better way the coefficient. But I have to admit that
if this will be done for version 1, this is not my priority...
> 3. If I shift the boundary of the lower object, (meshtest3.pov) I get a
> segmentation fault:
> Program received signal SIGSEGV, Segmentation fault.
> 0x080d3556 in MeshExtractor<SurfaceMeshOfTriangles>::operator()(unsigned
> const&) const ()
Here is the same kind of problem than the first one. For some reason that is
not clear to me the surface mesh generator did not crash, but it generated an
empty mesh. The bug there is that I did not check the size of the mesh when
builting the iterator. I fixed it.
Thank you for all those remarks.
I would like to say one more thing.
For your case, you are using boxes where planes would be more appropriated
because the boxes you use have comon boundaries with the mesh M. This is bad
for the numerical reasons I explained before.
Best regards and enjoy ff3d!
Stephane.
PS : I hope all this will be simpler when the manual is up to date ...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/zQGabZyhKhZwdc0RAvlbAKDFERM1h5MixMxqklDgDWOXzXqxHQCgjhim
D8RbEe7oFhp5UVjtfI1EvLE=
=mVHr
-----END PGP SIGNATURE-----