<div dir="ltr">Hi All,<div>I&#39;m using ClpSimplex to calculate network (concurrent) flow problem. </div><div>When the input values are relatively small (roughly below 1,000,000,000), everything&#39;s fine. However, when goes above it, the solver will return optimal value 0, which means a most conservative result. </div><div><br></div><div><div><b>TEST:</b></div><div>Just single large value constraint, if I set the demand to 80,000,000,000, the solver will return some result.</div><div>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.</div></div><div><br></div><div>This problem should occurs in the following constraints:</div><div><div>/**</div><div>       * add one more col for demand utilization ratio</div><div>       * This utilization ratio is global, i.e., the maximum ratio that</div><div>       * all commodities can achieve.</div><div>       *</div><div>       * 1. For source node, we have:</div><div>       * total flow of commodity &gt;= demand utilization ratio * demand</div><div>       * ==&gt; total flow of commodity - (demand utilization ratio * demand) &gt;= 0;</div><div>       *</div><div>       * 2. For destination node, we have:</div><div>       * - total flow of commodity &lt;= - demand utilization ratio * demand</div><div>       * ==&gt; -total flow of commodity + (demand utilization ratio * demand) &lt;= 0</div><div>       */</div></div><div>The corresponding addRow is:</div><div><div><b>buildObj.addRow(indices.size(), indicesArr,  coeffArr, 0, 0);</b></div></div><div><b><br></b></div><div><b>demand utilization ratio </b>is a percentage of demand that can achieve, which is between 0 to 1. <br></div><div>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&#39;t handle too many inequalities like this. Is that because Clp uses type <b>double</b>? Or it will give up calculation and return 0(if it&#39;s feasible) if the number is too large? </div><div>It&#39;s OK to lose some accuracy in my solution, <b>double</b> has 1.7e+308 range, so it shouldn&#39;t be a problem, right? </div><div><br></div><div>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?</div><div><br></div><div>Best,</div><div>Emer</div></div>