On Tue, 11 Jan 2011, Vasilis Vavourakis wrote:
load two Meshes: one mesh that is 1D (this is the BEM mesh used for the system)
and another dummy one that is 2D (with Trias+Quads+Edges), where
there is one-to-one match on all Edge elements. in addition, force the same
kind of order of Quadrature for both meshes for surface
integrations...so that there is consistency to quadrature points. this way it
can be evaluated the normal vectors...i think! BUT this solution
hinders someone to use AMR directly to the 1D mesh without applying the same
thing to the 2D mesh, if you understand what i mean.
Actually, if you're using a polygonal/polyhedral domain (or a domain
where coarse piecewise quadratic geometry is good enough), the
solution here is simple: don't refine the 2D mesh. You'll have to
generate "quadrature points" via inverse_map rather than by hoping you
matched up quadrature rules, but that's the safe way to go anyway
(some of our 2D quadrature rules that you'd need on the boundary of a
3D domain aren't symmetric).
A less hackish solution would be to just add (optional) tangent/normal
vectors calculation for interior FE evaluations. The
FEBase::compute_face_map code is straightforward enough to move and
extend; we'd be happy to accept a patch.
Our SparseMatrix class would still parallelize large dense matrices;
you'd be able to get solutions. The only code change is again in
DofMap - the send_list for communication of a BEM variable would need
to be full rather than built up from neighbor topology.
right!!! there is no "neighbor topology" in BEM as in FEM ... the DofMap should
address all nodes in the mesh!!!
but about DoF index... should the function "dof_number()" do the job? for
example:
Node* node;
...
const unsigned int index =node->dof_number(system.number(),
system.variable_number("u"), 0);
the above variable "index" is it local or global???
The index is a global index. But getting indices isn't the problem;
ensuring sufficient communication between every index is. That's what
would require an additional System flag set and DofMap code.
the other problem that arises to this method is that the final system is not of the form: "K *
u = F", as in FEM for elasticity; with "K" being
the stiffness and "F" the external force vector. in BEM the final system is like: "H * u = G * t",
where matrices "H", "G" contain the boundary
integrals and "u", "t" is the displacement and traction vector to all boundary
nodes. so in case there are some boundary nodes to whom the
traction is unknown (known "u" : Dirichlet BC) then there is a need for some
sort of system rearrangement!!! which to my mind seems very difficult
for the moment to handle in parallel.
This seems to assume that you're solving for u and t in the same
function space, and that known coefficients for one correspond to
unknowns for the other?
In that case you just add_matrix and add_vector to allocate
H,G,u_known,t_known terms, assemble them separately, copy the
appropriate blocks into your final algebraic system to solve, then
copy the results back after the solve.
---
Roy
Requires a little care, but there shouldn't be
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
