Occasional extreme number of line searches

[BenVanDerMeer]

I have a small (3 design variable) optimisation problem that typically is successfully solved by Ipopt. A typical solve (say 80% of the time) looks something like this.

iter    objective    inf_pr   inf_du lg(mu)  ||d||  lg(rg) alpha_du alpha_pr  ls
   0  2.4184510e+02 0.00e+00 2.07e+01   0.0 0.00e+00    -  0.00e+00 0.00e+00   0
   1  2.5507791e+02 0.00e+00 4.41e+01   0.5 3.11e+00    -  1.00e+00 7.29e-02f  2
   2  2.4726852e+02 0.00e+00 2.35e+01   0.5 1.03e-01    -  1.00e+00 1.00e+00f  1
   3  2.4432246e+02 0.00e+00 2.32e+00  -0.2 1.00e-01    -  1.00e+00 1.00e+00f  1
   4  2.4292590e+02 0.00e+00 1.47e+01  -0.9 6.31e-02    -  8.46e-01 1.00e+00f  1
   5  2.4091377e+02 0.00e+00 1.46e+01  -0.9 1.70e-01    -  1.00e+00 5.43e-01f  1
   6  2.4277467e+02 0.00e+00 2.05e+01  -0.3 1.61e-01    -  1.00e+00 1.00e+00f  1
   7  2.4096498e+02 0.00e+00 1.88e+00  -0.4 1.03e-01    -  1.00e+00 1.00e+00f  1
   8  2.4057993e+02 0.00e+00 3.89e+00  -1.1 1.77e-02    -  1.00e+00 1.00e+00f  1
   9  2.4054155e+02 0.00e+00 9.40e-01  -2.6 1.27e-02    -  1.00e+00 1.00e+00f  1
  10  2.4052964e+02 0.00e+00 5.26e-02  -3.6 4.00e-03    -  1.00e+00 1.00e+00f  1
  11  2.4052947e+02 0.00e+00 5.35e-03  -5.6 1.85e-04    -  1.00e+00 1.00e+00f  1
  12  2.4052947e+02 0.00e+00 5.32e-06  -7.7 1.07e-05    -  1.00e+00 1.00e+00f  1
  13  2.4052947e+02 0.00e+00 6.62e-09 -11.0 2.48e-08    -  1.00e+00 1.00e+00f  1

And Ipopt exits with "Optimal solution found". Other times (say 20%) the output looks something like this

iter    objective    inf_pr   inf_du lg(mu)  ||d||  lg(rg) alpha_du alpha_pr  ls
   0  2.6205082e+02 0.00e+00 1.00e+02   0.0 0.00e+00    -  0.00e+00 0.00e+00   0
   1  2.5337200e+02 0.00e+00 4.38e+01   0.9 8.23e+00    -  1.00e+00 1.11e-02f  2
   2  2.4868123e+02 0.00e+00 1.77e+01  -0.1 6.70e-02    -  9.96e-01 1.00e+00f  1
   3  2.4100734e+02 0.00e+00 3.87e+01  -0.8 3.10e-01    -  1.00e+00 5.71e-01f  1
   4  2.4085489e+02 0.00e+00 5.05e+00  -0.8 3.20e-02    -  1.00e+00 1.00e+00f  1
   5  2.4070806e+02 0.00e+00 2.68e+00  -2.3 1.49e-02    -  1.00e+00 1.00e+00f  1
   6  2.4063063e+02 0.00e+00 1.03e+00  -3.9 4.09e-03    -  1.00e+00 9.45e-01f  1
   7  2.4062953e+02 0.00e+00 2.02e-02  -5.8 1.70e-03    -  1.00e+00 9.38e-01f  1
   8  2.4062952e+02 0.00e+00 4.24e-04  -6.9 9.11e-05    -  1.00e+00 1.00e+00f  1
   9  2.4062952e+02 0.00e+00 1.64e-05  -9.0 1.54e-06    -  1.00e+00 1.00e+00f  1
  10  2.4062952e+02 0.00e+00 1.23e-07 -11.0 7.36e-08    -  1.00e+00 1.00e+00f  1
  11  2.4062952e+02 0.00e+00 6.16e-08 -11.0 6.82e-10    -  1.00e+00 5.00e-01f  2
  12  2.4062952e+02 0.00e+00 5.39e-08 -11.0 3.45e-10    -  1.00e+00 1.25e-01f  4
  13  2.4062952e+02 0.00e+00 5.22e-08 -11.0 3.02e-10    -  1.00e+00 3.12e-02f  6
  14  2.4062952e+02 0.00e+00 5.22e-08 -11.0 2.92e-10    -  1.00e+00 4.20e-286h949
  15  2.4062952e+02 0.00e+00 3.19e-10 -11.0 2.92e-10    -  1.00e+00 1.00e+00f  1

Note on iterate 14 where 949 line searches (function evaluations) were done. This step size for the primal variables is also extremely small on this iterate. Why is this? I have set accept_after_max_steps to 10 to alleivate this issue, but I'm interested in understanding why this occurs and if I could instead modify the problem somehow so this doesn't occur. This iterate was of type "h", perhaps this is relevant? This also seems to occur whenever Ipopt is close to the optimal solution.