[Getdp] Mag. Vec Potential

Thu Apr 5 14:15:17 CEST 2007

Dear Bernhard,

I checked your problem and made three corrections in the .pro file (see 
added comments with //+++ Patrick...):

- one for the correct definition of the boundary condition related to 
the magnetic vector potential (thus to the magnetic flux density, which 
has a zero normal component not only on the lateral faces but also on 
the transversal ones of your geometry).

- one for the gauge constraint (the tree must be complete on all the 
surfaces with magnetic vector potential constraints before being 
extended in the volume).

- the surface 'd1' is removed from the domain of integration in 
Formulation 'for_a'.

I changed the 'solver.par' file as well (especially with a higher value 
for the 'Nb_Fill' parameter and a reasonable value for the 'Stopping_Test').

For reducing the number of unknowns for my tests, I modified the mesh 
sizes in the 'hexa.geo' file. With a finer mesh, perhaps you will have 
to increase the 'Nb_Fill' parameter.

If you have any other question, do not hesitate to ask me.

Kind regards,

Patrick Dular

Kubicek Bernhard wrote:

>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
>  
>
-- 
Patrick Dular, Dr. Ir., Research associate, F.N.R.S.
Department of Electrical Engineering and Computer Science
Unit of Applied Electricity
University of Liege - Montefiore Institute - B28 - Parking P32
B-4000 Liege - Belgium - Tel. +32-4 3663710 - Fax +32-4 3662910
E-mail: Patrick.Dular at ulg.ac.be

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hexa.pro
URL: <http://www.geuz.org/pipermail/getdp/attachments/20070405/4d5a0fae/attachment.pro>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: solver.par
URL: <http://www.geuz.org/pipermail/getdp/attachments/20070405/4d5a0fae/attachment.par>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hexa.geo
URL: <http://www.geuz.org/pipermail/getdp/attachments/20070405/4d5a0fae/attachment.geo>