[Clp] large int (int64_t) overflow?

[Emerson]

Hi All,
I'm using ClpSimplex to calculate network (concurrent) flow problem.
When the input values are relatively small (roughly below 1,000,000,000),
everything's fine. However, when goes above it, the solver will return
optimal value 0, which means a most conservative result.

*TEST:*
Just single large value constraint, if I set the demand to 80,000,000,000,
the solver will return some result.
But if I set one more 0, make it be 800,000,000,000, it will return optimal
value of 0, which is feasible but not optimal.

This problem should occurs in the following constraints:
/**
       * add one more col for demand utilization ratio
       * This utilization ratio is global, i.e., the maximum ratio that
       * all commodities can achieve.
       *
       * 1. For source node, we have:
       * total flow of commodity >= demand utilization ratio * demand
       * ==> total flow of commodity - (demand utilization ratio * demand)
>= 0;
       *
       * 2. For destination node, we have:
       * - total flow of commodity <= - demand utilization ratio * demand
       * ==> -total flow of commodity + (demand utilization ratio * demand)
<= 0
       */
The corresponding addRow is:
*buildObj.addRow(indices.size(), indicesArr,  coeffArr, 0, 0);*

*demand utilization ratio *is a percentage of demand that can achieve,
which is between 0 to 1.
Since I use bps as the unit of demand, a typical value is at the magnitude
of 100,000,000,000, I use int64_t as its value type. But when the value is
at this order, Clp seems can't handle too many inequalities like this. Is
that because Clp uses type *double*? Or it will give up calculation and
return 0(if it's feasible) if the number is too large?
It's OK to lose some accuracy in my solution, *double* has 1.7e+308 range,
so it shouldn't be a problem, right?

Any way to tune the solver to manipulate larger number or I have to
decrease the number order when solving and enlarge it in the solution?

Best,
Emer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/clp/attachments/20150718/949db198/attachment.html>