It is now complete and working. I also added some minor improvements to moduleMesh.f90 using 'associate' to practice.
I noticed there are a lot of things (allocating K, for example) that are common for all meshes and should be moved to a general module.
I should've commited before, but I wanted to make things compile.
The big change is that I've added a global time step so the parameter
does not need to be passed in each function. This is useful as we are
moving towards using time profiles for boundary conditions and injection
of particles (not in this branch, but in the future and the procedure
will be quite similar)
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.
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.
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.
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
After some testing and making things a bit better and more general, I am
quite happy with the implementation of vtu and it seems that it is
working (at least as good as Gmsh2).
There are some procedures that might be useful for other XML-like
formats that might be moved in the future to the common module (I am
thinking right now in the implementation of a general format like
XDMF3).
I have tested all geometries and cases and all seem to work perfectly
with .vtu meshes.
Input and output works great, starting from a previous case also works.
Everything I was able to test is okay.
Still, what I want to do is to change a few things in the output (e.g.,
change OUTPUT prefix to Step) and try to improve reading gmsh meshes
to make them more compact as vtu is now.
For some reason the connectivity for collision meshes was not being
properly assigned.
Also, the first subroutine to read information from .vtu files as
initial states has been added.
It is currently giving wrong results.
First complete implementation of .vtu format.
Still a lot of things to improve but right now fpakc can read a vtu mesh
and write the output in vtu.
Still to test:
Multiple geometries.
Double mesh.
Moving forward making vtu an independent format.
Now fpakc can generate nodes and edges from vtu input.
Next step is cells.
Some minor corrections in gmsh2 format to unify statements.
The reading of meshes needs a good overhaul.
Testing all geometries with vtu is gonna be fun...
The average of the species properties can be written now in .vtu format.
No .pvd file is provided as no time series is generated.
Still to do:
Read a .vtu mesh.
Improve gmsh format to use more common functions.
The collisions and EM field information is now available in .vtu files.
A collection file .pvd is provided per dataset for time-dependent
plotting.
Still to do:
Write average quantities in .vtu
Read mesh from .vtu
Testing new VTU format.
For now, species information is ALWAYS output in .vtu (to test, this will
be an independent format in the future).
A .pvd file is produced to do time-series.
Still to implement other outputs (electromagnetic, average,
collisions...)
Still to implement reading a mesh from .vtu file
Finalysing first step of performance improvement focusing on reducing
iteration CPU time by improving calculation of basic element functions,
which took a lot of the CPU time
An issue in the node volume calculation in cylindrical coordinates was
found. This was causing wrong conservation of current. Still to test
with ALPHIE_Grid case.
Still to check triangular element.
Still to theck 1D radial geometry
First implementation of Electromagnetic pusher.
Some testing is still required.
Documentation needs to be upgraded to match the changes in this branch.
The geometry and push structure has been reworked to allow eassy adding
new pushers.
Documentation not updated yet.
Baseline for merging Cartesian pushers into one.
A new option has been added in which MCC are computed with its own time
step.
If no time is provided, then the minimum time step of the simulation is
employed.
Fixed an issue in which the position in triangular an thetrahedron
elements were not correctly being computed.
Other minor issues fixed:
- Units in input file now do not use '/'.
- Collisions accuratly conserve momentum.
- Minor improvements in mass calculation in collisions.
An initial simulation time can be provided in the input file. This is
useful when restarting a simulation from a previous file. If no
initial time is provided, the value 0 is used.
Implementation of the 0D grid to test collisional processes.
An OMP_LOCK was added to the nodes to properly write perform the
scattering (it is weird that multiple threads work in the same node at
the same time, but in 0D happens everytime).
Added a new case to test the 0D geometry.
User Manual updated with the new options.
easy to use a file from a previous run without processing it into a
plain text file.
Although the previous method presented some updates for 1D small cases,
this is quite easy to do with any type of simulations and, in the
future, with different mesh formats.