Automatic naming of tensor components

@fredrik would like to introduce automatic naming of tensor components:

See this discussion:

And this MR:
https://gitlab.kitware.com/paraview/paraview/-/merge_requests/5442

There is already automatic naming of 6 component symmetric tensor like this:
"XX", "YY", "ZZ", "XY", "YZ", "XZ"

But it appears that there is no such standard for 9 component tensor, and that even this 6 component mapping could also be considered without any standard.

For 9 components, there is two suggestions:

  • XX XY XZ YX YY YZ ZX ZY ZZ
  • "XX", "YY", "ZZ", "XY", "YZ", "XZ", "YX", "ZY", "ZX"

Does anyone have any inputs on this ?

I personally don’t think the specific ordering is very important as long as it is documented. If the chosen order is clearly documented it is after all very easy to do the permutation when doing the export.

The current situation is that you need to consult the application that produced the VTK file to find which order is used (even in the case of symmetric tensors). Quite likely they simply export in the order of internal storage of these tensors, which might not necessarily be the same as the convention used in ParaView, and then the existing labeling might be wrong. This is what our code used to do until recently Ferrite-FEM/Ferrite.jl#383. Before this patch tensors where exported in the storage order of the tensors library so in this case ParaView “mislabeled” the data.

I think that, if ParaView picks a order, any order, then applications can adjust to this quite easily when exporting the data, as in the linked pull request above.

1 Like

I personally don’t think the specific ordering is very important as long as it is documented.

The problem is that as soon as your changes is merged, users using a different convention will be presented with misleading component labels instead of the neutral numbering we have now.

True, but that is already the case for symmetric tensors – just because ParaView adds labels there is no guarantee that the exporter used that ordering.

I agree, and I mean to say that maybe the automatic naming of symmetric tensor is already confusing people. I added the naming some years ago thinking it was considered standard.

Right, and I would be perfectly fine if the existing labeling of symmetric tensors were removed.

Probably the best thing would be for the exporter to include ordering or custom labels as metadata in the VTK file, and then ParaView would look that up (defaulting to enumeration). But perhaps that is not currently possible.

I’ve answered there to be more precise, but since this is supported by the vtkDataArray api, it is a matter of file formats, not VTK/ParaView directly.

The solution given in Data array multi-component labelling - #11 by mwestphal is perfect for me. Perhaps the automatic labeling should be removed then, and users can put names in the file itself such that the information in the file is complete without having to look at the order of the exporter.

What is the current meaning of the 0-8 indices?

I would have thought ordering by indicial notation (ξij) would be the most logical.
11, ξ12, ξ13, ξ21, ξ22, ξ23, ξ31, ξ32, ξ33) <==> (XX XY XZ YX YY YZ ZX ZY ZZ)

although for a symmetric tensor I would expect
XX YY ZZ XY YZ ZX

Alternatively you could always show 9 components regardless of symmetry.

XX YY ZZ XY YZ ZX

This is the current naming scheme for unammed 6 component arrays, (almost, last one is XZ, but the same value)

XX XY XZ YX YY YZ ZX ZY ZZ

This is my suggestion exactly and seems logical to me. It would be nice to have more inputs though.

1 Like

Does this match the 0-8 indices currently?

Currently, there is no automatic componant naming for 9 components array.

Yes. I realise that but surely each index in the drop down box still refers to a particular component?

Each component correspond to each component in the order they are defined. It could even not be a tensor but just a 9 component array.

1 Like

In that case I think letting the user configure their own string array to map each index to a label would be better than hard coding a solution.

I agree. No matter what choice is made by ParaView you can not be sure that it matches the ordering used for the export. This is already the case with the symmetric matrices. Since it is possible to encode custom names in the file, maybe it is better to point to that, and completely remove automatic naming (also for the existing symmetric case).

For my own case, I have already now implemented custom naming in the file exporter I use, so personally I don’t really have an interest in the automatic naming now since I can encode it directly in the file.

1 Like

Indeed, the right resolution for this could be a filter that lets user set the names of the components, ideally with a default naming scheme based on the number of components.

Well, I think we will not change anything and just close your MR unless someone as other inputs.