Why GeometryData is not a template class of scalars?

[cmastalli]

I would love to run updateGeometryPlacements with different scalars. And, as you might be aware, this is not possible. The reason is that GeometryData is not a template class.

When inspecting, I can see that there is a context scalar.

pinocchio/include/pinocchio/multibody/geometry.hpp

Lines 233 to 239 in c0bbd6c

	struct GeometryData
	: NumericalBase<GeometryData>
	, serialization::Serializable<GeometryData>
	{
	EIGEN_MAKE_ALIGNED_OPERATOR_NEW
	typedef context::Scalar Scalar;

However, I am unaware of the design choice behind this.

Would you be happy to make this GeometryData a template class?

[cmastalli]

To add a bit of extra detail, the problem comes in line

pinocchio/include/pinocchio/algorithm/geometry.hxx

Line 48 in c0bbd6c

geom_data.oMg[i] = (data.oMi[joint_id] * geom_model.geometryObjects[i].placement);

. However, I suspect there is much more than this.

I am happy to contribute to this if you provide general guidance.

[jcarpent]

The first question you need to ask is: why do you really need to have GeometryData to be templated?

[jcarpent]

Part of this effort is also to finish the work started by Rohan.

Which work do you mean here? In Crocoddyl you mean?

[cmastalli]

loco-3d/crocoddyl#1081

[cmastalli]

However, I am not doing it exactly as described there.

[jcarpent]

Concretely, there is a compilation error as data.oMi[joint_id] uses a float while geom_data.oMg[i] uses a double.

We did not templatized Geometry{Model,Data} because coal is not a templatized libraries. It has no meaning to do automatic code-generation or automatic differentiation over all the types of geometries supported by COAL.
Yet, with @lmontaut, we are thinking on supporting floating precision for COAL. But we will do in a non-templatized way to save our time and limit bad computational behaviors.

[cmastalli]

That sounds good! I am still interested in handling different floats, and this is what I am doing right now.

I might find a way to handle this with a non-templatized approach.

• @lmontaut could you describe briefly how you think to do this?
• @jcarpent what do you mean with "bad computational behaviors"?

[jcarpent]

Loss of numerical precision and related convergence issues