[Getdp] Mag. Vec Potential

[Kubicek Bernhard]

Dear all,

as promised I send a small system which I try to solve with a tree
gauged magnetic vector potential. 
The system was created, because my final-goal calculation does not work
at all:

We try to simulate arc discharges, in a geometry simmilar to
coolmesh.png. The top surface is a symmetry boundary, the red and blue
things are conducting copper electrodes, green and grey-blue is some
air. One of the (visible) small side faces of the electrodes we insert a
source current density, the (visible) small side face of the opposed
electrode is on potential zero. In the "air", we have a
temperature-field imported into GetDP up to 30000 Kelvin. The plasma is
modelled via a temperature dependent conductivity. All this is coupled
with a commercial CFD code, to simulate the arcs behaviour transiently,
e.g. the pinch forces, the resistive heating, fluid pressure waves,
movement...

All this workes nicely for our "playground" geometries e.g.
http://www.geuz.org/getdp/wiki/Gallery .
However, in the attached mesh we are more or less forced to use a
hexahedral mesh. The electrodes are so thin that they would force an
enourmous ammout of tetrahedras for some useful meshing. With the shown
structured hexahedral grid, we hope to use longish "bricks" instead of
"cubeish" cells. Also I think it is an advantage that and the violet
region, the mesh bends around the electrodes in a similar way as the
magnetic field. 
However, we experience very bad behaviour even for the calculation of
the current density. However, the magnetic field is completely invalid.
Which I don't understand, as my very beautiful mesh is indeed very
beautiful.
The big difference can be the hexahedral mesh, oposed to the tetrahedral
mesh we use usually.

That is why I created the attached system, to trace down the problem's
source.
// The gambit mesh are excluded because of their size, you can download
it here:
// http://kariert.org/files/gambit.gmsh

Basically, it is a infinitely long square wire with a constant electric
current "enclosed" in a box. The geometry is meshed either tetrahedral
or hexahedral using gmsh. To get some hexahedral grid using the
transfinite algorithm, the 8 outer volumes were chosen.
Alternatively, I have one more tetrahedral mesh created using converters
from Gambit, Fluent's commercial mesher, to pinpoint mesh problems (mesh
quality is a bit better than with gmsh2, reflected in less strange spots
around "bad" cells, see tetra* images). However, due to the conversion,
the region numbers are different, and therefore there are two blocks in
the .pro's region definition of which one needs to uncommented.

Attached are a couple of pngs showing the calculation results. The
tetrahedral ones compare to some extend with the analytical solution
(which should have a max norm of approx 0.27). Apart from a a tube where
there are very high fields, at the border between the volumes. Some
similar tubes on the outer sides can be seen, if the gauge condition is
not applied in the d* faces. It looks like if somehow a current is
searching a way to flow backwards.
Knowing that the static h-field can only exist if there are no
current-sources in the calculated regime ( rot h =j -> div j==div rot
h==0), we still think that things should be ok if the are current
sources on boundary surfaces?
We find this highly strange.
Furthermore, the hexahedral calculation is not even close in their
magnitude.
Our idea that maybe on the boundary faces that cut the wire, one could
"help" the a-potential by declaring a source-h-field also failed quite
impressively.

If someone has some ideas on what is going on and how we could improve
the calculations, that would be _extremely_ nice.
Personally, I am under a lot of pressure to make this work asap, but I
am out of ideas and knowledge.

Very nice greetings,
and thank you in advance, also for reading this long mail,
 Bernhard


-------------- next part --------------
A non-text attachment was scrubbed...
Name: coolmsh.png
Type: image/png
Size: 186190 bytes
Desc: coolmsh.png
URL: <http://www.geuz.org/pipermail/getdp/attachments/20070404/14a74d00/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tetra.geo
Type: application/octet-stream
Size: 1752 bytes
Desc: tetra.geo
URL: <http://www.geuz.org/pipermail/getdp/attachments/20070404/14a74d00/attachment.geo>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hexa.geo
Type: application/octet-stream
Size: 1580 bytes
Desc: hexa.geo
URL: <http://www.geuz.org/pipermail/getdp/attachments/20070404/14a74d00/attachment-0001.geo>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: solver.par
Type: application/octet-stream
Size: 4989 bytes
Desc: solver.par
URL: <http://www.geuz.org/pipermail/getdp/attachments/20070404/14a74d00/attachment.par>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gambit_tetracenter.png
Type: image/png
Size: 37311 bytes
Desc: gambit_tetracenter.png
URL: <http://www.geuz.org/pipermail/getdp/attachments/20070404/14a74d00/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tetracenter.png
Type: image/png
Size: 36394 bytes
Desc: tetracenter.png
URL: <http://www.geuz.org/pipermail/getdp/attachments/20070404/14a74d00/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hexacenter.png
Type: image/png
Size: 22975 bytes
Desc: hexacenter.png
URL: <http://www.geuz.org/pipermail/getdp/attachments/20070404/14a74d00/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: analytical_squarewire.png
Type: image/png
Size: 36636 bytes
Desc: analytical_squarewire.png
URL: <http://www.geuz.org/pipermail/getdp/attachments/20070404/14a74d00/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hexa.pro
Type: application/octet-stream
Size: 5253 bytes
Desc: hexa.pro
URL: <http://www.geuz.org/pipermail/getdp/attachments/20070404/14a74d00/attachment.pro>