[Dzhordzhs]

Hello!

Program was designed as a part of Bachelor's thesis. The purpose was to create a tool to optimize magnetron sputtering process.

Keywords:
OpenFOAM, Salome, snappyHexMesh, electrons, magnetic field

Pre-processing:
- Geometry export from Salome, .stl file processing.

Electric and magnetic fields:
- Electric field calculation via electric scalar potential.
- Magnetic field calculation via vectorial magnetic potential.
- Hybrid boundary conditions for magnetic vector potential on boundaries between two regions.
- Magnetic permeability dependence on magnetic field strength.
- Open boundary conditions (infinite space).

Particles:
- Particles can be initialized in one or many separate regions.
- Particles of different species (charges, masses etc.).
- Particles can be initialized from any specific boundary (inlet).

Possible applications:
- Salome script scriptSalome.py and Bash script mergeFiles can be used to generate complicated geometries and export them to the OpenFOAM.
- Heat and mass transfer equations can be added to multiRegionFOAM and rarefied gas dynamics can be studied in complicated geometry cases.

https://github.com/jvencels/multiRegionPlasma
http://youtu.be/o-qdLP7xJWw

Here you will find the program, test example and written work (in Latvian).

I am not working on this project now, but anyway I would like to discuss the limits of OpenFOAM to solve electromagnetic problems, meshing etc.

Any suggestions are very-very welcome!

Juris

[chriss85]

Very interesting!

I'm working on a similar task right now, though it's only using one region for now, maybe more later.

I'm using an inhomogenous conductivity field and calculate electric/magnetic fields and current in it.

Maybe you can take a look here and give me some input on an appropriate BC?
http://www.cfd-online.com/Forums/ope...tml#post471040

Is there some documentation available on the coupling between the regions and the used BCs? Unfortunately I do not understand Latvian.
I saw that you use calculated BCs in the test case with a value of 0, why is that so?

[Dzhordzhs]

Program uses changeDictionary to modify BC in "0" folder. Check, for example, this file:
system/magnet2/changeDictionaryDict

I do not have other documentation. In Bachelor's work there also isn't much information about implementing BC.

In your post you mentioned mixed BC.
Check these BC in OpenFOAM.

[chriss85]

Thanks, I didn't see the changeDictionaryDict file. So you're keeping all currents in the test case boundaries.

I will look into the BC mentioned in your link, I think this is what is needed for electric field and current through electrodes.

[chriss85]

I have another topic I would like to mention:

Did you investigate huge steps in the electrical conductivity from one cell to another?
I am noticing a violation of current continuity at the cells next to the step.
I believe this is due to the discretization and the calculation of the gradient (for the elctric field) using a central scheme.

It's not too much of a problem, but I'm wondering if one could use a better scheme to avoid this.

[Dzhordzhs]

In my case I had one region with the electric field and boundaries. Conductivity was 0.

I was studying large plasma density gradients. My problem was with particle-field interaction.
OpenFOAM stores fields inside the cells, I was not able to redistribute charge density among neighbor cells.

I do not know what quantities conserves FVM, but try other scheme.

[chriss85]

Hi again,

I've made some validation calculations for the electric potential. Using your phiOpen BC with a radius that is larger than the mesh, I can't see any difference to simply setting a fixedValue of 0. The computed solution differs from the analytical solution because of the finite size of the mesh, since the analytical solution sets a zero potential in infinity.

Any ideas?

[Dzhordzhs]

Hi,
I assume you are talking about open boundary conditions - how to set them to represent infinity.

