Originally posted by: Yunwei

From the online documentation for CPXsetdeletenodecallbackfunc

The user written callback function should be:
int callback (CPXCENVptr env, void *cbdata, int wherefrom, void *cbhandle, CPXLONG seqnum, void *handle)

However, when I program, the CPXsetdeletenodecallbackfunc only accept the callback function like:
int callback (CPXCENVptr env, int wherefrom, void *cbhandle, CPXLONG seqnum, void *handle)

void *cbdata is missing which is important to query info for nodes to be deleted.

I am using CPLEX 12.3 Callable library on Mac OS X.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

You are right, this is a mismatch in the documentation.
What information do you want to query from the delete callback?
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: Yunwei

I want to know how the node looks like when it is deleted.

for example:
int CPXgetcallbacknodelp(CPXCENVptr env, void * cbdata, int wherefrom, CPXLPptr * nodelp_p)

basically all CPXgetcallbackXXXX needs cbdata as an argument
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Unfortunately, this is not possible. In many situations, the nodelp is not even set up when the node is deleted. For example, consider a node in the tree that is pruned when a new incumbent is found. CPLEX would not load any of the node data structures; it just needs to free the memory associated with the node. In particular, it needs to free the user data attached to the node, and this is the reason why the deletecallback is called.

Tobias
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

As Tobias said, the delete callback may not have the context that is required to provide the data you are looking for.
However, what you could do is to attach a user object to each node in a branch callback and then store all the required data in that user object (you may have to fill in this data from other callbacks). If you do so then you can query the desired data from the user object when the delete callback is invoked.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: Yunwei

To Daniel: It would be much harder to use other callbacks to gather information on what has been done on the node and I doubt these callbacks can provide complete info on what has been done on the node.

To Tobias: There are only four situations when a node is to be deleted. I understand some of them
do not need to load nodelp to get a node freed.
You are talking from the programming point of view, what is needed to delete a node. I am more interested in what makes the decision to delete a node and I thought this is what delete node callback would provide based on the documentation.

Thank you for your timely reply.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

I'm afraid you read more into the documentation than it actually says :-(
The delete callback does not provide any information concerning why the node is being deleted. The documentation just lists the different cases in which the callback may be invoked. There is no (direct) way to figure out why the node was deleted. The only way I see to figure this out with the existing API is by massive use of callbacks.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: amindehghanian

Sorry, my question is not really related to the main issue of this thread.
But, I am very curious about what Daniel said.
How we can attach a user object to each node in branch callback. I mean how it is possible to do it in terms of programming?
My feeling is that I have to declare too many objects before calling CPXmipopt. It means I need to associate an object for each open node. But there are 2 issues with this method:
1. It is killing in terms of memory
2. We don't know how many open nodes we will have at each point of the B&C tree

Am I right?
Is there any better method?

Thanks a lot,
Amin
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

The branch callback allows you to query which branches CPLEX would create if you had no branch callback installed. Using this information you can create the exact same branches but attach user objects to the newly created nodes. These objects stay alive until they are deleted in the delete callback. So the idea is to dynamically allocate the user objects as needed in the branch callback and to delete them in the delete callback once a node has been processed and the user objects are no longer needed.
There is no need to predict the number of objects that will be required. Depending on the size of the user objects and the number of open nodes this may be require some memory.
#CPLEXOptimizers
#DecisionOptimization