Bringing automatic differentiation to Simbody through ADOL-C

[antoinefalisse]

We have transformed part of Simbody to enable the use of automatic differentiation using ADOL-C which is an operator overloading tool. The key concept is the introduction of an active scalar type called adouble whose real part is of the standard type double. All variables that may be considered as differentiable quantities should be declared as active and have adouble as data type.

We are wondering what should be the best way to bring all our changes to Simbody. @chrisdembia suggested to create a branch autodiff where we could progressively bring our changes through pull requests. Would that be an option?

The approach we have followed so far is that we assigned Real to adouble instead of double. In some cases, this does not require any further changes. In other cases, this requires adding cases (e.g. cases in NTraits such as Widest, Narrowest, isNumericallyEqual). To make sure our changes do not affect the original Simbody, we defined through CMake a pre-processor SimTK_REAL_IS_ADOUBLE and introduced our changes for instance by doing:

#ifdef SimTK_REAL_IS_ADOUBLE 
    template <> class NTraits<adouble>;
#endif

Is that a valid option? In brief, the users would have the possibility, through CMake, to build the libraries using ADOL-C (this would be a third case after shared and static) and that would assign Real to adouble.

Also, some parts of Simbody are not differentiable or are, currently, not transformed to be used with ADOL-C. This is the case for contact models but also when using Lapack, optimizers, or integrators. The approach we are following is that we would return a run time error if users are trying to use these features with automatic differentiation. Is that a good idea?

We have also developed a differentiable contact model which could be used with automatic differentiation. We are planning to bring it to Simbody (as a new class of SimTKsimbody).

Our proposed timeline would be to have one library merged per month starting in October so that the code would be fully integrated in this new branch by the end of December. We would divide each library in a certain number of pull requests (e.g. one per week). This is of course only a suggestion :)

[chrisdembia]

Great summary @antoinefalisse. Another question is whether the runtime error when using Lapack with adouble should (a) always be thrown, or (b) should only be thrown if ADOL-C is "taping" (that is, if the user intends to perform a derivative calculation). Approach (a) is likely easier but requires commenting out lots of tests when compiling with adoubles, while, with (b), we could get all the tests to compile even with adoubles (since the tests will not attempt to perform derivative calculations).

I've created a feature branch feature_adolc.

[chrisdembia]

@antoinefalisse submitted the first PR for this feature ( #588 ). It would be nice to set up Travis to build with BUILD_ADOLC_LIBRARIES=on.

I can try to set that up once #588 is merged.

It might be as simple as sudo apt-get install libadolc-dev (or whatever the name of the package is) and cmake ... -DBUILD_ADOLC_LIBRARIES=on.

[antoinefalisse]

@chrisdembia , isn’t it going to be a problem that Travis will try to build Simbody with Real as adouble but without all adolc-related changes having been merged yet? For instance, issuing the next PR with the changes in common.h will set Real to adouble but the libraries will not compile since all the other changes are needed. Or is there another way to proceed?

[chrisdembia]

Ah right. Maybe we can do without it then. Alternatively, we can add an adouble build and let it fail, but just ensure that it failed the way we expected.

We could also alter the adouble build to only build the parts that we think will work (e.g., only compile SimTKcommon_adolc).

Setting up Travis is a low priority though.

[arocchi]

I wonder how long of a step it would take to propagate the AD feature up to OpenSim to finally have CaSaDi-powered muscoloskeletal optimal motion synthesis :P

[antoinefalisse]

@arocchi, we have that working locally (Simbody and OpenSim with AD through ADOL-C and interface with CasADi) and we are now working on making the code available (see https://github.com/simbody/simbody/tree/feature_adolc). This might still take a little while though.