From the file file: /multiRegionPlasmaTest/system/air/changeDictionaryDict
This file defines boundary conditions between region "air" and other regions

    phi
    {
        internalField   uniform 0;

        boundaryField
        {
            ".*"
            {
                type            fixedValue;
                value           uniform 0;
            }
            "air_to_box.*"
            {
                type            phiOpen;
                radius		uniform 0.15;
            }
            "air_to_target.*"
            {
                type            fixedValue;
                value           uniform -10;
            }

Radius is specified between boundary "air_to_box".

This BC defined in /multiRegionPlasmaFoam/phiOpenFvPatchScalarField.C

    operator==
    (
        transform(I - n*n, intFld)/(1/(patch().deltaCoeffs()*radius_)+1)
    );

If you set radius to 0 then i expect that you get zeroGradient BC.

[chriss85]

I guess I need to look in your case/solver.

I have been solving the laplace equation laplace(sigma, phi) = 0 and used your open boundary condition for phi.

My case consists of the air between solid spheres. I have spheres with radius 1 at (0 0 0), (0 1 0) and (0 0 1) with different potentials applied to them. The outer boundary is a sphere of radius 20. I have tried to set the BC of the outer boundary to the phiOpen condition with a radius of 100. Maybe I understood the meaning of the radius incorrectly.
I thought it was meant to represent an imaginary outer sphere, outside of the case with this radius. Is it the distance of the current boundary to the voltages / charges on the inner spheres instead?

[Dzhordzhs]

"radius" means radius of the open boundary.
If you have sphere of air with radius 20 then set this parameter "radius" to 20.

[chriss85]

Ok that makes more sense I guess. However, I tried setting the radius of the outer sphere now, so the boundary of it looks like this (Now with outer sphere radius = 40):


border
{
type phiOpen;
radius uniform 40;
value uniform 0;
}

Using a fixedValue there with value uniform 0; gives the same result for me...
The solution approaches the analytical result for larger outer boundaries as expected, I just can't see any difference from your open BC to a fixedValue

[Dzhordzhs]

Check what happens if you don't add the line "value uniform 0;", only like this:

border
{
type phiOpen;
radius uniform 40;
}

[chriss85]

That doesn't work unfortunately, and you don't do that in your test case either. You have used
".*"
{
type calculated;
value uniform 0;
}

in the phi file and change it to phiOpen in the changeDictionaryDict as far as I can see.

The open boundary condition requires the value field to be specified, likely because it inherits from the fixedValue BC that requires it.

[chriss85]

I'm currently also looking into extending my solver towards multiple regions so I can include solids. I saw that you based your AMixed boundary condition on some variant of the temperatureCoupled boundary conditions (is that correct?).

However, you inherit from fixedValueFvPatchField, while the coupled temperature BCs inherit from a mixed BC.
In turbulentTemperatureCoupledBaffleMixedFvPatchScala rField.C a comment says:

    // Both sides agree on
    // - temperature : (myKDelta*fld + nbrKDelta*nbrFld)/(myKDelta+nbrKDelta)
    // - gradient    : (temperature-fld)*delta
    // We've got a degree of freedom in how to implement this in a mixed bc.
    // (what gradient, what fixedValue and mixing coefficient)
    // Two reasonable choices:
    // 1. specify above temperature on one side (preferentially the high side)
    //    and above gradient on the other. So this will switch between pure
    //    fixedvalue and pure fixedgradient
    // 2. specify gradient and temperature such that the equations are the
    //    same on both sides. This leads to the choice of
    //    - refGradient = zero gradient
    //    - refValue = neighbour value
    //    - mixFraction = nbrKDelta / (nbrKDelta + myKDelta())

Your code looks different. I think you use some kind of weighted average between the potentials on both sides? Can you explain the logic behind this difference?

I believe I should be able to do the same thing for the electric potential, but with the electrical conductivity sigma instead of heat conductivity kappa (or mu in your case).

Apparently there isn't much documentation available on these topics, so it would be nice if you could give me a hint here

[Dzhordzhs]

Yes, I based magnetic vectorpotential boundary conditions on temperature boundary conditions.

There are no perfect boundary conditions for vector-potential fields between two regions. Boundary conditions I used are approximations - I obtained them by deduction, but I do not remember details.

[chriss85]

The coupling of the electric potential is working now. However, I need a sub-loop for convergence between the different regions. I'm somewhat surprised that you don't use one. Was it not needed in your case?
chtMultiRegionFoam solves the energy equation in the outer PIMPLE loop, but it doesn't appear to use a convergence check of the energy/temperature region coupling for this iteration.
I'm now checking for convergence by comparing the current electrostatic potential with the one from the previous iteration and breaking the loop when the relative differences fall under a tolerance.

[chriss85]

I had to change the convergence check, now it checks that the potential and current density are (jnearly) equal at the boundaries of the regions. The previous criterium didn't result in a converged solution.

I attached an image depicting the iteration process. There are three regions which are coupled using the mixed formulation like the one in chtMultiRegionFoam. At the end there are still about 10 iterations per time step.

I really want to get a better convergence, I'll have to check if the speed can be improved with Aitken's delta-squared method (mentioned in the document above) or similar. Maybe I can also use a rougher tolerance.

[wyldckat]

Greetings to all!

@Juris: I've created a basic wiki page for to help getting your tool multiRegionPlasma known to the community that uses OpenFOAM technology: http://openfoamwiki.net/index.php/Co...tiRegionPlasma

May you or anyone else feel free to update that wiki page!

Best regards,
Bruno

[logo]

hi juris ,

I am trying to check your solver because it seems that it is very useful for my case. However when I compile the dsmc library the below error occurs :

parcels/derived/dsmcParcel/dsmcParcel.H:38:22: fatal error: particle.H: No such file or directory
#include "particle.H"

can you suggest me a solution ?
thanks in advance

[wyldckat]

Originally Posted by logo

can you suggest me a solution ?

Quick question: Which OpenFOAM version are you using?