Re: [eigen] Eigen and rigid body simulation

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2009/11/25 Christian Mayer <mail@xxxxxxxxxxxxxxxxx>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Mathieu Gautier schrieb:
>> Hi,
>>
>> I plan to use eigen in one of our library to simulate rigid body in 3D.
>> I have several basic elements (Wrench, Twist, Displacement, etc.) based
>> on Eigen matrix and quaternion which are used to manipulate the rigid
>> bodies velocities, forces, positions, etc. I think that this elements
>> could be added to Eigen as a new module, although, they are quite tied
>> to the geometry module. So, if you are interested I can submit a patch.
>
> Hi Mathieu,
>
> this sounds like a sensible way coming from the Eigen background (i.e.
> geometry).
>
> But when you are talking about linear or angular "mechanics" you should
> also think about its analog applications: thermodynamics and electricity:
>
> force = torque = current = heat transport
> velocity = angular velocity = potential = temperature
> mass = inertia = capacity
>
> The formulas to handle those quantities are exactly the same.
>
> I.e. although most quantites are only 1D (and not 3D like linear and
> angular motion) this is really asking for a generic mechanism to handle
> it. And - so far Eigen could only spend it's expression templates - it
> might be a good usecase for the solving methods of Eigen.
>
> But in either case (only mechanics or generalized) I think it's out of
> the scope of Eigen. It's a good usecase though.

As usual, it's really hard to say whether a proposed new module is in
the scope of Eigen, if it should be accepted in "unsupported", etc...

Yesterday a little conversation happened on IRC, let me paste it below...

About your concerns, if I understand well, you're saying that if we
start having mechanics stuff we may just as well have thermodynamics
stuff because the underlying concepts are the same, and then that's
clearly out of the scope of Eigen.

But I would reply to that 2 things:
1) Mechanics is special among physics topics in that it is very close
to geometry; the frontier between geometry and Mechanics is fuzzy
enough.
2) This mechanics stuff is something that is quite likely to be useful
to many Eigen users, seeing how many of Eigen users are using it in
robotics/engineering. We already have several known users who do
mechanics with Eigen; I don't know anybody doing thermodynamics with
Eigen.

Finally, as was mentioned in the IRC conversation pasted below, there
always was an ambiguity in unsupported/ because it is 2 things:
- a staging area for new stuff until it is ready to be supported
(mature enough and enough potential users)
- a place for extra stuff useful to Eigen users but that we don't want
to have to support. Here we're squarely using the fact that thanks to
being a template library, we can have that at a very small cost ---
just some disk space on the developer's side.

I'll start a wiki page on that....

Anyway I'm not opposed to having that in unsupported.

The alternative might be for Mathieu to start his own mechanics
(template) library that requires Eigen as a dependency.

Cheers,
Benoit

IRC log:

<gael> I think this is what unsupported/ is ment for
<gael> a place to share code related to Eigen
<orzel> gael: mm, depends, at least some of the modules in unsupported
are meant to migrate in core
<gael> yes, if they become useful, mature enough, and with a reliable maintener
<gael> but I don't think this should be a necessary goal for all
unsupported modules
<orzel> gael: but a module such as the rigid body stuff would never go
to core, that's not the place where it belongs
<gael> sure
<orzel> i see what you mean
<orzel> maybe we should have a place for "stuff to mature before going
to core" , and another one for "application specific stuff"
<gael> but might still be interesting to make it easily available to
everybody (I'm speaking in general)
<moritz_> ext/ and incubator/ :-)
<orzel> the problem is that most of the time, people put stuff in
there, and kind of dissapear
<bjacob> orzel: if it's unsupported and they disappear, in the worst
case we can simply remove the code
<bjacob> that's the nice thing with it being unsupported
<orzel> yes, but it also bloats the repository
<orzel> not a big concern, sure




>
> CU,
> Chris
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEAREIAAYFAksNpvIACgkQoWM1JLkHou0TTwCgkR/q4Nq5ciF0Jn57sF4r5PB7
> tugAn3Rr42Z000gJJYWPSDYijSd66Fzn
> =zO+Q
> -----END PGP SIGNATURE-----
>
>
>