[ff3d-users] Re: boundaries of objects and meshes

[Stephane Del Pino]

-----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-----