Very nice. this was the sign I was expecting.
Anyway for next time you can just give directions so that we can implement things the way you like, speeding up the improvements and needed changes.
At this point I suppose the C or Fortran implementations are not needed anymore.
So now the function can be included in geomtools.levelVolumes,
be called in Mesh.levelVolumes or just be called directly?

In 7e4122a a new function geomtools.hexVolume was added computing the volume of hexahedral elements using the formulas mentioned in https://savannah.nongnu.org/bugs/?45061#comment12
This results in a tremendous speedup of the volume computation in large models (probably the conversion takes a lot of time?):
The new function should be used to compute the volume for all hex type elements. Maybe more accurate formulas can be derived for hex20/hex27.

In b1a81c7 arraytools.vectorTripleProduct was changed to use a determinant formula, resulting in an important speedup on large datasets. Here are results for 1 to 10 million tetrahedrons.

What sign do you expect?
I first need (a lot) more information on what you want/need.
 individual result for every element?
 how accurate?
 how much faster?
Then we need to profile the current code and see where the most time is spent.
Possible ways for speedup:
 Using formulas like in http://www.osti.gov/scitech/servlets/purl/632793
 Implement these (or the current) algorithms in C
 Use numerical integration (with low or high accuracy). Implement these in Fortran (as I have them already, just need to adjust and construct interface).

In commit 36adca0 the function meshQuality has been added to compute all vtk quality measures.
Now if we like we can call this function for some specific measures (like vtkVolumes ) as Gianluca suggested , but I think we should not add many.
For the volumes I still think we should find a way not to use vtk.
Benedict can you give a sign on this?

Gianluca regarding to teh vtk*Quality
I would use the MeshQuality instead of the CellQuality.
the Mesh quality return derived measures as well which can be useful.
we can just use quality parameter as a string and use the eval function with no checks ( up to the user to select the correct one) to keep the function very short, something like this pseudo code
def meshQuality(mesh,quality):
convert to vtkobj
elname = get the elemnt vtk name (Hex,Triangle ect )
q = vtkMeshQuality(vtkobj)
eval('q.Set' + elname + 'QualityMeasureTo' + quality +'()')
q.Update()
get the quality array
and we avoid to add as many functions as the quality measures.

I would not do like you said
I have already implemented the mesh quality functions based on the jacobian and the norms. I will put them as soon as possible after I finish the tests and I write the paper on the mesh quality improvemnet based on that.
this vtk things would be just a temporary solution for some stuff not included in pyformex, a general evaluateMesh will be more compact and we will not add so many different functions. this way teh user ask directly what he needs otherwise eveytime we need something from the _vtkCellQuality we will keep on adding specific functions that call it. beside I think it is a
easy way just to use a evaluateMesh(mesh, quality). and we keep it as you said with no converisons as teh user can do it outside the function.
For teh volumes in vtk I remember I read something once but I might be wrong or maybe it is not a problem anymore

Hi Francesco,
I would propose the following:
 create a function in vtk_itf.py to use the vtkCellQuality with tri/quad/tet/hex and with all types of quality (including volume).
I suggest the name "_vtkCellQuality", with underscore
In this function I would not introduce conversions, but leave as it is in vtk, because conversion are planar approximations.
 create more specific functions to check a specific metric
I suggest the name "vtkVolumes", "vtkScaledJacobians"
Btw, why do you think that vtk volume is wrong? If you sum all the vtk volumes you get the correct total volume. I think that vtk uses a different way to compute the volumes which is not necessarily wrong, but it is different in case of warped quads. Splitting quads into triangles is only an approximation. The read quad surface is probably the ruled surface, which is curved.

I think with our own c++ functions with can have faster computation of volumes,
The correct results is the one in pyformex but
with the conversion to tet4 and then using the vtkTet* instead of the vtkHex* methods the results are the same. I did not cjheck for the quad
I think we can introduce this function in the vtk plugin for all the additional information still lacking in pyFormex.
Maybe we can introduce a function that wraps the vtk one like
evaluateQuality(mesh, targetQuality):
and make some due conversions of quad and hex first in pyformex to and tri3x and tet4
Still an improvement of the pyformex functions is needed.
Gianluca will you do the additin to vtk?

Hi,
Very interesting topic. We really need some quality metrics for (large) meshes. It seems that a lot of metrics are ready for us in VTK. Please run the attached script (volume of hex elements is 3x faster with vtk). I think we should create one general pyFormex interface function to vtk.vtkMeshQuality()
Regarding hex volumes:
Volume is indeed strange for hex elements because of the nonplanarity: vtk and pyformex return different volumes in case of nonplanar faces (including negative volume elements).
 Minor issue in the current pyFormex implementation:
hex.volume() and sum(hex.volumes()) return different values if there are nonplanar faces on the border, because
 volumes() goes through tet424 to a tet3x border
 volume() uses a tet3u border
(file #33984)

following the comment of Gianluca
indeed the computation with tet5 will be accuarate only with plane faces so indeed we need another solution.
Though I need this to be improved, if you can give me the input to improve it with additional libraries please do, I will work on it and send it back to you. I have a code that needs many calls to volumes and this call slows it down a lot. So please give mehints on how to proceed

I suggest we leave the volumes computation like it is (for now).
The educated user can use the approximate hex8>tet45 speedup himself when he wants.

Hi Francesco,
 Regarding the element volumes:
if you use hex8>tet45 and you sum up the element volumes you do not get the correct total volume. The reason is that the face shared by two faceadjacent hex elements could be split in 2 tets using two different diagonals, producing a nonconformal tri3 mesh at the interface. If the shared quad4 face would be warping the tri3 meshes of the two hex may have gaps or intersect each other. The only subdivision which guarantees conformity is the tet24. Of course, if you need a fast computation of all volumes to assess the element quality you do not care about warping, so an approximated volume would suffice, using the hex8>tet45, but you should be aware that the sum of the volumes is not the total volume
 Regarding the mesh volume:
what Benedict suggested is already the standard in mesh.py and it is indeed very fast:
3dmesh > getbordermesh > convert to tri3 > surface_volume

Hi Benedict I dont even know what calpy is, so if you can start to include the libraries it would be easier.
Later we can start implementing our own and you could send me the functions to be converted in c++ to help you in this

For the total volume, I would use
3dmesh > getbordermesh > convert to tri3 > surface_volume
For individual volumes of elements, we can best implement direct formulas based on the shape functions. We have them available in calpy and calix(fortran), could be ported to pyformex, possibly even in accelerated form. Or we reimplement them in our Clibrary.

The default conversion for to tet4 is tet424
if we use tet45 teh computational cost will be reduced of 5 times. the problem is that the function uses as default the conversion to the base name 'tet4'.
Possible solutions
1 Either we add a new element conversion to all elements that calls the conversion with the minimum number of tets (eg. 'tet4min' ) so if the element type is not 'tet4' we always convert to 'tet4min'
2 add exception in the Mesh.volumes
if self.elName() == 'hex8':
base = 'tet45'
3 use the inertia.surface_volume for all 3D elements. though I tested it and it works, the results are less accurate on an element base and it is a bit slower than the 'tet45' conversion
Additionally we could use the inertia.surface_volume to compute the total volume of the 3D mesh, which would much faster
