Hello again,
as I haven't found a method that creates a dim-1 triangulation in dim
space from another (<dim,dim>) one's boundary, I've written something
myself.
I store vertex and cell information in suitable objects and pass them to
GridReordering<dim-1,dim>::reorder_cells(BEM_cells);
BEM_tria.create_triangulation_compatibility( boundary_vertices,BEM_cells,
subcelldata); // (empty subcelldata object)
(I've tried without reordering and .create_triangulation(...) first.)
GridOut gives me an ucd file output like this (dimesion <1,2>, 8 cells
resulting from a once globally refined (-1,1) hypercube 2D:
8 8 0 0 0
1 -1 -1 0
2 0 -1 0
3 1 -1 0
4 -1 0 0
5 -1 1 0
6 1 0 0
7 1 1 0
8 0 1 0
1 43 line 1 2
2 43 line 2 3
3 43 line 1 4
4 43 line 4 5
5 43 line 3 6
6 43 line 6 7
7 43 line 5 8
8 43 line 8 7
Now as a strange thing, when I tell him to .distribute_dofs(BEM_fe) on
the BEM_triangulation, he assigns the right number of dofs (n_dofs()=8
with one Lagrange FE per cell, i.e. one dof per vertex and nothing
else), but the numbering is slightly wrong:
Vertices number 1 and 2 get dof number 1 (counting from zero, but zero
is overwritten by dof_accessor.templates.h::set_vertex_dof_index() in
the end). Also, vertices number 6 and 7 are assigned dof number 5. The
rest is good. After all, with this refinement, dofs zero and 6 don't
appear, 1 and 5 are assigned twice, very strange.
I get the same effect refining my original FEM grid more often: It's
always the one in the lower left getting the dof number overwritten from
its right neighbor and the upper right vertex the one from its lower
neighbor...
So I have the that either my triangulation is not valid - I'm not sure
about the structure rules in spacedim-1, but this is what I get from
GridReordering<dim-1,dim>::reorder_cells(BEM_cells) - or the dof
distribution algorithm for some reason fails on my grid.
5-->--8-->--7
| 7 8 |
^4 6^
| |
4 6
| |
^3 5^
| |
1-->--2-->--3
1 2
(hope this doesn't get mashed up by mail service)
debugging trace as far as I've understood it:
dealii::DoFHandler<1, 2>::distribute_dofs loops on line 1991 over all
cells, where it calls
1993 next_free_dof
1994 =internal::DoFHandler::Implementation::distribute_dofs_on_cell
(*this, cell, next_free_dof);
goes into
dealii::internal::DoFHandler::Implementation::distribute_dofs_on_cell<2>
where I think is something wrong with the neighbor identification around
line 116 ?
After all, here he really does overwrite the vertex dofs mentioned
above, which I think should be caught by this neighbor construction...
OK, but that's too deep for me - if just someone could tell me, if my
triangulation is maybe invalid this way, that would be great.
(If anyone's interested, I'd be happy to contribute my
create_tria_from_boundary method, but I think my code's anything but
best practice (or even good) - also I'm not sure it can be easily
transformed into a nice template)
Thank's in advance and a Happy New Year!
Till
Luca Heltai wrote on
Thu, 17 Sep 2009 06:18:55 -0700
On 16/set/09, at 15:33, Till Heinemann wrote:
I have a specific problem, where I want to combine a boundary
element integration and a finite element integration on one
domain.
I was going to use two different triangulations for this (is
this at all necessary?).
Yes. For now, deal.II supports coupling BEM and FEM only by using
separate meshes and dofhandlers. I have never had the need to do this,
but in principle it should be possible to have a "TriangulationView" or
something like this that behaves like a codimension one triangulation,
built on top of the boundary of a standard triangulation...
The BEM is supposed to share displacement variables at the
vertices the two domains coincide on (i.e. the boundary nodes).
You will have to do this by hand, but it is not too complicated.
So my idea was to create a dim and a dim-1 triangulation (and
dofhandlers, fes…) and somehow use the dof_handler to exchange
this displacement variable information.
The latest distribution of deal.II supports BEM as codimension one
grids, that is Triangulation<dim-1, dim> objects. You want a
triangulation with vertices in dim space, and cells in dim-1 space.
The next difficulty would be assembling and solving a common
system of equations to be solved for all the dofs appearing in
the 2 systems, which would resolve in combining a full matrix
from BEM and a sparse matrix from FEM – given respect to the
size of the FEM matrix, I think it may still be advantageous to
use a sparse matrix representation of the combined system
matrix?
In some of my applications I use deal.II sparse matrix also for BEM
problems. This does not seem to be too much of an overhead, compared to
the assembly of the full system.
So I’m not asking you to solve my problem for me, but maybe
someone has already attempted sth similar and can tell me if I’m
thinking in the right direction here or if there’s a simpler /
more efficient approach to it – or he knows why my ideas won’t
work.
Where can I find more information on this whole problem, which
examples may treat aspects of this?
The example you should look at is step-34, where a potential flow
problem is solved (Laplace equation for outer domain) using BEM. Part of
your problem will be very similar to that. As far as coupling is
concerned, I think your ideas seem reasonable.
Best,
Luca.
_______________________________________________
dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
