How to control NUM from UI
A first way of controlling the execution of
SPIS/NUM solvers is through the source code. The object oriented (OO) language
Java allows an easy handling of objects like a Spacecraft, a
Plasma or a VolumeDistribution. In practice,
this can be done either:
-
directly in the NUM Java
source code as documented in Java for NUM.html
(Java basics), NUM architecture.html (code architecture) and NUM integration in
framework.html (practical file integration)
-
through the Jython command line of SPIS/UI (still to
be documented).
The second simplified way of controlling the
execution of SPIS/NUM is through a more classical user interface, offering the
capability to modify parameters, either global or local. This is the subject of
this page. Of course it reduces somewhat the range of possibilities with
respect to what is really supported by the solvers. The advanced users may look
at the source code of ..\API\public\spis\Top\Simulation\SimulationFromUIParams.html to see how most of the
global parameters control the simulation at top level.
Note the last column of the tables below
stating whether each property is in use or not as of this software version
(currently 3.00.01rc1).
Global parameters
are presented first, local parameters, i.e.
fields living either in the volume or on a surface (spacecraft or external
boundary), are presented next.
The general behaviour of NUM solvers is ruled by
global parameters. They are organised by section:
-
Plasma
-
B Field
-
Particles
sources on spacecraft
-
Outputs
In each section the parameters are first
reviewed, then listed in a table.
They can be edited through a spreadsheet
editor, which is launched by the Solver/Set Global Param menu, or at first click on the UI to Num button.
The major parameters in use as of todays version are simply the duration of the simulation and the time step for plasma dynamics integration.
If set to zero, the time step is automatically
set so as to fulfil stability criteria. It roughly sets the time step so that
particles do not cross more than a fraction of a cell in a time step (CFL-like
condition), which also insures dt < 1/wp if the user defined cells smaller than Debye
length. This is when electrons dynamics is modelled (PIC model), since things
are much more stable when electrons are treated as a fluid (Boltzmann
distribution only). Such automatic time step definition is quite difficult, hence this feature still lacks robustness. For
example if particles are strongly accelerated after injection, time step can
get too coarse and result in inaccuracies in trajectory integration. It does
not take into account spacecraft potential evolution either (if floating) and
it may lead to too fast potential evolution in case of small Csat and large current (e.g. when
turning on a thruster). In all
these cases return to a manual tuning of these parameter (plasmaDt,
Csat
).
Name |
Description |
Variable
type |
Unit |
Default
value |
In use |
duration |
Duration
of the simulation |
float |
[s] |
0.1 |
Yes |
plasmaDt |
Time step
for plasma dynamics (automatic if = 0) |
float |
[s] |
0.0 |
Yes |
plasmaDuration |
Duration of plasma dynamics inner loops (10 times
plasmaDt if = 0) |
float |
[s] |
0.0 |
little |
scDt |
Integration
time for SC potential between each plasma dynamics loop integration (10 times
plasmaDuration if = 0) |
float |
[s] |
0.0 |
No |
This section defines the environment through two distributions of electrons and two of ions. The total should be neutral (not enforced).
The major point to be noted is that some of the parameters are names of classes. It means that Java generates a class from its name, which is possible thanks to the powerful introspection capabilities of Java. Reasonable defaults are provided for these classes, to which shy users can stick.
The general rules is for the environmentType parameter, which defined the environment:
-
this class must derive from
the class Environment
-
have a specific constructor including the UI-defined parameters as described
in ..\API\public\spis\Top\Plasma\Environment.html
-
in practice as of today only
BiMaxwellianEnvironment is supported, which may
involve two Maxwellians or only one by setting the
second one(s) to zero density (as in the defaults)
The general rules for the ionDistrib* electronDistrib* parameters, which define the 4 particle populations (2 of ions, 2 electrons), is:
-
these class must derive from
the class VolDistribWithIO
-
have a specific constructor including the UI-defined parameters as described
in ..\API\public\spis\Vol\VolDistrib\VolDistribWithIO.html
-
in practice as of today only GlobalMaxwellBoltzmannVolDistrib and PICVolDistrib are supported. The latter
described a particle population as a global thermal equilibrium distribution
(Maxwell-Boltzmann) and is usually valid when no
attractive potential or potential barrier exist. The
Particle-In-Cell model (PICVolDistrib)
really simulates this population dynamics but is much more costly in
computation time and memory.
The supported types of ions is currently H+,
O+, H20+, Xe+, Xe++, Ar+, Cs+, but can easily be increased (see the source of ..\API\public\spis\Top\Default\SpisDefaultPartTypes.html).
Name |
Description |
Variable
type |
Unit |
Default
value |
In use |
Name of
the Environment class to be used (ex: BiMaxwellianEnvironment which will use the parameters
below, or WorstCaseGeoEnvironment which will be
self-contained) |
String / Class |
- |
BiMaxwellianEnvironment |
Yes |
|
electronDensity |
electron
density (1st population) |
float |
[m-3] |
1.0e6 |
Yes |
electronTemperature |
Electron
temperature(1st population) |
float |
[eV] |
1.0 |
Yes |
Name of
the VolDistrib class to be used for electrons |
String / Class |
- |
GlobalMaxwellBoltzmannVolDistrib |
Yes |
|
ionDensity |
ion
density (1st population) |
float |
[m-3] |
1.0e6 |
Yes |
ionTemperature |
Ion
temperature (1st population) |
float |
[eV] |
1.0 |
Yes |
ionVx |
Ion drift
velocity along x axis (1st population) |
float |
[m/s] |
0.0 |
Yes |
ionVy |
Ion drift
velocity along y axis (1st population) |
float |
[m/s] |
0.0 |
Yes |
ionVz |
Ion drift
velocity along z axis (1st population) |
float |
[m/s] |
0.0 |
Yes |
ionType |
First ion
population (a string that must be found in the particle types filename below) |
String |
- |
H+ |
Yes |
ionDistrib |
Name of
the VolDistrib class to be used for ions |
String / Class |
- |
PICVolDistrib |
Yes |
electronDensity2 |
electron
density (2nd population) |
float |
[m-3] |
1.0e6 |
Yes |
electronTemperature2 |
Electron
temperature(2nd population) |
float |
[eV] |
1000.0 |
Yes |
electronDistrib2 |
Name of
the VolDistrib class to be used for the 2nd
electron population |
String/ Class |
- |
GlobalMaxwellBoltzmannVolDistrib |
Yes |
ionDensity2 |
ion
density (2nd population) |
float |
[m-3] |
1.0e6 |
Yes |
ionTemperature2 |
Ion
temperature (2nd population) |
float |
[eV] |
1000.0 |
Yes |
ionVx2 |
Ion drift
velocity along x axis (2nd population) |
float |
[m/s] |
0.0 |
Yes |
ionVy2 |
Ion drift
velocity along y axis (2nd population) |
float |
[m/s] |
0.0 |
Yes |
ionVz2 |
Ion drift
velocity along z axis (2nd population) |
float |
[m/s] |
0.0 |
Yes |
ionType2 |
Second
ion population (a string that must be found in the particle types filename
below) |
String |
- |
H+ |
Yes |
ionDistrib2 |
Name of
the VolDistrib class to be used for ions 2nd
population |
String/ Class |
- |
PICVolDistrib |
Yes |
avPartNbPerCell |
average
number of super-particle per cell NB: the
average particle number per node is more relevant because computation is mostly on the nodes. It is 6
times bigger, this is why avPartNbPerCell can be
rather small ~ 5 |
float |
[-] |
5.0 |
Yes |
Poisson conditions are always:
- Dirichlet on the spacecraft (fixed potential), the initial potential being defined in the local parameters (see next section)
- Fourier on the external boundary (mixed Dirichlet-Neumann) with parameters defined so as to give an asymptotic behaviour in r-n
And are controlled by the poissonBCType parameter.
The non-linear Poisson solver includes one (or two) Maxwellian distribution directly in the Poisson solving scheme:
-Df = e(ni n0 eef/kT) / e0
and has the major advantage to be stable even for cells larger than Debye length. If the non linear solver is selected (linearPoisson = 0), the electron distribution(s) are automatically inserted in the non-linear Poisson solver.
The next parameters, controlling the maximum iteration number or tolerance of the conjugate gradient Poisson equation solver, are rather for specialists.
Name |
Description |
Variable
type |
Unit |
Default
value |
In use |
poissonBCType |
0- Use the Poisson boundary
conditions defined as fields through electric node editor (Dirchlet/Fourier with UI-defined parameters) 1- Dirichlet on SC, Fourier on external
boundary with alpha parameter mimicking a 1/r decay (~vacuum) 2- Dirichlet on SC, Fourier on external
boundary with alpha parameter mimicking a 1/r2 decay (~pre-sheath) 3- Dirichlet on SC, Fourier on external
boundary with alpha parameter mimicking a 1/rn decay, n being next
parameter (poissonBCParameter1) |
int |
- |
2 |
Yes |
poissonBCParameter1 |
Parameter
that can be used by some BC types (e.g. 1/rn exponent) |
float |
[varies] |
|
Yes |
poissonBCParameter2 |
2nd
parameter that can be used by some BC types |
float |
[varies] |
|
No |
linearPoisson |
0- no: use non-linear Poisson solver 1- yes: use linear Poisson solver |
int |
- |
0 |
Yes |
iterGradient |
Maximum
iteration number for conjugate gradient Poisson Solver |
int |
- |
100 |
Yes |
tolGradient |
Tolerance
for conjugate gradient Poisson Solver (stops when residue is smaller than tolGradient) |
float |
[-] |
0.0001 |
Yes |
iterGradientNl |
Maximum
iteration number for conjugate gradient Poisson Solver when non-linear
solving |
int |
- |
100 |
Yes |
tolGradientNl |
Tolerance
for conjugate gradient Poisson Solver when non-linear solving |
float |
[-] |
0.0001 |
Yes |
iterNewton |
Maximum
iteration number for |
int |
- |
10 |
Yes |
tolNewton |
Tolerance
for |
float |
[-] |
0.02 |
Yes |
An homogeneous B field can be defined this way.
Name |
Description |
Variable
type |
Unit |
Default
value |
In use |
Bx |
x-component
of the magnetic field (uniform over the computation box) |
float |
[T] |
0.0 |
Yes |
By |
y-component
of the magnetic field |
float |
[T] |
0.0 |
Yes |
Bz |
z-component
of the magnetic field |
float |
[T] |
0.0 |
Yes |
If electricCircuitIntegrate =
0, spacecraft potentials are constant, if electricCircuitIntegrate =
1, the spacecraft floats, the relative capacitances being derived from material
properties, whereas the spacecraft absolute capacitance is given by the
parameter CSat.
Name |
Description |
Variable
type |
Unit |
Default
value |
In use |
electricCircuitIntegrate |
Flag
controlling SC electric circuit integration: -
0: do not integrate (constant initial potentials) -
1: integrate |
int |
- |
1 |
Yes |
initPotFlag |
Flag to
define initial spacecraft potential -
0: set it to 0 -
1: uniform potential = initPot (next
parameter) -
2: local potential defined via the UI (SCDiriPot,
see local parameters below) |
int |
- |
1 |
Yes |
initPot |
Initial
global potential for the spacecraft (if initPotFlag
=1) |
float |
[V] |
0 |
Yes |
CSat |
Spacecraft
absolute capacitance |
float |
- |
1.0e-9 |
Yes |
electricCircuitFilename |
Name of the file describing extra electric
devices between electric (super-)nodes. See below for
syntax of circuit file. The file must be in the "default input
directory" (jython directory (!) on Windows
XP, SpisUI on linux ??).
(to be improved) |
String |
- |
circuit.txt |
Yes |
The file describing the electric circuit is
composed of an arbitrary number of lines, each with the syntax:
componentDescriptor node1Id node2Id
value
with:
- componentDescriptor (a string) one of
- C : it is a capacitor of capacitance value
- R : it is a resistor of resistance value
- V : it is a potential source of potential difference value (Vnode2 = Vnode1 + value)
- node1Id and node2Id (integers): the Ids of the (super) electric
nodes between which to plug the component (same Id as in ElecNodeId)
- value (a float): the value
of the component (resistance
)
Example file :
V 0 1 -10
R 0 2 1.e6
C 0 3 1.e-10
C 2 3 1.e-10
-
line 1: Electric super node
1 is biased of -10 V with respect to node 0, which is SC ground (it may be a Langmuir probe).
-
line 2: Electric super node
2 is related by a 1 MW resistor to SC ground (it may be a solar array).
-
line 3: Electric super node
3 is not related by any "real" component to SC ground, so it was
chosen to model its capacitive coupling to the ground (this is not necessary, a
fraction of SC absolute capacitance CSat
is attributed to each electric node, proportionally to its area, so that it
does not have zero capacitance, resulting in infinite potential as soon as it
collects some charge).
-
line 4: the capacitive
coupling between nodes 2 and 3 has been added (seldom useful).
Particle sources on spacecraft
These parameters allow the embedding of a plasma sources on the spacecraft (e.g. a thruster). Several sources are allowed, currently 4, but their number can easily be increased by modifying DefaultGlobalParam.py in SpisUI/DefaultValues folder.
Each source is controlled by the following three global parameters, which allow turning the source on, defining the source class and particle type. The general rules for the sourceType parameter, which defines the source class, is:
-
this class must derive from
the class NonPicSurfDistrib
-
have a specific constructor including the UI-defined parameters as described
in "Writing UI-supported
classes" page and in ..\API\public\spis\Surf\SurfDistrib\NonPICSurfDistrib.html
-
in practice as of today only LocalMaxwellSurfDistrib and
MaxwellianThruster are
supported (the latter being experimental, but you can modify it, cf. ..\API\private\spis\Surf\SurfDistrib\MaxwellianThruster.html)
Extra local parameters allow to switch locally
between the sources (sourceId),
and to define their parameters (current, temperature, Mach number).
Name |
Description |
Variable
type |
Unit |
Default
value |
In use |
sourceFlag1 |
Flag for
defining first artificial source on the spacecraft: 0 => none, 1 =>
yes, x => number of
super-particles densified by x (for a local source,
for which you want x times avPartNbPerCell
particles per cell) |
float |
- |
0 |
Yes |
Name of
the SurfDistrib class to be used for first
artificial source on the spacecraft (ex: LocalMaxwellSurfDistrib,
which will use the source flux, source temperature and source Mach
user-defined local fields, whereas a specific EP model could only use the
source flux and define internally its velocity distribution) |
String / Class |
- |
Yes |
||
sourceParticleType1 |
Type of particles
for first particle source (a string that must be found in the particle
types) |
String |
- |
Yes |
|
sourceFlag2 |
Same as
sourceFlag1, but for source 2 |
float |
- |
0 |
Yes |
Same as
sourceType1, but for source 2 |
String / Class |
- |
Yes |
||
sourceParticleType2 |
Same as
sourceParticleType1, but for source 2 |
String |
- |
Yes |
|
sourceFlag3 |
Same as sourceFlag1,
but for source 3 |
float |
- |
0 |
Yes |
sourceType3 |
Same as
sourceType1, but for source 3 |
String / Class |
- |
Yes |
|
sourceParticleType3 |
Same as
sourceParticleType1, but for source 3 |
String |
- |
Yes |
|
sourceFlag4 |
Same as
sourceFlag1, but for source 4 |
float |
- |
0 |
Yes |
sourceType4 |
Same as
sourceType1, but for source 4 |
String / Class |
- |
Yes |
|
sourceParticleType4 |
Same as sourceParticleType1,
but for source 4 |
String |
- |
Yes |
|
Number of
particle sources: not to be modified in UI, but only in defaultGlobalParam.py
if the number of sources is modified in defaultGlobalParam.py
(e.g. if sourceNb is set to 5, sourceFlag5,
sourceType5 and sourceParticleType5 must be defined in defaultGlobalParam.py
located in SpisUI/DefaultValues folder). |
int |
- |
4 |
Yes |
These parameters are mostly flags to turn
interactions on or off.
Name |
Description |
Variable
type |
Unit |
Default
value |
In use |
photoEmission |
-
if 0, no photo-emission -
if 1, photo-emission is turned on with the sun direction defined below
(no shading for now) -
if 3, photo-emission is turned on with the sun direction defined below
and photo-electron dynamics is modelled (PIC) -
if 5, photo-emission is turned on with a sun flux defined locally
(local parameters) -
if 7, photo-emission is turned on with a sun flux defined locally
(local parameters)and photo-electron dynamics is modelled (PIC) NB: note
each bit meaning: bit0=>on, bit1=>dynamics of photo-electrons is
modelled, bit2=>local sun flux |
int |
- |
0 |
Yes |
electronSecondaryEmission |
-
if 0, no secondary emission under electron impact -
if 1, secondary emission under electron impact is turned on -
if 2 or 3, secondary emission under electron impact is turned on and secondary
electron dynamics is modelled |
int |
- |
0 |
Yes |
protonSecondaryEmission |
-
if 0, no secondary emission under proton impact -
if 1, secondary emission under proton impact is turned on |
int |
- |
0 |
Yes (under
testing) |
volumeConductivity |
-
if 0, no volume conductivity -
if 1, volume conductivity is turned on |
int |
- |
0 |
Yes |
inducedConductivity |
-
if 0, no induced conductivity -
if 1, induced conductivity is turned on |
int |
- |
0 |
Yes (under
testing) |
surfaceConductivity |
-
if 0, no induced conductivity -
if 1, induced conductivity is turned on |
int |
- |
0 |
Yes |
sunX |
x-component
of sun direction (points to sun, vector opposite to photons velocity) |
float |
- |
0.0 |
Yes |
SunY |
y-component
of sun direction |
float |
- |
0.0 |
Yes |
SunZ |
z-component
of sun direction |
float |
- |
1.0 |
Yes |
Outputs
These parameters mostly the periodicity for
storing data for postprocessing (these data are then
returned to UI and can be plotted).
Two last parameters tune the detail level for
screen printing (or verbosity level).
Name |
Description |
Variable
type |
Unit |
Default
value |
In use |
scPotMonitorStep |
time step
for spacecraft ground potential monitoring (0.0 => none) NB: used
also for currents and potentials on each electric (super) node |
float |
[s] |
0.0 |
Yes |
scPotMapMonitorStep |
time step
for spacecraft local potential monitoring (0.0 => none) |
float |
[s] |
0.0 |
Yes |
scCurrentMapMonitorStep |
time step
for spacecraft local currents monitoring (0.0 => none) |
float |
[s] |
0.0 |
Yes |
plasmaPotMapMonitorStep |
: time
step for plasma potential monitoring (0.0 => none) |
float |
[s] |
0.0 |
Yes |
densitiesMapsMonitorStep |
: time step
for densities monitoring (0.0 => none) |
float |
[s] |
0.0 |
Yes |
particleTrajectoriesNb |
number of
particle trajectories per PIC population |
int |
- |
0 |
No |
materialPropertyPlots |
plot
material properties? 0=no,
1=yes |
int |
- |
0 |
Yes |
verbose |
Verbosity
level (level of screen messages about code execution): 0 = no
print at all 1 =
prints errors and warnings only 2 = 1 +
minimal information 3 = 1 +
more information (remains yet readable) 4 = even
more information
(next
levels for debugging) |
int |
- |
3 |
Yes |
poissonVerbose |
Same as
verbose, but specific to Poisson solver |
int |
- |
3 |
Yes |
These local parameters are scalar fields living either in the volume or on a surface (spacecraft or external boundary). Not all of them are used in the present version of the code. Some come in addition to global parameters that they override when some flag declares that a property is to be considered as local (e.g. turning on an interaction only locally).
They can be defined through the group editor ,
which is launched by the Groups/Group editot menu or the Edit groups button. It allows to define
them group by group (a uniform value on each group).
See the UI documentation for practical usage of
the group editor. We simply edict the basic principles here:
-
in the CAD tool the user
defines:
1.
spacecraft surface
(physical) groups
2.
external boundary groups
3.
volume groups
-
in the group editor, for
each of these 3 types of groups, a plasma must be defined:
1.
a plasma of type spacecraft
for spacecraft surface groups
2.
a plasma of type boundary
for boundary surface groups
3.
a plasma of type volume for
volume groups
These
3 types of plasma must not be mixed (they involve flags telling the solvers
what is the spacecraft or the boundary!). In each of the 3 categories you have
a choice among a few predefined plasmas, and extra ones that you can modify.
Trying to add new plasma through the UI is possible but difficult, prefer
modification of the extra ones (adding a new one is easier in the source code,
see SpisUI/Bin/MaterialMaker.py, where the default materials are defined).
-
for the spacecraft surface
groups only, you MUST also choose a material and an electric node (even though
the electric nodes are not yet used by the solvers, they must be defined).
There again, you have a choice among a few predefined materials and electric
nodes, and extra ones that you can modify (same thing about adding new ones).
The local fields are described now. They are
grouped somewhat arbitrarily as Material, Electric Node, or Plasma properties.
Affecting a given Material, Electric Node, and Plasma to a group affects their
properties to each elements of the group.
NB: Only the properties that should be modified
by the users are described here. You will find a few others in the Material,
Electric Node, and Plasma editors (flags, xyz coordinates
) which should not be
modified indeed.
Material properties
The major parameters are:
-
the material model Id, which
can only be 0 for now, but may be different when other material models are
developed (0, means NASCAP-like i.e. at least based on NASCAP material
properties database
-
the material type Id is an
Id which refers to the temporary default material list in SPIS, which is
currently rather slim:
-
0: ITOC (Material coated
with ITO)
- 1: CERS (Solar cell material. Cerium doped silicon with MgF2 coating)
-
2: CFRP (Carbon fibre,
conducting, no resin layer)
-
3: Kapton
but can be extended easily (see the source
code of ..\API\public\spis\Top\Default\SpisDefaultMaterials.html).
The predefined materials-plasma-electric_node that can be affected to each physical group
are defined in SpisUI/Bin/MaterialMaker.py file, which can easily be
modified (see SPIS/UI documentation on this topic, when available)
Name |
Description |
Unit |
Default
value |
Live on
(spacecraft, external boundary or volume): |
Centring,
or localisation (0=node, 1=edge, 2=surface, 3=volume) |
In use |
MatModelId |
Id of the
material model used for this material |
- |
0
(default model = NASCAP-properties-based) |
SC |
2 |
Yes |
MatTypeId |
Id of this
material in its material model |
- |
-1 (no
coating: bare metal, no interaction (except collection)) |
SC |
2 |
Yes |
MatThickness |
Material
thickness (if defined, overrides the default material thickness defined in
the material properties) |
[m] |
-1 (use
the default material thickness defined in the material properties) |
SC |
2 |
Yes |
PhotoEmis |
If 1,
photo emission is turned on and simulated |
- |
0 (no
photo emission) |
SC |
2 |
No |
ElecSecEmis |
If 1, secondary
electron emission under electron impact is turned on and simulated |
- |
0 (no
electron secondary emission) |
SC |
2 |
No |
ProtSecEmis |
If 1,
secondary electron emission under proton impact is turned on and simulated |
- |
0 (no ion
secondary emission) |
SC |
2 |
No |
If 1,
volume conductivity through the bulk material is turned on |
- |
0 (no
volume conductivity) |
SC |
2 |
No |
|
IndConduct |
If 1, induced
volume conductivity is turned on and simulated (if 0, the raw volume
conductivity above is used) |
- |
0 (no
induced conductivity) |
SC |
2 |
No |
SurfConduct |
If 1,
surface conductivity is turned on and simulated (from the top of a cell to the
next ones) |
- |
0 (no
surface conductivity) |
SC |
2 |
No |
Temperature |
Surface
temperature |
[K] |
300.0 |
SC |
2 |
No |
Sun flux
on spacecraft |
[sun at 1
AU] |
-1.0
(compute it from sun direction, possibly including shades) |
SC |
2 |
Yes |
Electric node properties
There is the only one property resulting of the
choice of an electric node, its
Name |
Description |
Unit |
Default
value |
Live on
(spacecraft, external boundary or volume): |
Centring,
or localisation (0=node, 1=edge, 2=surface, 3=volume) |
In use |
The
electric (super) node this element is related to (SC ground, array ground
) |
- |
0
(default electric node, related to SC ground) |
SC |
2 |
Yes |
Plasma properties
The next ones result of the choice of a plasma,
which was commented in the introduction to this Local Parameters section. Only SCDiriPot, SourceCurrent,
SourceTemp, and SourceMach are in use now.
Name |
Description |
Unit |
Default
value |
Live on (spacecraft,
external boundary or volume): |
Centring,
or localisation (0=node, 1=edge, 2=surface, 3=volume) |
In use |
surfThicknessS |
Thickness
of 2D surfaces (used when surfaces are tagged as thin, their thickness not
meshed) |
[m] |
0.0 |
SC |
2 |
Yes |
edgeRadiusS |
Radius of
1D elements (used when edges are tagged as physical thin wires, their
thickness not meshed) |
[m] |
0.0 |
SC |
1 |
Yes |
SCDiriFlag |
If 1, Dirichlet condition for Poisson equation on SC (fixed
potential) |
- |
1 (yes) |
SC |
0 |
No: set to 1,
always Dirichlet on SC |
SCDiriPotl |
The
potential to be used for Dirichlet condition |
[V] |
0.0 |
SC |
0 |
Yes |
SCFourFlag |
If 1,
Fourier condition for Poisson equation on SC: alpha pot + d(pot)/dn = value |
- |
0 (no) |
SC |
2 |
No: set to 0,
always Dirichlet on SC |
SCFourApha |
Alpha
parameter in Fourier condition: alpha pot + d(pot)/dn
= value |
[m-1] |
1.0 |
SC |
2 |
No: always Dirichlet on SC |
SCFourValue |
Right hand
side parameter in Fourier condition : alpha pot + d(pot)/dn
= value NB: note
the centring different from other Fourier parameters |
[V] |
0.0 |
SC |
0 |
No: always Dirichlet on SC |
BdDiriFlag |
If 1, Dirichlet condition for Poisson equation on external
boundary (fixed potential) |
- |
0 (no) |
Boundary |
0 |
No: set
to 0, always Fourier on boundary |
BdDiriPot |
The
potential to be used for Dirichlet condition |
[V] |
0.0 |
Boundary |
0 |
No: always
Fourier on boundary |
BdFourFlag |
If 1,
Fourier condition for Poisson equation on external boundary |
- |
1 (yes) |
Boundary |
2 |
No: set
to 1, always Fourier on boundary |
BdFourAlpha |
Alpha
parameter in Fourier condition (used if poissonBCType
= 0) |
[m-1] |
1.0 [m-1] |
Boundary |
2 |
Yes |
BdFourVal |
Right
hand side parameter in Fourier condition (used if poissonBCType
= 0) |
[V] |
0.0 |
Boundary |
0 |
Yes |
Id of the
local artificial plasma source defined on the spacecraft: between
1 and sourceNb (=4) to have
source 1 to 4 emitting at this place. Value 0
or negative => no source. NB: only
one source can selected on each mesh element. |
- |
-1 (no
source) |
SC |
2 |
No |
|
Current of
an artificial source defined on the spacecraft (NB: for some sources the unit
can be different, e.g. the particle number, or the total current) |
[A / m2] |
0.0 |
SC |
2 |
Yes |
|
Temperature
of the emitted Maxwellian distribution, if sourceType of the corresponding sourceId (hence sourceType1
where sourceId = 1, or sourceType2 where sourceId = 2, etc.) is a LocalMaxwellSurfDistrib
(if not, the interpretation of this value can be different) |
[eV] |
1.0 |
SC |
2 |
Yes |
|
Source
Mach number (0 => Lambertian), if a LocalMaxwellSurfDistrib.(else different interpretation is
possible) |
[-] |
0.0 |
SC |
2 |
Yes |
|
IncomPart
|
-
If 0, no particle are injected. -
If 1, particles are injected (following the defined environment) |
- |
1
(injection) |
Boundary |
2 |
No |
OutgoPart
|
-
If 0, outgoing particles are lost (sink) -
If 1, they bounce specularly (extra
options possible) |
- |
0 (sink) |
Boundary |
2 |
No |
VolInteracFlag |
If 1,
volume interaction is computed in that region (typically charge exchange) |
- |
0 (no) |
Volume |
3 |
No |
BackgroundDens |
Fixed
background density used to compute volume interaction (typically: neutral
density) |
[m-3] |
0.0 |
Volume |
3 |
No |