Hello there 👋 I'm writing regarding the following admonition in the docs :)

I am solving optimal-control problems where the dynamics are encoded in the form of a ModelingToolkit model. ModelingToolkit can generate very efficient code for the right-hand side of the dynamics, i.e., I can obtain an executable function $f$ in
$$\dot x = f(x, u)$$
where $x$ and $u$ are potentially high-dimensional (length(x) == 10) in the particular example I'm working on right now).
Tracing through $f$ with JuMP variables (infinite variables) "works", with plenty of hacks, but the result is very slow (the traced expression for $\dot x$ is too large to even print to the REPL without crashing julia, while evaluating the code generated by MTK takes 1µs only). The issue is that the code emitted by MTK contains tons of common sub expressions and inlined solutions of linear systems etc ($f$ is the dynamics of a high-dimensional multibody system), this is all handled very efficiently in $f$, where memory for solving the linear systems is manually allocated and freed etc. making $f$ GC allocation free.
To avoid explosive expression growth when tracing through $f$ with JuMP variables, I replace the linear-system solves x = A\b that appear in $f$ with the following
x = InfiniteOpt.@variables(m, begin
[1:n], Infinite(τ) # Temporary anonymous variables
end)[1]
lhs = A*x
@constraint(m, lhs .== b)
bout .= x
i.e., I introduce temporary variables x and equality constraints A*x == b. As I said, this works, but memory requirements are sky high and I believe it should be possible to improve the performance by at least 1000x over the performance this gives me.
Coming back to the admonition, I have been thinking about different ways to work around the limitations on vector-valued nonlinear functions but haven't found any alternative that is working out for me. What approach did you have in mind with
However, this limitation can readily be removed if there is a use case for it
?
I am willing to jump through quite a few hoops to make this efficient if required :) Thanks for your time!
Hello there 👋 I'm writing regarding the following admonition in the docs :)
I am solving optimal-control problems where the dynamics are encoded in the form of a ModelingToolkit model. ModelingToolkit can generate very efficient code for the right-hand side of the dynamics, i.e., I can obtain an executable function$f$ in
where$x$ and $u$ are potentially high-dimensional (length(x) == 10) in the particular example I'm working on right now).
Tracing through$f$ with JuMP variables (infinite variables) "works", with plenty of hacks, but the result is very slow (the traced expression for $\dot x$ is too large to even print to the REPL without crashing julia, while evaluating the code generated by MTK takes 1µs only). The issue is that the code emitted by MTK contains tons of common sub expressions and inlined solutions of linear systems etc ($f$ is the dynamics of a high-dimensional multibody system), this is all handled very efficiently in $f$ , where memory for solving the linear systems is manually allocated and freed etc. making $f$ GC allocation free.
To avoid explosive expression growth when tracing through$f$ with JuMP variables, I replace the linear-system solves $f$ with the following
x = A\bthat appear ini.e., I introduce temporary variables
xand equality constraintsA*x == b. As I said, this works, but memory requirements are sky high and I believe it should be possible to improve the performance by at least 1000x over the performance this gives me.Coming back to the admonition, I have been thinking about different ways to work around the limitations on vector-valued nonlinear functions but haven't found any alternative that is working out for me. What approach did you have in mind with
?
I am willing to jump through quite a few hoops to make this efficient if required :) Thanks for your time!