Understanding IPOPT 3.13.3 (build) Differences

[lfaucheux]

I am trying to understand the differences in resolution between IPOPT runs under Windows and Linux.

Where can I find the exact procedure used to generate the IPOPT 3.13.3 executable (Intel MKL 2020.0.166 + MUMPS 4.10.0 + METIS 5.1.0), including compilation flags and optimization control options, if any?

These differences are significant: under Windows, IPOPT converges reliably, while under Linux, it gets stuck in slack too small, adjusting variable bound-like traps.

[svigerske]

I don't have the build logs for the Windows libraries from https://github.com/coin-or/Ipopt/releases/tag/releases%2F3.13.3 anymore. It was nothing special. But since these are build with MSVS, they wouldn't be reproducible in the same way on Linux (GCC, Clang, or Intel compilers, I would think).

The Windows libraries use PARDISO from Intel's MKL as default linear_solver. To get this also on Linux, you would need to build with Intel's MKL there as well.

Looking at the differences in the Ipopt log at a higher print_level may help a bit.

[lfaucheux]

Thank you for your feedback. My question specifically concerns the use of MUMPS. I set print_level to at least 9, which helped me discover that the first discrepancy occurs during the residuals computation.

Under Windows

[...]
Component 1:
  DenseVector "resid[ 0]" with 15 elements:
  resid[ 0][    1]=-2.2204460492503131e-16   # <--- incidentally, negative of 2**-52, i.e. 64-bit binary floats in the IEEE-754 standard
  resid[ 0][    2]= 0.0000000000000000e+00
  resid[ 0][    3]= 0.0000000000000000e+00
  resid[ 0][    4]= 0.0000000000000000e+00
  resid[ 0][    5]= 0.0000000000000000e+00
  resid[ 0][    6]= 0.0000000000000000e+00
  resid[ 0][    7]= 0.0000000000000000e+00
  resid[ 0][    8]= 4.4408920985006262e-16   # <--- ~2**-51
  resid[ 0][    9]= 0.0000000000000000e+00
  resid[ 0][   10]= 3.7546184440191048e-10
  resid[ 0][   11]=-4.0041959136448424e-10
  resid[ 0][   12]=-3.4471041344626930e-09
  resid[ 0][   13]=-1.4759268901325535e-09
  resid[ 0][   14]= 0.0000000000000000e+00
  resid[ 0][   15]= 0.0000000000000000e+00
[...]

Under Linux

[...]
Component 1:
  DenseVector "resid[0]" with 15 elements:
  resid[0][    1]= 0.0000000000000000e+00   # <--- ???
  resid[0][    2]= 0.0000000000000000e+00
  resid[0][    3]= 0.0000000000000000e+00
  resid[0][    4]= 0.0000000000000000e+00
  resid[0][    5]= 0.0000000000000000e+00
  resid[0][    6]= 0.0000000000000000e+00
  resid[0][    7]= 0.0000000000000000e+00
  resid[0][    8]= 4.4408920985006262e-16   # <--- ~2**-51
  resid[0][    9]= 0.0000000000000000e+00
  resid[0][   10]= 4.1007521428638245e-09
  resid[0][   11]= 3.3248707070974298e-09
  resid[0][   12]= 2.7818616399922109e-10
  resid[0][   13]= 2.2493634083293606e-09
  resid[0][   14]= 0.0000000000000000e+00
  resid[0][   15]= 0.0000000000000000e+00
[...]

Any insight ?_{Anyway, thanks for your time already.}

[svigerske]

Not really. Seems like a slightly different rounding for resid[0][1], but that can just happen.

[lfaucheux]

Any idea why Ipopt::FilterLSAcceptor's reference_theta_ > 0. || reference_gradBarrTDelta_ < 0.0' is asserted under Linux (and fails) and not under Windows ? Yet reference_gradBarrTDelta is (identical and) largely positive under both. I.e.

Under Linux

**************************************************
*** Finding Acceptable Trial Point for Iteration 6:
**************************************************

