El camino I Siempre he pensado en esto:
Imagina que tienes dos objetos móviles unidos por un muelle. Cuando un objeto se mueve, estira el muelle, lo que hace que el otro objeto se mueva. Ahora puedes elaborar un sistema de ecuaciones diferenciales que describa todo esto, e integrarlo numéricamente para averiguar qué hace el sistema. (En realidad, un sistema este trivial podría incluso admitir una solución de forma cerrada).
Ahora imagina que coges el muelle y lo sustituyes por una barra de acero.
Científicamente, una barra de acero es como un muelle: se puede estirar y aplastar. Pero prácticamente la deformación real de la barra va a ser minuto . (A menos que se trate de fuerzas realmente enormes).
Básicamente, lo que estás diciendo es que una barra de acero es sólo un muelle con un increíblemente grande constante del muelle. En otras palabras, la barra de acero es un "muelle rígido".
Ahora piensa en cómo vas a resolver eso numéricamente. Con un muelle "normal", cuando mueves un extremo, el otro oscila un poco y finalmente se estabiliza en la longitud natural del muelle. Cuando mueves una barra de acero, ¿qué ocurre? en el mundo real es que el otro extremo alcanza instantáneamente el equilibrio. Lo que ocurre en la simulación es que la enorme constante del muelle hace que el sistema oscile como un loco, y hay que dar pasos minúsculos, minúsculos, para hacerlo converger al equilibrio correctamente.
En resumen, los sistemas rígidos son un dolor para resolver numéricamente. De hecho, mientras leía un tutorial de nVidia (?) sobre integración numérica, daban el siguiente consejo para tratar con sistemas rígidos: "Intenta que no sean rígidos. Si no lo consigues, utiliza métodos implícitos. Buena suerte con eso..."
Esto no es una "definición", pero debería darte una idea de la intuición que hay detrás del término. (A no ser, por supuesto, que esté completamente equivocado... En ese caso, seguro que alguien lo dirá).