add edm4eic::Tensor

[veprbl]

This adds a new type that facilitates exchange of tensor data for ML applications.

[simonge]

I had some comments on this but answered them myself while writing this out, I've added them here anyway in case it's useful but otherwise the type looks fine.

• If we want to make use larger batch inference we could use the folder/unfolder to stick together a bunch of events. This would add another variable dimension ontop of the event size batch. Admittedly this could be flattened out for running the inference and handled by the folder.
• Any batch treatment of a graph neural network or other variable size input requires a non-static dimension. I remembered this is passed to the inference as a separate tensor, keeping track of how the data tensor is divided up.

[veprbl]

This is a good topic. My comment is that the current implementation in EICrecon PR does batch inference. As far as EDM is concerned, there is no difference between batch and single item evaluations, all tensors are supposed to have a concrete shape. ONNX model and the converters from/to-tensor are the one that have to know. Convertors obviously need to do the batching, and, like you say, folding unfolding, indeed is a possibility. For the second point, this is new to me, sounds like this is jagged tensor implementation. I'm not sure that ONNX models are coded like that, it actually supports "sequences" of tensors, which are more likely to be used, according to my intuition. Support for those may require another type in the EDM with a vector member for edm4eic::Tensors.

[simonge]

I have a demonstration model which (currently poorly) predicts the position and time of a hit from a varying sized collection of pixel hits. Here the model takes a tensorflow ragged tensor input and can be exported using the tf2onnx package:
https://github.com/simonge/AllpixFastSim/blob/GNN/MakeModel/train_predictor_gnn.py#L80

The model actually ends up taking two input tensors of different types. The first is just a float32 containing the input values and the second gives the position in the value array where different pseudo-clusters are separated as an int64.
https://github.com/simonge/AllpixFastSim/blob/GNN/TestModel/plot_input_resolutions_gnn.py#L127

From what I see, I believe this would be completely compatible with the data type and onnx inference algorithm you currently have.

[ruse-traveler]

LGTM! I'm happy with this as is, but I wonder if might want to add additional element types down the line... For example, I can imagine having a bool (elementType==9) might be useful for some ML classifiers.

[veprbl]

LGTM! I'm happy with this as is, but I wonder if might want to add additional element types down the line... For example, I can imagine having a bool (elementType==9) might be useful for some ML classifiers.

I'd like to avoid the bool. It's probably useless (no existing exporter will use it) and might present an edge case when we add any kind of support for zero-copy.