2011/1/10 Roy Stogner <[email protected]>
>
> On Mon, 10 Jan 2011, Vasilis Vavourakis wrote:
>
> (1) in BEM mostly boundary integrations occur, which means that in 2D
>> problems only 1D discretization is needed. however, since only Edge
>> elements
>> are "loaded" to the MeshBase class, when i try to evaluate the normal
>> vectors to each quadrature point for each boundary (edge) element through
>> the "get_normals" function then i get an error. one option would be to
>> load
>> a 2D mesh (of triangles and quadrilaterals) and perform only boundary
>> integration to all non-neighboring side elements, but this way i would
>> load
>> into the System the nodes located inside the domain. any ideas on that?
>>
>
> The most flexible idea that jumps to my mind: adding a per-variable
> flag to identify BEM variables in a System, then querying that in
> DofMap so as to only assign degrees of freedom to boundary nodes.
> This would be a difficult feature for a non-experienced libMesh
> developer to write, though.
>
>
i've thought of a simple but yet not smart enough solution:
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.
>
> (2) the system matrix "A" of the final linear system "A*x=b" in not banded
>> as in FEM, but full populated... this means that parallelization is not
>> that
>> easy to implement, right?
>>
>
> 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???
> Efficiency is another question, though; I'm not sure what you'd want
> to do for preconditioning.
>
i think that direct solvers will do the job...so i've not come into thinking
about pre-conditioners.
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.
Vas
> ---
> Roy
>
------------------------------------------------------------------------------
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
