Hi,
I’m afraid this is going to be completely unreproduceable, but after a couple of days I’m starting to think that my problem might not be entirely my own mistakes.
I’m using JuMP and HiGHS (or Gurobi) to solve sequential objectives with an LP, with the wrinkle that we solve twice for each objective with a difference in one constraint (a cheap way of doing a single-binary-variable IP where often one of the two options is infeasible).
For one test case (out of about 60), solving with HiGHS fails after about the 10th LP solve in the sequence with the error message
OTHER_ERROR ("There was an error calling optimize!")
The LP it’s trying to solve is feasible, but the solve immediately before is infeasible, and I’m updating constraints on the same model, not reconstructing the model from scratch, so some model state might be lying around.
Logs from HiGHS for the infeasible and failed models are:
Solving LP without presolve or with basis
Using EKK dual simplex solver - serial
Iteration Objective Infeasibilities num(sum)
0 -7.5421920965e-01 Ph1: 13(1085.11); Du: 2(0.754219) 0s
4 1.2325458579e+01 0s
Model status : Infeasible
Simplex iterations: 4
Objective value : 1.2325755066e+01
HiGHS run time : 0.21
---------
Solving LP without presolve or with basis
Using EKK dual simplex solver - serial
Iteration Objective Infeasibilities num(sum)
0 -1.2521442429e-01 Ph1: 10(6.07856); Du: 2(0.125214) 0s
5 1.5601243444e+02 0s
Using EKK dual simplex solver - serial
Iteration Objective Infeasibilities num(sum)
5 1.5601569095e+02 Pr: 2(3.70398e-07); Du: 0(9.27958e-12) 0s
5 1.5601569095e+02 0s
Model status : Unknown
Simplex iterations: 5
Objective value : 1.5601569095e+02
HiGHS run time : 0.24
The objective shown in the second log is correct. The model appears to have been solved to optimality, but HiGHS is unhappy for some other reason. For reference, the log for a successful solve of the exact same problem (see below for the workaround) is:
Solving LP without presolve or with basis
Using EKK dual simplex solver - serial
Iteration Objective Infeasibilities num(sum)
0 -1.2521440649e-01 Ph1: 10(6.07856); Du: 2(0.125214) 0s
4 1.5601569143e+02 Pr: 0(0) 0s
Model status : Optimal
Simplex iterations: 4
Objective value : 1.5601569143e+02
HiGHS run time : 0.23
The log for the immediately preceding infeasible solve is identical in the workaround case.
If I dump the problem LP to MPS, and HiGHS solves it with no problem, so it seems to be to do with the sequential nature of the solves. There are other test-cases that solve successfully (including this one with a workaround) that follow the same pattern of an infeasible solve followed by unsuccessful solves, so that doesn’t appear to be the issue.
Inspecting the MPSs of all the solves in a failing and workaround case shows no differences other than the ordering of some elements of the file, and the naming of one of the indices.
The really fun part of all this is that the failure is toggled by the names of one of the indices I use in the model.
If I call the supply objects (supplies appear as indices in variables and constraints) “s-1”, “s-2”,… the model solves successfully (and this is my current workaround). If I call the objects “supply-1”, “supply-2”,… the solve fails. Other names either do or don’t work, for example the prefixes “sapply” and “sepply” work, but “sopply” and “sipply” don’t. “su” doesn’t work but “supp” does…
I suspect the problem is related to HiGHS or the HiGHS binding, because the whole thing works if I use Gurobi, but given what else is going on, I really don’t know.
This is with Julia 1.7.2 and a recently updated set of packages:
pkg> st
[2e9cd046] Gurobi v0.11.0
[87dc4568] HiGHS v1.1.1
[4076af6c] JuMP v0.23.2
...
So, sorry for unhelpful report. I’m not really expecting anything given such vague information, but, in case it’s helpful, I thought I should try to document what I’ve found. I apologise if this proves to be a problem of my own making 
Thanks!
Geoff