Ignore:
Timestamp:
Dec 5, 2009 10:54:48 AM (10 years ago)
Author:
EdwinStraver
Message:

Added comments from Lou

File:
1 edited

Legend:

Unmodified
Added
Removed
  • branches/sandbox/Cbc/src/CbcModel.cpp

    r1357 r1364  
    16561656    bool noObjects = (numberObjects_ == 0);
    16571657    // Set up strategies
     1658/*
     1659  See if the user has supplied a strategy object and deal with it if present.
     1660  The call to setupOther will set numberStrong_ and numberBeforeTrust_, and
     1661  perform integer preprocessing, if requested.
     1662
     1663  We need to hang on to a pointer to solver_. setupOther will assign a
     1664  preprocessed solver to model, but will instruct assignSolver not to trash the
     1665  existing one.
     1666*/
    16581667    if (strategy_) {
    16591668        // May do preprocessing
     
    20242033        return ;
    20252034    }
     2035/*
     2036  See if we're using the Osi side of the branching hierarchy. If so, either
     2037  convert existing CbcObjects to OsiObjects, or generate them fresh. In the
     2038  first case, CbcModel owns the objects on the object_ list. In the second
     2039  case, the solver holds the objects and object_ simply points to the
     2040  solver's list.
     2041
     2042  080417 The conversion code here (the block protected by `if (obj)') cannot
     2043  possibly be correct. On the Osi side, descent is OsiObject -> OsiObject2 ->
     2044  all other Osi object classes. On the Cbc side, it's OsiObject -> CbcObject
     2045  -> all other Cbc object classes. It's structurally impossible for any Osi
     2046  object to descend from CbcObject. The only thing I can see is that this is
     2047  really dead code, and object detection is now handled from the Osi side.
     2048*/
    20262049    // Convert to Osi if wanted
    20272050    bool useOsiBranching = false;
     
    20722095            //}
    20732096        } else {
     2097/*
     2098  As of 080104, findIntegersAndSOS is misleading --- the default OSI
     2099  implementation finds only integers.
     2100*/
    20742101            // do from solver
    20752102            deleteObjects(false);
     
    22672294    double * upperBefore = new double [numberColumns] ;
    22682295    /*
     2296  Set up to run heuristics and generate cuts at the root node. The heavy
     2297  lifting is hidden inside the calls to doHeuristicsAtRoot and solveWithCuts.
     2298
     2299  To start, tell cut generators they can be a bit more aggressive at the
     2300  root node.
     2301
     2302  QUESTION: phase_ = 0 is documented as `initial solve', phase = 1 as `solve
     2303            with cuts at root'. Is phase_ = 1 the correct indication when
     2304            doHeurisiticsAtRoot is called to run heuristics outside of the main
     2305            cut / heurisitc / reoptimise loop in solveWithCuts?
    22692306
    22702307      Generate cuts at the root node and reoptimise. solveWithCuts does the heavy
     
    23492386        }
    23502387    }
     2388/*
     2389  Run heuristics at the root. This is the only opportunity to run FPump; it
     2390  will be removed from the heuristics list by doHeuristicsAtRoot.
     2391*/
    23512392    // Do heuristics
    23522393    doHeuristicsAtRoot();
     2394/*
     2395  Grepping through the code, it would appear that this is a command line
     2396  debugging hook.  There's no obvious place in the code where this is set to
     2397  a negative value.
     2398*/
    23532399    if ( intParam_[CbcMaxNumNode] < 0)
    23542400        eventHappened_ = true; // stop as fast as possible
     
    23652411        //eventHappened_=true; // stop as fast as possible
    23662412    }
     2413/*
     2414  Set up for statistics collection, if requested. Standard values are
     2415  documented in CbcModel.hpp. The magic number 100 will trigger a dump of
     2416  CbcSimpleIntegerDynamicPseudoCost objects (no others). Looks like another
     2417  command line debugging hook.
     2418*/
    23672419    statistics_ = NULL;
    23682420    // Do on switch
     
    23752427    if (noObjects && numberIntegers_ < solver_->getNumCols() && (specialOptions_&65536) != 0 && !parentModel_)
    23762428        AddIntegers();
    2377 
     2429/*
     2430  Do an initial round of cut generation for the root node. Depending on the
     2431  type of underlying solver, we may want to do this even if the initial query
     2432  to the objects indicates they're satisfied.
     2433
     2434  solveWithCuts does the heavy lifting. It will iterate a generate/reoptimise
     2435  loop (including reduced cost fixing) until no cuts are generated, the
     2436  change in objective falls off,  or the limit on the number of rounds of cut
     2437  generation is exceeded.
     2438
     2439  At the end of all this, any cuts will be recorded in cuts and also
     2440  installed in the solver's constraint system. We'll have reoptimised, and
     2441  removed any slack cuts (numberOldActiveCuts_ and numberNewCuts_ have been
     2442  adjusted accordingly).
     2443*/
    23782444    int iObject ;
    23792445    int preferredWay ;
     
    69056971    //solver_->writeMps("saved");
    69066972#ifdef CBC_THREAD
     6973/*
     6974  Thread mode makes a difference here only when it specifies using separate
     6975  threads to generate cuts at the root (bit 2^1 set in threadMode_). In which
     6976  case we'll create an array of empty CbcModels (!). Solvers will be cloned
     6977  later.
     6978*/
    69076979    CbcModel ** threadModel = NULL;
    69086980    Coin_pthread_t * threadId = NULL;
     
    69717043            onOptimalPath = (debugger->onOptimalPath(*solver_)) ;
    69727044    }
     7045/*
     7046  As the final action in each round of cut generation (the numberTries loop),
     7047  we'll call takeOffCuts to remove slack cuts. These are saved into slackCuts
     7048  and rechecked immediately after the cut generation phase of the loop.
     7049*/
    69737050    OsiCuts slackCuts;
    69747051    /*
    6975       Resolve the problem. If we've lost feasibility, might as well bail out right
     7052    lh:
     7053          Resolve the problem
     7054
     7055  The resolve will also refresh cached copies of the solver solution
     7056  (cbcColLower_, ...) held by CbcModel.
     7057  This resolve looks like the best point to capture a warm start for use in
     7058  the case where cut generation proves ineffective and we need to back out
     7059  a few tight cuts.
     7060  I've always maintained that this resolve is unnecessary. Let's put in a hook
     7061  to report if it's every nontrivial. -lh
     7062
     7063        Resolve the problem. If we've lost feasibility, might as well bail out right
    69767064      after the debug stuff. The resolve will also refresh cached copies of the
    69777065      solver solution (cbcColLower_, ...) held by CbcModel.
     
    69897077    cut_obj[CUT_HISTORY-1] = lastObjective;
    69907078    //double firstObjective = lastObjective+1.0e-8+1.0e-12*fabs(lastObjective);
     7079/*
     7080  Contemplate the result of the resolve.
     7081    - CbcModel::resolve() has a hook that calls CbcStrategy::status to look
     7082      over the solution. The net result is that resolve can return
     7083      0 (infeasible), 1 (feasible), or -1 (feasible, but do no further work).
     7084    - CbcFeasbililityBase::feasible() can return 0 (no comment),
     7085      1 (pretend this is an integer solution), or -1 (pretend this is
     7086      infeasible). As of 080104, this seems to be a stub to allow overrides,
     7087      with a default implementation that always returns 0.
     7088
     7089  Setting numberTries = 0 for `do no more work' is problematic. The main cut
     7090  generation loop will still execute once, so we do not observe the `no
     7091  further work' semantics.
     7092
     7093  As best I can see, allBranchesGone is a null function as of 071220.
     7094*/
    69917095    if (node && node->nodeInfo() && !node->nodeInfo()->numberBranchesLeft())
    69927096        node->nodeInfo()->allBranchesGone(); // can clean up
     
    69977101        feasible = false; // pretend infeasible
    69987102    }
     7103/*
     7104  NEW_UPDATE_OBJECT is defined to 0 when unthreaded (CBC_THREAD undefined), 2
     7105  when threaded. No sign of 1 as of 071220.
     7106
     7107  At present, there are two sets of hierarchies for branching classes. Call
     7108  them CbcHier and OsiHier. For example, we have OsiBranchingObject, with
     7109  children CbcBranchingObject and OsiTwoWayBranchingObject. All
     7110  specialisations descend from one of these two children. Similarly, there is
     7111  OsiObject, with children CbcObject and OsiObject2.
     7112
     7113  In the original setup, there's a single CbcBranchDecision object attached
     7114  to CbcModel (branchingMethod_). It has a field to hold the current CbcHier
     7115  branching object, and the updateInformation routine reaches through the
     7116  branching object to update the underlying CbcHier object.
     7117
     7118  NEW_UPDATE_OBJECT = 0 would seem to assume the original setup. But,
     7119  if we're using the OSI hierarchy for objects and branching, a call to a
     7120  nontrivial branchingMethod_->updateInformation would have no effect (it
     7121  would expect a CbcObject to work on) or perhaps crash.  For the
     7122  default CbcBranchDefaultDecision, updateInformation is a noop (actually
     7123  defined in the base CbcBranchDecision class).
     7124
     7125  NEW_UPDATE_OBJECT = 2 looks like it's prepared to cope with either CbcHier or
     7126  OsiHier, but it'll be executed only when threads are activated. See the
     7127  comments below. The setup is scary.
     7128
     7129  But ... if the OsiHier update actually reaches right through to the object
     7130  list in the solver, it should work just fine in unthreaded mode. It would
     7131  seem that the appropriate thing to do in unthreaded mode would be to choose
     7132  between the existing code for NEW_UPDATE_OBJECT = 0 and the OsiHier code for
     7133  NEW_UPDATE_OBJECT = 2. But I'm going to let John hash that out. The worst
     7134  that can happen is inefficiency because I'm not properly updating an object.
     7135*/
    69997136
    70007137    // Update branching information if wanted
     
    73127449
    73137450          The need to resolve here should only happen after a heuristic solution.
     7451  optimalBasisIsAvailable resolves to basisIsAvailable, which seems to be part
     7452  of the old OsiSimplex API. Doc'n says `Returns true if a basis is available
     7453  and the problem is optimal. Should be used to see if the BinvARow type
     7454  operations are possible and meaningful.' Which means any solver other the clp
     7455  is probably doing a lot of unnecessary resolves right here.
    73147456          (Note default OSI implementation of optimalBasisIsAvailable always returns
    73157457          false.)
     
    73727514        //probingInfo_->initializeFixing();
    73737515        int i;
     7516/*
     7517  threadMode with bit 2^1 set indicates we should use threads for root cut
     7518  generation.
     7519*/
    73747520        if ((threadMode_&2) == 0 || numberNodes_) {
    73757521# ifdef COIN_HAS_CLP
     
    75727718                }
    75737719            }
     7720/*
     7721  End of loop to run each cut generator.
     7722*/
    75747723            if (!node) {
    75757724                handler_->message(CBC_ROOT_DETAIL, messages_)
     
    83808529        }
    83818530    } while (numberTries > 0 || keepGoing) ;
     8531/*
     8532  End cut generation loop.
     8533*/
    83828534    {
    83838535        // switch on
     
    84538605    }
    84548606    /*
     8607  End of code block to check for a solution, when cuts may be added as a result
     8608  of a feasible solution.
     8609
    84558610      Reduced cost fix at end. Must also check feasible, in case we've popped out
    84568611      because a generator indicated we're infeasible.
     
    85268681    //printf("XXb sum obj changed by %g\n",sumChangeObjective2_);
    85278682    /*
     8683        lh:
     8684          Is this a full scan interval? If so, consider if we want to disable or
     8685  adjust the frequency of use for any of the cut generators. If the client
     8686  specified a positive number for howOften, it will never change. If the
     8687  original value was negative, it'll be converted to 1000000+|howOften|, and
     8688  this value will be adjusted each time fullScan is true. Actual cut
     8689  generation is performed every howOften%1000000 nodes; the 1000000 offset is
     8690  just a convenient way to specify that the frequency is adjustable.
     8691-lh
    85288692      End of cut generation loop.
    85298693
     
    85428706      TODO: All this should probably be hidden in a method of the CbcCutGenerator
    85438707      class.
    8544 
     8708lh:
     8709  TODO: Can the loop that scans over whichGenerator to accumulate per
     8710        generator counts be replaced by values in countRowCuts and
     8711        countColumnCuts?
     8712
     8713        << I think the answer is yes, but not the other way 'round. Row and
     8714           column cuts are block interleaved in whichGenerator. >>
     8715
     8716  The root is automatically a full scan interval. At the root, decide if
     8717  we're going to do cuts in the tree, and whether we should keep the cuts we
     8718  have.
     8719
     8720  Codes for willBeCutsInTree:
     8721    -1: no cuts in tree and currently active cuts seem ineffective; delete
     8722        them
     8723     0: no cuts in tree but currently active cuts seem effective; make them
     8724        into architecturals (faster than treating them as cuts)
     8725     1: cuts will be generated in the tree; currently active cuts remain as
     8726        cuts
     8727-lh
    85458728    */
    85468729#ifdef NODE_LOG
     
    85628745        double densityNew = numberRowsAdded ? (static_cast<double> (numberElementsAdded)) / static_cast<double> (numberRowsAdded)
    85638746                            : 0.0;
     8747/*
     8748  If we're at the root, and we added cuts, and the cuts haven't changed the
     8749  objective, and the cuts resulted in a significant increase (> 20%) in nonzero
     8750  coefficients, do no cuts in the tree and ditch the current cuts. They're not
     8751  cost-effective.
     8752*/
    85648753        if (!numberNodes_) {
    85658754            if (numberRowsAdded)
     
    86788867            }
    86798868        }
     8869/*
     8870  Noop block 071219.
     8871*/
    86808872        if ((numberRowsAdded > 100 + 0.5*numberRowsAtStart
    86818873                || numberElementsAdded > 0.5*numberElementsAtStart)
     
    86878879            //     numberRowsAdded,densityNew);
    86888880        }
     8881/*
     8882  Noop block 071219.
     8883*/
    86898884        if (densityNew > 100.0 && numberRowsAdded > 2 && densityNew > 2.0*densityOld) {
    86908885            //if (thisObjective-startObjective<0.1*fabs(startObjective)+1.0e-5)
     
    86948889        }
    86958890        // Root node or every so often - see what to turn off
     8891/*
     8892  Hmmm ... > -90 for any generator will overrule previous decision to do no
     8893  cuts in tree and delete existing cuts.
     8894*/
    86968895        int i ;
    86978896        for (i = 0; i < numberCutGenerators_; i++) {
     
    87068905            << currentPassNumber_
    87078906            << CoinMessageEol ;
     8907/*
     8908  Count the number of cuts produced by each cut generator on this call. Not
     8909  clear to me that the accounting is equivalent here. whichGenerator_ records
     8910  the generator for column and row cuts. So unless numberNewCuts is row cuts
     8911  only, we're double counting for JUST_ACTIVE. Note too the multiplier applied
     8912  to column cuts.
     8913*/
    87088914        if (!numberNodes_) {
    87098915            double value = CoinMax(minimumDrop_, 0.005 * (thisObjective - startObjective) /
     
    87368942            totalCuts += value;
    87378943        }
     8944/*
     8945  Open up a loop to step through the cut generators and decide what (if any)
     8946  adjustment should be made for calling frequency.
     8947*/
    87388948        int iProbing = -1;
    87398949        double smallProblem = (0.2 * totalCuts) /
     
    87428952            int howOften = generator_[i]->howOften() ;
    87438953            /*  Probing can be set to just do column cuts in treee.
    8744             But if doing good then leave as on */
     8954            But if doing good then leave as on
     8955  Ok, let me try to explain this. rowCuts = 3 says do disaggregation (1<<0) and
     8956  coefficient (1<<1) cuts. But if the value is negative, there's code at the
     8957  entry to generateCuts, and generateCutsAndModify, that temporarily changes
     8958  the value to 4 (1<<2) if we're in a search tree.
     8959
     8960  Which does nothing to explain this next bit. We set a boolean, convert
     8961  howOften to the code for `generate while objective is improving', and change
     8962  over to `do everywhere'. Hmmm ... now I write it out, this makes sense in the
     8963  context of the original comment. If we're doing well (objective improving)
     8964  we'll keep probing fully active.
     8965                       
     8966                        */
    87458967            bool probingWasOnBut = false;
    87468968            CglProbing * probing = dynamic_cast<CglProbing*>(generator_[i]->generator());
     
    87588980                }
    87598981            }
     8982/*
     8983  Convert `as long as objective is improving' into `only at root' if we've
     8984  decided cuts just aren't worth it.
     8985*/
    87608986            if (willBeCutsInTree < 0 && howOften == -98)
    87618987                howOften = -99;
     8988/*
     8989  And check to see if the objective is improving. But don't do the check if
     8990  the user has specified some minimum number of cuts.
     8991
     8992  This exclusion seems bogus, or at least counterintuitive. Why would a user
     8993  suspect that setting a minimum cut limit would invalidate the objective
     8994  check? Nor do I see the point in comparing the number of rows and columns
     8995  in the second test.
     8996*/
    87628997            if (!probing && howOften == -98 && !generator_[i]->numberShortCutsAtRoot() &&
    87638998                    generator_[i]->numberCutsInTotal()) {
     
    87739008                    howOften = -99; // switch off
    87749009            }
     9010/*
     9011  Below -99, this generator is switched off. There's no need to consider
     9012  further. Then again, there was no point in persisting this far!
     9013*/
    87759014            if (howOften < -99)
    87769015                continue ;
     9016/*
     9017  Adjust, if howOften is adjustable.
     9018*/
    87779019            if (howOften < 0 || howOften >= 1000000) {
    87789020                if ( !numberNodes_) {
     9021/*
     9022  If root only, or objective improvement but no cuts generated, switch off. If
     9023  it's just that the generator found no cuts at the root, give it one more
     9024  chance.
     9025*/
    87799026                    // If small number switch mostly off
    87809027#ifdef JUST_ACTIVE
     
    88029049                            }
    88039050                        }
     9051/*
     9052  Not productive, but not zero either.
     9053*/
    88049054                    } else if ((thisCuts + generator_[i]->numberColumnCuts() < smallProblem)
    88059055                               && !generator_[i] ->whetherToUse()) {
     9056/*
     9057  Not unadjustable every node, and not strong probing.
     9058*/
    88069059                        if (howOften != 1 && !probingWasOnBut) {
     9060/*
     9061  No depth spec, or not adjustable every node.
     9062*/
    88079063                            if (generator_[i]->whatDepth() < 0 || howOften != -1) {
    88089064                                int k = static_cast<int> (sqrt(smallProblem / thisCuts)) ;
     9065/*
     9066  Not objective improvement, set to new frequency, otherwise turn off.
     9067*/
    88099068                                if (howOften != -98)
    88109069                                    howOften = k + 1000000 ;
    88119070                                else
    88129071                                    howOften = -100;
     9072/*
     9073  Depth spec, or adjustable every node. Force to unadjustable every node.
     9074*/
    88139075                            } else {
    88149076                                howOften = 1;
    88159077                            }
     9078/*
     9079  Unadjustable every node, or strong probing. Force unadjustable every node and
     9080  force not strong probing? I don't understand.
     9081*/
    88169082                        } else {
    88179083                            howOften = 1;
     
    88199085                            probingWasOnBut = false;
    88209086                        }
     9087/*
     9088  Productive cut generator. Say we'll do it every node, adjustable. But if the
     9089  objective isn't improving, restrict that to every fifth depth level
     9090  (whatDepth overrides howOften in generateCuts).
     9091*/
    88219092                    } else {
    88229093                        if (thisObjective - startObjective < 0.1*fabs(startObjective) + 1.0e-5 && generator_[i]->whatDepth() < 0)
     
    88259096                    }
    88269097                }
     9098/*
     9099  End root actions.
     9100
     9101  sumChangeObjective2_ is the objective change due to cuts. If we're getting
     9102  much better results from branching over a large number of nodes, switch off
     9103  cuts.
     9104
     9105  Except it doesn't, really --- it just puts off the decision 'til the
     9106  next full scan, when it'll put it off again unless cuts look better.
     9107*/
    88279108                // If cuts useless switch off
    88289109                if (numberNodes_ >= 100000 && sumChangeObjective1_ > 2.0e2*(sumChangeObjective2_ + 1.0e-12)) {
     
    88319112                }
    88329113            }
     9114/*
     9115  Ok, that's the frequency adjustment bit.
     9116
     9117  Now, if we're at the root, force probing back on at every node, for column
     9118  cuts at least, even if it looks useless for row cuts. Notice that if it
     9119  looked useful, the values set above mean we'll be doing strong probing in
     9120  the tree subject to objective improvement.
     9121*/
    88339122            if (!numberNodes_) {
    88349123                if (probingWasOnBut && howOften == -100) {
     
    88429131                    willBeCutsInTree = 1;
    88439132            }
     9133/*
     9134  Set the new frequency in the generator. If this is an adjustable frequency,
     9135  use the value to set whatDepth.
     9136
     9137  Hey! Seems like this could override the user's depth setting.
     9138*/
    88449139            generator_[i]->setHowOften(howOften) ;
    88459140            if (howOften >= 1000000 && howOften < 2000000 && 0) {
     
    88829177            }
    88839178        }
     9179/*
     9180  End loop to adjust cut generator frequency of use.
     9181*/
    88849182        delete [] count ;
    88859183        if ( !numberNodes_) {
     
    88899187                generator_[i]->setNumberActiveCutsAtRoot(generator_[i]->numberCutsActive());
    88909188            }
     9189/*
     9190  Garbage code 071219
     9191*/
    88919192            // decide on pseudo cost strategy
    88929193            int howOften = iProbing >= 0 ? generator_[iProbing]->howOften() : 0;
     
    89139214            if (willBeCutsInTree == -2)
    89149215                willBeCutsInTree = 0;
     9216/*
     9217  End garbage code.
     9218
     9219  Now I've reached the problem area. This is a problem only at the root node,
     9220  so that should simplify the issue of finding a workable basis? Or maybe not.
     9221*/
    89159222            if ( willBeCutsInTree <= 0) {
    89169223                // Take off cuts
     
    92639570    return numberDropped;
    92649571}
    9265 
     9572/*
     9573  Return values:
     9574    1:  feasible
     9575    0:  infeasible
     9576   -1:  feasible and finished (do no more work on this subproblem)
     9577*/
    92669578int
    92679579CbcModel::resolve(CbcNodeInfo * parent, int whereFrom,
     
    95789890    int returnStatus = feasible ? 1 : 0;
    95799891    if (strategy_) {
     9892/*
     9893  Possible returns from status:
     9894    -1: no recommendation
     9895     0: treat as optimal
     9896     1: treat as optimal and finished (no more resolves, cuts, etc.)
     9897     2: treat as infeasible.
     9898*/
    95809899        // user can play clever tricks here
    95819900        int status = strategy_->status(this, parent, whereFrom);
     
    96499968    const double * rowLower = getRowLower();
    96509969    const double * rowUpper = getRowUpper();
     9970/*
     9971  Scan the rows, looking for individual rows that are clique constraints.
     9972*/
    96519973
    96529974    for (iRow = 0; iRow < numberRows; iRow++) {
     
    96579979        bool good = true;
    96589980        int slack = -1;
     9981/*
     9982  Does this row qualify? All variables must be binary and all coefficients
     9983  +/- 1.0. Variables with positive coefficients are recorded at the low end of
     9984  which, variables with negative coefficients the high end.
     9985*/
    96599986        for (j = rowStart[iRow]; j < rowStart[iRow] + rowLength[iRow]; j++) {
    96609987            int iColumn = column[j];
     
    968710014        int iUpper = static_cast<int> (floor(upperValue + 1.0e-5));
    968810015        int iLower = static_cast<int> (ceil(lowerValue - 1.0e-5));
     10016/*
     10017  What do we have? If the row upper bound is greater than 1-numberM1, this
     10018  isn't a clique. If the row upper bound is 1-numberM1, we have the classic
     10019  clique (an SOS1 on binary variables, if numberM1 = 0). If the upper bound
     10020  equals numberM1, we can fix all variables. If the upper bound is less than
     10021  numberM1, we're infeasible.
     10022 
     10023  A similar analysis applies using numberP1 against the lower bound.
     10024*/
    968910025        int state = 0;
    969010026        if (upperValue < 1.0e6) {
     
    970410040                state = -3;
    970510041        }
    9706         if (good && state) {
     10042  /*
     10043  What to do? If we learned nothing, move on to the next iteration. If we're
     10044  infeasible, we're outta here. If we decided we can fix variables, do it.
     10045*/
     10046      if (good && state) {
    970710047            if (abs(state) == 3) {
    970810048                // infeasible
     
    972810068                }
    972910069            } else {
     10070/*
     10071  And the final case: we have a clique constraint. If it's within the allowed
     10072  size range, make a clique object.
     10073*/
    973010074                int length = numberP1 + numberM1;
    973110075                if (length >= atLeastThisMany && length < lessThanThis) {
     
    973310077                    bool addOne = false;
    973410078                    int objectType;
     10079/*
     10080  Choose equality (type 1) or inequality (type 0). If we're forcing equalities,
     10081  add a slack.
     10082*/
    973510083                    if (iLower == iUpper) {
    973610084                        objectType = 1;
     
    974510093                        }
    974610094                    }
     10095/*
     10096  Record the strong values for the variables. Variables with positive
     10097  coefficients force all others when set to 1; variables with negative
     10098  coefficients force when set to 0. If the clique is formed against the row
     10099  lower bound, convert to the canonical form of a clique against the row
     10100  upper bound.
     10101*/
    974710102                    if (state > 0) {
    974810103                        totalP1 += numberP1;
     
    980910164    }
    981010165#endif
     10166/*
     10167  If required, augment the constraint matrix with clique slacks. Seems like we
     10168  should be able to add the necessary integer objects without a complete
     10169  rebuild of existing integer objects, but I'd need to look further to confirm
     10170  that (lh, 071219). Finally, add the clique objects.
     10171*/
    981110172    if (numberCliques > 0 && numberSlacks && makeEquality) {
    981210173        printf("adding %d integer slacks\n", numberSlacks);
     
    1252312884    return solver->isProvenOptimal() ? 1 : 0;
    1252412885}
     12886/*!
     12887    \todo It'd be really nice if there were an overload for this method that
     12888          allowed a separate value for the underlying solver's log level. The
     12889          overload could be coded to allow an increase in the log level of the
     12890          underlying solver.
     12891
     12892          It's worth contemplating whether OSI should have a setLogLevel method
     12893          that's more specific than the hint mechanism.
     12894*/
    1252512895
    1252612896// Set log level
     
    1261812988}
    1261912989/* Encapsulates choosing a variable -
    12620    anyAction -2, infeasible (-1 round again), 0 done
     12990   anyAction: -2 infeasible
     12991              -1 round again
     12992               0 done
     12993
     12994   At the point where chooseBranch is called, we've decided that this problem
     12995   will need to be placed in the live set and we need to choose a branching
     12996   variable.
     12997
     12998   Parameters:
     12999     newNode:   the node just created for the active subproblem.
     13000     oldNode:   newNode's parent.
     13001     lastws:    oldNode's basis
     13002     lowerBefore, upperBefore: column bound arrays for oldNode
     13003     cuts:      list of cuts added to newNode.
     13004
     13005     resolved:  (o)  set to true if newNode is resolved during processing
     13006     branches:  (o) will be filled in with ... ? Null on entry
    1262113007*/
    1262213008int
     
    1263513021      4 - no solution but many nodes
    1263613022         add 10 if depth >= K
     13023    K is currently hardcoded to 8, a few lines below.
     13024
     13025    CBCMODEL_DEBUG: Seems like stateOfSearch_ should be 2 if
     13026               numberHeuristicSolutions_ == numberSolutions_.
     13027
    1263713028    */
    1263813029    stateOfSearch_ = 1;
     
    1268713078#endif
    1268813079    currentNode_ = newNode; // so can be used elsewhere
     13080/*
     13081  Enough preparation. Get down to the business of choosing a branching
     13082  variable.
     13083*/
    1268913084    while (anyAction == -1) {
    1269013085        // Set objective value (not so obvious if NLP etc)
     
    1269213087        //if (numberPassesLeft<=0)
    1269313088        //branchingState=1;
     13089/*
     13090  Is there a CbcBranchDecision object installed? Does it specify a
     13091  chooseVariable method? If not, we're using the old (Cbc) side of the branch
     13092  decision hierarchy.  In quick summary, CbcNode::chooseBranch uses strong
     13093  branching on any objects, while CbcNode::chooseDynamicBranch uses dynamic
     13094  branching, but only on simple integers (-3 is the code for punt due to
     13095  complex objects). Serious bugs remain on the Cbc side, particularly in
     13096  chooseDynamicBranch.
     13097*/
    1269413098        if (!branchingMethod_ || !branchingMethod_->chooseMethod()) {
    1269513099#ifdef COIN_HAS_CLP
     
    1272713131                    anyAction = newNode->chooseBranch(this, oldNode, numberPassesLeft) ; // dynamic did nothing
    1272813132            }
     13133/*
     13134  We're on the new (Osi) side of the branching hierarchy.
     13135*/
    1272913136        } else {
    1273013137            OsiBranchingInformation usefulInfo = usefulInformation();
     
    1282113228        }
    1282213229    }
     13230/*
     13231  End main loop to choose a branching variable.
     13232*/
    1282313233    if (anyAction >= 0) {
    1282413234        if (resolved) {
     
    1310313513   1 - delete
    1310413514      2 - just delete - don't even use
     13515  Parameter of 2 means what it says --- the routine will do nothing except
     13516  delete the existing heuristics. A feasibility pump is always deleted,
     13517  independent of the parameter value, as it's only useful at the root.
     13518
     13519  The routine is called from branchAndBound to process the root node. But it
     13520  will also be called when we've recursed into branchAndBound via smallBaB.
    1310513521*/
    1310613522void
     
    1311213528    int i;
    1311313529    if (deleteHeuristicsAfterwards != 2) {
     13530/*
     13531  If mode == 1, we delete and recreate here, then delete at the bottom. The
     13532  create/delete part makes sense, but why delete the existing array? Seems like
     13533  it should be preserved and restored.
     13534*/
    1311413535        if (deleteHeuristicsAfterwards) {
    1311513536            delete [] usedInSolution_;
     
    1312213543        if (eventHandler)
    1312313544            eventHandler->setModel(this);
     13545/*
     13546  currentPassNumber_ is described as `cut pass number'. Again, seems a bit
     13547  cavalier to just change it.
     13548
     13549  Whether this has any effect is determined by individual heuristics. Typically
     13550  there will be a check at the front of the solution() routine that determines
     13551  whether it will run or simply return. Root heuristics are characterised by
     13552  node count of 0. In addition, currentPassNumber_ can be checked to to limit
     13553  execution in terms of passes through cut generation / heuristic execution in
     13554  solveWithCuts.
     13555*/
    1312413556
    1312513557        currentPassNumber_ = 1; // so root heuristics will run
     13558/*
     13559  A loop to run the heuristics. incrementUsed will mark entries in
     13560  usedInSolution corresponding to variables that are nonzero in the solution.
     13561  CBC_ROUNDING just identifies a message template, not the heuristic.
     13562*/
    1312613563        // Modify based on size etc
    1312713564        adjustHeuristics();
     
    1326913706        /*
    1327013707          Did any of the heuristics turn up a new solution? Record it before we free
    13271           the vector.
     13708  the vector. tree_ will not necessarily be a CbcTreeLocal; the main model gets
     13709  a CbcTree by default. CbcTreeLocal actually implements a k-neighbourhood
     13710  search heuristic. This initialises it with a solution and creates the
     13711  k-neighbourhood cut.
    1327213712        */
    1327313713        if (found >= 0) {
     
    1328313723        }
    1328413724    }
     13725/*
     13726  Cleanup. The feasibility pump heuristic is a root heuristic to look for an
     13727  initial feasible solution. It's had its chance; remove it.
     13728
     13729  For modes 1 and 2, all the heuristics are deleted.
     13730*/
    1328513731    if (!deleteHeuristicsAfterwards) {
    1328613732        for (i = 0; i < numberHeuristics_; i++) {
Note: See TracChangeset for help on using the changeset viewer.