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...
