# Automatically Getting Derivatives of a Function in Dymola

In a prior post, I wrote about manually specifying derivatives of a function in Dymola. This is necessary in certain cases, especially when external code is used. For the simple function I used in that post and many functions like it, however, there is actually a much easier answer.

## The ‘smoothOrder’ Annotation

Here is the model from before that could not be differentiated:

The ParticlePath function above produces a scaled sine wave, something Dymola could easily differentiate under normal circumstances. Running this code, however, produces the infamous “Failed to reduce the DAE index error.” The reason is that in general, it is extremely difficult to verify whether imperative code (i.e. code in an algorithm section), which can have loops and conditional branches and reassign variables, can be validly differentiated. The function might have a big discontinuity in it. Dymola plays it safe by refusing to do so.

We know that ParticlePath is easy to differentiate, however, and the good news is that we can tell Dymola that. Adding the smoothOrder annotation to our function, as below, will let our model compile.

The number after smoothOrder indicates how many times the function can be differentiated and still get a continuous result. A value of one would mean that the first derivative of the function is smooth, and if the first derivative is smooth it is safe to take up to two derivatives. Setting smoothOrder=0 tells Dymola the function is smooth but its derivative is not, so it is only safe to take a first derivative. For our function above, no matter how many derivatives you take the result will be continuous, so we just put in an arbitrarily large number. A value of nine will let Dymola take more derivatives than we should ever need.

If you have ever used smooth() in the equation section of a model, you may note that the smoothOrder annotation works the exact same way.

## Multiple Derivatives

We told Dymola it is safe to take a whole bunch of derivatives, so let’s test it by computing acceleration:

As a reminder, for a smoothOrder of n, Dymola will happily take n+1 derivatives. So for the code computing acceleration here, any function with smoothOrder=1 or greater will work, but smoothOrder=0 will not translate.

## Conclusion

By default, Dymola will not differentiate a non-inlinable function. In many cases, the smoothOrder annotation is all that is needed to let Dymola take one or more derivatives. Such automatic differentiation is convenient and reliable, as long as the function is genuinely differentiable, and there is not some other factor such as external code blocking the differentiation. If, after adding smoothOrder, Dymola still cannot take a derivative, or a faster calculating approximation of a derivative is desired, there is the option of specifying a derivative manually.

Written by: Joseph Henning – Software Engineer

Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion