Can you provide recommendations on how to debug "Positive directional derivative for linesearch"?

Question

I've been trying to get a dynamic optimization working using dymos, but my optimizations routinely fail with the following error: "Positive directional derivative for linesearch". From what I understand, this error is common if the optimizer cannot identify a feasible solution because of constraint violations or poor variable scaling. My questions are below.

1. How would you recommend debugging this error for a dymos problem? Specifically, how would I determine which constraints are not satisfied? I'm aware that the driver has a debugging option for printing constraints, but for dymos problems, I have hundreds of constraints and that information is a nightmare to parse.

2. I checked the scaling report using p.driver.scaling_report() and many of the dymos collocation and continuity constraints have very poor scaling (I'm looking for the scaled value to be on the order of 1). I've provided the constraints output of the scaling report below. How do you recommend setting ref for the collocation_constraint and continuity_comp constraints? Is it typical to have those constraints scaled in the same way as the design variables? Can scaling even be applied to the continuity_comp constraints?

If the extra information helps, I'm using the SciPyOptimize Driver with SLSQP optimizer. Thanks in advance.

Answer 1

check_partials() are good with relative error order <=10^-6

Sometimes you can have good looking partials around your initial contidition, but they are incorrect when you move away to another point. Often this happens if you defaulted an input to 0 or set an initial condition to 1 and that creates a special case where derivatives simplify and your mistakes get hidden. As an extra double sanity check, I suggest you add a small bit of random noise to at least a few of your inputs and double check your partials.

Its pretty rare for check_totals with FD to tightly match the analytic models, so a small bit of error is expected. You could try switching to CS for the totals. Things should match well then, unless there is a complex-step problem non compatible calculation somewhere in your code.

Another possibilility is that you have an incorrect linear solver setup in your model somewhere. Do you have any NonLinearBlockGS solvers in your model? If yes, did you also add a linear solver to that same group (probably a DirectSolver).

If you show us a XDSM zoomed into your ODE, we can sanity check it. If you can post a gist of your model, it would be easier to give more targeted advice.

As for your question about the value of ref. Scaling constraints to around 1 is a decent starting point. if your nominal constraint value was about 10, then set the ref to 10 and you'd get a scaled value of 1. Id have a look at the actual derivative values though. Are the super tiny? Super massive? As a second iteration of scaling, I normally aim to bring all the derivatives to be within 4 or 5 orders of magnitude of eachother.

One last issue you might consider. Dymos models typically rely heavily on the total derivative coloring for good performance. There are some relevant papers on why this is valuable here and here. The coloring system relies heavily on sparsity information provided by the partial derivatives of components. Depending on how you provided your partials (perhaps as dense matricies with diagonal values) you might be getting bad coloring. To sanity check this, you can turn off the total derivative coloring and re-run your optimization. If it works, that gives you a hint. Id consider switching to sparse partial derivatives at that point.