--> Starting line search in iteration 6 <--
Mu has changed in line search - resetting watchdog counters.
Acceptable Check:
  overall_error =  1.4880342869721161e-01   acceptable_tol_             =  1.0000000000000001e-15
  dual_inf      =  1.4880342869721161e-01   acceptable_dual_inf_tol_    =  1.0000000000000001e-15
  constr_viol   =  0.0000000000000000e+00   acceptable_constr_viol_tol_ =  1.0000000000000000e-02
  compl_inf     =  1.0644731315798715e-01   acceptable_compl_inf_tol_   =  1.0000000000000001e-30
  curr_obj_val_ =  3.2673194260567556e+01   last_obj_val                =  6.3327794897744155e+01
  fabs(curr_obj_val_-last_obj_val_)/Max(1., fabs(curr_obj_val_)) =  9.3821866306389445e-01 acceptable_obj_change_tol_ =  1.0000000000000000e+20
test iter = 6
The current filter has 0 entries.
Relative step size for delta_x = 1.555980e+02
minimal step size ALPHA_MIN = 5.000000E-07
Starting checks for alpha (primal) = 1.21e-03
Checking acceptability for trial step size alpha_primal_test= 1.207152e-03:
  New values of barrier function     = -1.2188508606204306e+02  (reference -1.3684563268732566e+02):
  New values of constraint violation =  0.0000000000000000e+00  (reference  0.0000000000000000e+00):
reference_theta = 0.000000e+00 reference_gradBarrTDelta = 2.228266e+03  👈💥💥💥
python: ../../../src/Algorithm/IpFilterLSAcceptor.cpp:275: bool Ipopt::FilterLSAcceptor::IsFtype(Ipopt::Number): Assertion `reference_theta_ > 0. || reference_gradBarrTDelta_ < 0.0' failed.

under Windows

**************************************************
*** Finding Acceptable Trial Point for Iteration 6:
**************************************************

--> Starting line search in iteration 6 <--
Mu has changed in line search - resetting watchdog counters.
Acceptable Check:
  overall_error =  1.4880342869721147e-01   acceptable_tol_             =  1.0000000000000001e-15
  dual_inf      =  1.4880342869721147e-01   acceptable_dual_inf_tol_    =  1.0000000000000001e-15
  constr_viol   =  0.0000000000000000e+00   acceptable_constr_viol_tol_ =  1.0000000000000000e-02
  compl_inf     =  1.0644731315798701e-01   acceptable_compl_inf_tol_   =  1.0000000000000001e-30
  curr_obj_val_ =  3.2673194260567556e+01   last_obj_val                =  6.3327794897744155e+01
  fabs(curr_obj_val_-last_obj_val_)/Max(1., fabs(curr_obj_val_)) =  9.3821866306389445e-01 acceptable_obj_change_tol_ =  1.0000000000000000e+20
test iter = 6
The current filter has 0 entries.
Relative step size for delta_x = 1.555980e+02
minimal step size ALPHA_MIN = 5.000000E-07
Starting checks for alpha (primal) = 1.21e-03
Checking acceptability for trial step size alpha_primal_test= 1.207152e-03:
  New values of barrier function     = -1.2188508606204303e+02  (reference -1.3684563268732555e+02):
  New values of constraint violation =  0.0000000000000000e+00  (reference  0.0000000000000000e+00):
reference_theta = 0.000000e+00 reference_gradBarrTDelta = 2.228266e+03 👈🕊️🕊️🕊️
Checking sufficient reduction...
Succeeded...
Checking filter acceptability...
Succeeded...
reference_theta = 0.000000e+00 reference_gradBarrTDelta = 2.228266e+03

Is it necessarily reference_theta_ that is actually (invisibly) positive, unlikely isn't it ?

[svigerske]

Assertions are only active in debug builds (compilation without -DNDEBUG). For Windows, the mdd/mtd libs are debug builds, but not the md/mt.