[Getdp] OT: Theoretical Questions/Gauge Conditions

[Kubicek Bernhard]

Hello,
I have already been reading (little)/collecting papers on gauge conditions in numerical electrodynamics, and honestly, there are some things which I would like to ask some professionals:

The edge-Whitney elements are often defined by the node-Whitney elements n_i (which are also sometimes called hat functions):
e_ij=w_i grad w_j-w_j grad w_i
When one plots these (see attached pdf), they are not really intuitive. However, by adding/subtracting them pairwise some structure appears.
The added ones show homogenous fields, while the subtraction of two looks like carousel rot-fields with a origin that is centered in the remaining edge.
a)Is the reason for defining the edge Whitney elements in this way, that they are divergence free and/or that they are rot-constant within the element ?
If so, is there another edge-Whitney element that is rot-free and div-constant?

If one ones wants to calculate the mag. vec. potential (A) from a given current distribution, the "normal" way seems to define A at the edges. Then however, there would be be many possible solutions that would lead to zero residual. In [1] there is stated that it is still possible to solve this "ungauged" A using iterative methods. When I tried this with getDP, the preconditioning ILUTP complained about zero rows iirc (which seems logical since the Matrix is singulary).
One way of solving this problem seems to be to take the graph of nodes/edges and leave away as many edges, so that all nodes are still connected. Only on those edges the equations for A are solved while for the "loop-creating" ones A is set to zero.
b) Why is it relevant to tell declare in getDP from which surfaces this tree "starts" ? Or does this states that all edges on the declared surfaces and all of a random cotree have zero A ?

c) By playing around we found that for faces where A has a symmetry boundary condition and no source terms (so b is normal to the surface), there should be no TreeStartingOn gauge condition defined. Is this correct?

d) How to correctly specify a boundary condition for a face where there is some current density normal to the face, and where  b should be considered only parallel to surface (the "physically gauged" A  then would be normal to the surface)?
An additional Galerkin Term (CompZ[{a}],{a'}) In SampleSurfaceXY  with no gauge condition starting from this face seemed not to do work.

e) Does the "tree-gauge-trick" also work on hexahedral and mixed (i.E. containing tetrahedral, hexahedral and "pyramidal") element meshes?
Because I tried, and failed for some unknown reason: The resolution had two steps: Calculate el. potential from voltage boundary conditions and a spatial conductivity profile, all non-transient. Afterwards,  with the A-edge-tree gauge, calculate mag. vec. pot. A (using rect-shell transformations) from the current -cond*{d V}.
I get nice results for a tetrahedral mesh, but when I go hexahedral or mixed with the _same_  .pro file, the calculated results become very counter-intuitive.

f) Is there a way to output the edge values in the post-processing, instead of some probably interpolated nodal values?

g) Is there a good read on the "h-phi" formulation _apart_ from Bossavit? Finding some papers on the net is a pain, because of the unfortunate name of the formulation.

h) Could one expect a big performance leap by exploiting the h-phi formulation compared to a "global A" formulation, if the source electric current for the magnetic field is only existing in one fith of the elements,  while the remaining cells are in a simple connected region?

i) Are the following statements reasonable: 
The matrix element M_ij originating from a Galerkin term (L_1 Dof{A},{L_2 A'}) is defined by 
\int dv (L_1 l_i)(L_2 l_j)
with the basis functions l of the field A. 
The actual value is approximated using a numerical Gauss-Integration, by calculating a weighted sum of the values (L_1 l_i)(L_2 l_j) at a finite number of well chosen positions wihin the shared support.
So, if the operator L1 is changing polynomial with degree n in space, the number of points in the integration block of the .pro file should be larger than m, where m*2-1=n+2, since a N point Gauss quadrature is exact for polynomials with degree 2N-1 \cite{Numerical Recipies, shortly before formula 4.5.9}, and the two bases functions are of order 1.

j) Is more a proposal: in [1] there is the description of a loop gauge that (at least in the paper) seems to produce "nicer" vector-potentials than the edge-gauge one can use from getDP. Maybe this could be an interesting thing to add to the already great capabilites of getDP (e.g. by an additional Basis-Function-Type "BF_EdgesOfLoops").



I feel very guilty for posing this bombardement of questions, but there is simply nobody else I know who I can ask. As well, this might be important for people who want to learn to work with getDP, or at least this is what I hope.
So thank you in advance in case your valueable time allows you to read/answer some of this (possibly stupid) questions.

Nice greetings from Vienna,
Bernhard Kubicek

Some literature on this themes:
[1] Ticar, I.; Biro, O.; Preis, K.: Vector potential expanded by edge basis functions associated with loops on finite element facets.  IEEE transactions on magnetics 38 (2002) , S. 437-440
[2] Vasile Catrinel Gradinaru: Whitney Elements on Sparse Grids, Dissertation, Tübingen 2002.
[3] J.C. Nedelec: Mixed Finite Elements in R3, Numerische Mathematik 1980.
[4] R. Albanese, G. Rubinacci: Solution of three dimensional eddy current Problems by integral and differential methods, IEEE Trans. Magnetics, 24(1), 1988.
[5] Biro, O.; Preis, K.; Richter, K. R.: On the use of the magnetic vector potential in the nodal and edge finite element analysis of 3D magnetostatic fields. IEEE transactions on magnetics 32 (1996) , S. 651-654
-------------- next part --------------
A non-text attachment was scrubbed...
Name: edge.pdf
Type: application/octet-stream
Size: 148263 bytes
Desc: edge.pdf
URL: <http://www.geuz.org/pipermail/getdp/attachments/20060830/95e67cfa/attachment.pdf>