Originally posted by: open_ball

Hi,

I am trying to access the value of some variables within the callback function but am receiving the error shown below.

Exception in thread "main" ilog.cplex.CpxException: CPLEX Error  1006: Error during callback.

        at ilog.cplex.CplexI.CALL(CplexI.java:4969)
        at ilog.cplex.CplexI.setStatus(CplexI.java:6301)
        at ilog.cplex.CplexI.access$500(CplexI.java:120)
        at ilog.cplex.CplexI$SolveHandle.stop(CplexI.java:2941)
        at ilog.cplex.CplexI.solve(CplexI.java:2964)
        at ilog.cplex.IloCplex.solve(IloCplex.java:10254)

 I store the master variable in a HashMap as; 

HashMap<ArcTime,IloIntVar> masterVariable;

When I enter into the lazy constraint callback function, I intend to reach each value one by one. However, when I call context.getCandidatePoint, I receive an error. 

Iterator<ArcTime> set = indexSet.iterator(); 
        while(set.hasNext()){
        ArcTime arcTime = new ArcTime(set.next().getFrom(), set.next().getTo(), set.next().getTimeIndex());     
        double val=  context.getCandidatePoint(masterVariable.get(arcTime));
        // use val to update sub problem. 
         }

I checked the formulation of both master and sub problems through the LP files, and everything seems correct. Also, the code successfully enters into the callback function. What might I be doing wrong?

When you invoke the ArcTime constructor in the last code chunk, you call set.next() three times, which means you are grabbing "from", "to" and "time index" from three consecutive set elements, not from a single element. I suspect that's a bug.

The other problem, which I think accounts for the error message, is that you do not check in line 4 of the last chunk for masterVariable.get(arcTime) returning a null value. Since you just constructed arcTime, it cannot possibly be a key in masterVariable. If there is an entry in masterVariable whose key matches your arcTime in all fields, there is still the question of whether the ArcTime class overrides the equals() method to treat two instances with identical fields as being equal.

Is there are reason for building a new ArcTime instance rather than just using set.next() as the key for the masterVariable map?

Originally posted by: open_ball

"When you invoke the ArcTime constructor in the last code chunk, you call set.next() three times, which means you are grabbing "from", "to" and "time index" from three consecutive set elements, not from a single element. I suspect that's a bug." 

You are right! I made a mistake there and fixed the bug. 

"Is there are reason for building a new ArcTime instance rather than just using set.next() as the key for the masterVariable map?"

 I create an Arc instance via the ArctTime instance. That is why I do not directly use set.next().

"The other problem, which I think accounts for the error message, is that you do not check in line 4 of the last chunk for masterVariable.get(arcTime) returning a null value. Since you just constructed arcTime, it cannot possibly be a key in masterVariable. If there is an entry in masterVariable whose key matches your arcTime in all fields, there is still the question of whether the ArcTime class overrides the equals() method to treat two instances with identical fields as being equal."

 The indices of masterVariable come from indexSet. I do not think that it would return null. Also, I did override hashCode() and equals() methods when I first created  the ArcTime class. 

Thanks for your answers. I believe that I solved the issue. It looks like it was because of the way I define the masterVariable. Since I did not define it globally and did not pass it into the callback function, I was receiving the error.  I defined it as a private final variable and any method within the class can access it.  

In general, it is a good idea to wrap your callback function into something like

try {
  // callback code here
}
catch (IloException e) {
  System.err.println(e);
  throw e;
}
catch (RuntimeException e) {
  System.err.println(e);
  throw e;
}

That gives more information about the actual exception that was thrown. With this information you can track down problems in callbacks more easily.