Just some comments on how I am going to make the desired changes (have a
Dirichlet boundary condition for the electric potential that changes
with time). This might be a good opportunity to rework the boundary
conditions in the electrostatic field and include other things like a
Newmann boundary condition. We will see.
The correction in the node volume is no longer needed as now things are
being calculated right with the last change.
Still, at some point I should review the calculation of the node volume
in 2DCyl.
So the radius for the volume integral in the nodes has to be set with a
1/4 3/4 ratio to match the change in volume as the radius changes along
the volume.
This has a bigger impact close to the edge.
Still unsure if this is the "right" thing to do, but at least it works
okay (it seems).
The manual has been modified to account for the new particlePerEdge
option and to indicate that now when the flux is giving by a flux like
in the Am2 units, the real surface of the inject is used to scale it.
I rewrote how particles are injected. Now the particles per edge and its
weight are calculated in the initialization. There is the possibility
for the user to select the particles per edge.
TODO: Write documentation for new feature.
TODO: Test in 2DCyl
I made some small changes to how things are calculated.
I have also discovered that the issue with different density when
changing injection is not related with the node volume but with the way
injection is carried out. When loading particles from a file, all
provide the same density regardless the cell (node) volume.
I am doing testing in 2DCart as it is easier to set up.
Basically things do not work. I've added a correction to the node volume
in the axis which gives okays results but still this is not perfect. I
need to find a better way to do things.
Also, I've noticed that the density changes with the size of the cells,
which should not happen! I'vw to check this issue.
Trying to have a very simple volume per node assuming a rectangle and
the density at the axis it higher than it should (kinda like when using
the more accurate volume calculation).
This is still weird. I also suspect that the size of the first cell in
the axis will also affect this...
So now each edge has the same number of particles and the weight of each
particle is calculated based on the surface of each edge compared to the
total one.
Only in 2DCyl, still to extend to other geometries.
Not perfect constant density, but the issue might be the node volume.
The number of particles per cell can be defined when giving an initial
distribution fora species. If not, the typical method of using the
species weight is used. This is particularly useful for cylindrical
coordinates in which very little particles might end up in the axis if a
constant weight is used.
Fixed an issue with random integer numbers.
Cylindrical coordinates are not perfect yet:
- Box (cylinder) with initial constant density loses particles at r =
0
- Injection density still low in r = 0
I have to change the injection of particles. Each edge will receive a
similar number of particles and their weight will change to have a
constant density based on the geometry.
Still testing.
I think that the volume of the nodes is not being well calculated, maybe
we need a better volume calculation for this, using multiple points (as
it is done for K)
The random position for edges in the axis is corrected so that there is
a more uniform charge density in the axis.
Still, things are not perfect and this is something to really look into
in the future.
WARNING: This current denstiy will be multiplied by the reference
length, no the surface area that is being used for injection!
New units in the injection of particles 'Am2' to inject a density
current. Manual has been modified accordingly.
Reference parameters are now also printed in the case folder.
Fixing an issue with reading tables led me to other issues with
collisions that I think are fixed right now. I am testing with the 1D
ionization model for ALPHIE and things seems to be working properly.
Coulomb scattering is now fully conservative thanks to the method in
lemos2009small.
The trick was to conserve the momentum and energy of ALL particles
involved in the scattering in each cell.
The substeps in Coulomb collisions have been removed as they are no
longer necessary.
Still some issues with e-i, but I don't know right now.
In an attempt to make the operator fully conservarive I have combined ij
and ji collisions (when i/=j).
Now the matter is to find a way that makes this conserve momentum and
energy for intraspecies.
Now per each Coulomb collision process there is the possibility to do
sub-steps. This helps in improving accuracy without reducing the time
step of the problem.
There was an issue with the calculation of theta and phi for the
rotation from W to C. This was causing some velocities not being
correct.
Now the angles are properly computed. Still unsure about the e-i
collisions as they seem to be quite small. Probably a numerical issue
with the mass ratios still exists.
The code is still not fully conservative in intra-species collisions
(small error) but at least now is working.
I have to test species with different weight.
I have to implement a fully conservation for intra-species.
I had to go back to sherlock2008montecarlo to properly understand the
change in frame of reference and how to translate that into the code.
The language there is clear and understandable for a dumb person like
me.
Now I have a Coulomb linear operator that at least works.
However, still not fully 100% conservative, need to fix this with a
correction for intra-species collisions.
I skip gym today because I was unable to focus on other things than
this.
I was having tones of issues with the previous implementation. I think
the problem was the velocity vector and how it was returning to the
normal reference frame.
I hope this new implementation works better.
I found no way to ensure conservation in the linear Coulomb operator.
Thus, now two collisions have to be declared if sp_i /= sp_j: collision
ij and collision ji.
This does not conserve energy so please use under your own risk, like
everything else.
Still, I think something is wrong with this implementation and I'm
really tired.
