This solver implements a heuristic algorithm for planning demands. More...
#include <solver.h>

Classes | |
class | SolverMRPdata |
This class is a helper class of the SolverMRP class. More... | |
struct | State |
This class is used to store the solver status during the ask-reply calls of the solver. More... | |
Public Member Functions | |
void | endElement (XMLInput &pIn, const Attribute &pAttr, const DataElement &pElement) |
virtual PyObject * | getattro (const Attribute &) |
bool | getAutocommit () const |
short | getConstraints () const |
double | getIterationAccuracy () const |
double | getIterationThreshold () const |
TimePeriod | getLazyDelay () const |
short | getPlanType () const |
virtual size_t | getSize () const |
virtual const MetaClass & | getType () const |
PythonFunction | getUserExitBuffer () const |
PythonFunction | getUserExitDemand () const |
PythonFunction | getUserExitFlow () const |
PythonFunction | getUserExitOperation () const |
PythonFunction | getUserExitResource () const |
bool | isCapacityConstrained () const |
bool | isConstrained () const |
bool | isFenceConstrained () const |
bool | isLeadtimeConstrained () const |
bool | isMaterialConstrained () const |
virtual int | setattro (const Attribute &, const PythonObject &) |
void | setAutocommit (const bool b) |
void | setConstraints (short i) |
void | setIterationAccuracy (double d) |
void | setIterationThreshold (double d) |
void | setLazyDelay (TimePeriod l) |
void | setPlanType (short b) |
void | setUserExitBuffer (const string &n) |
void | setUserExitBuffer (PyObject *p) |
void | setUserExitDemand (const string &n) |
void | setUserExitDemand (PyObject *p) |
void | setUserExitFlow (const string &n) |
void | setUserExitFlow (PyObject *p) |
void | setUserExitOperation (const string &n) |
void | setUserExitOperation (PyObject *p) |
void | setUserExitResource (const string &n) |
void | setUserExitResource (PyObject *p) |
void | solve (void *v=NULL) |
SolverMRP (const string &n) | |
void | writeElement (XMLOutput *, const Keyword &, mode=DEFAULT) const |
virtual | ~SolverMRP () |
Static Public Member Functions | |
static PyObject * | commit (PyObject *, PyObject *) |
static bool | demand_comparison (const Demand *, const Demand *) |
static int | initialize () |
static PyObject * | rollback (PyObject *, PyObject *) |
static PyObject * | solve (PyObject *, PyObject *) |
Static Public Attributes | |
static const short | CAPACITY = 4 |
static const short | FENCE = 8 |
static const short | LEADTIME = 1 |
static const short | MATERIAL = 2 |
static const MetaClass * | metadata |
Protected Member Functions | |
bool | checkOperation (OperationPlan *, SolverMRPdata &data) |
void | checkOperationCapacity (OperationPlan *, SolverMRPdata &) |
bool | checkOperationLeadtime (OperationPlan *, SolverMRPdata &, bool) |
void | scanExcess (CommandManager *) |
void | scanExcess (CommandList *) |
void | solve (const Operation *, void *=NULL) |
void | solve (const OperationRouting *, void *=NULL) |
void | solve (const OperationAlternate *, void *=NULL) |
void | solve (const BufferInfinite *, void *=NULL) |
void | solve (const Buffer *, void *=NULL) |
void | solve (const BufferProcure *, void *=NULL) |
void | solve (const Flow *, void *=NULL) |
void | solve (const Resource *, void *=NULL) |
void | solve (const ResourceInfinite *, void *=NULL) |
void | solve (const Load *, void *=NULL) |
void | solve (const Demand *, void *=NULL) |
Protected Attributes | |
SolverMRPdata | commands |
short | constrts |
Detailed Description
This solver implements a heuristic algorithm for planning demands.
One by one the demands are processed. The demand will consume step by step any upstream materials, respecting all constraints on its path.
The solver supports all planning constraints as defined in Solver class.
See the documentation of the different solve methods to understand the functionality in more detail.
The logging levels have the following meaning:
- 0: Silent operation. Default logging level.
- 1: Show solver progress for each demand.
- 2: Show the complete ask&reply communication of the solver.
- 3: Trace the status of all entities.
Constructor & Destructor Documentation
frepple::SolverMRP::SolverMRP | ( | const string & | n | ) | [inline] |
virtual frepple::SolverMRP::~SolverMRP | ( | ) | [inline, virtual] |
Member Function Documentation
bool frepple::SolverMRP::checkOperation | ( | OperationPlan * | opplan, |
SolverMRP::SolverMRPdata & | data | ||
) | [protected] |
This function will check all constraints for an operationplan and propagate it upstream. The check does NOT check eventual sub operationplans.
The return value is a flag whether the operationplan is acceptable (sometimes in reduced quantity) or not.
Definition at line 107 of file solveroperation.cpp.
void frepple::SolverMRP::checkOperationCapacity | ( | OperationPlan * | opplan, |
SolverMRP::SolverMRPdata & | data | ||
) | [protected] |
Verifies whether this operationplan violates the capacity constraint.
In case it does the operationplan is moved to an earlier or later feasible date.
Definition at line 35 of file solveroperation.cpp.
bool frepple::SolverMRP::checkOperationLeadtime | ( | OperationPlan * | opplan, |
SolverMRP::SolverMRPdata & | data, | ||
bool | extra | ||
) | [protected] |
Verifies whether this operationplan violates the leadtime constraints.
Definition at line 344 of file solveroperation.cpp.
PyObject * frepple::SolverMRP::commit | ( | PyObject * | self, |
PyObject * | args | ||
) | [static] |
Python method for commiting the plan changes.
Definition at line 372 of file solverplan.cpp.
This function defines the order in which the demands are being planned.
The following sorting criteria are appplied in order:
- demand priority: smaller priorities first
- demand due date: earlier due dates first
- demand quantity: smaller quantities first
Definition at line 68 of file solverplan.cpp.
void frepple::SolverMRP::endElement | ( | XMLInput & | , |
const Attribute & | , | ||
const DataElement & | |||
) | [virtual] |
Called while restoring the model from an XML-file.
This is called when the corresponding close element tag is encountered, and the Data() member of pElement is valid.
Reimplemented from frepple::Solver.
Definition at line 254 of file solverplan.cpp.
PyObject * frepple::SolverMRP::getattro | ( | const Attribute & | attr | ) | [virtual] |
Default getattro method.
Subclasses are expected to implement an override if the type supports gettattro.
Reimplemented from frepple::Solver.
Definition at line 281 of file solverplan.cpp.
bool frepple::SolverMRP::getAutocommit | ( | ) | const [inline] |
short frepple::SolverMRP::getConstraints | ( | ) | const [inline] |
double frepple::SolverMRP::getIterationAccuracy | ( | ) | const [inline] |
double frepple::SolverMRP::getIterationThreshold | ( | ) | const [inline] |
TimePeriod frepple::SolverMRP::getLazyDelay | ( | ) | const [inline] |
short frepple::SolverMRP::getPlanType | ( | ) | const [inline] |
Returns the plan type:
- 1: Constrained plan.
This plan doesn't not violate any constraints.
In case of material or capacity shortages the demand is delayed or planned short. - 2: Unconstrained plan with alternate search.
This unconstrained plan leaves material, capacity and operation problems when shortages are found. Availability is searched across alternates and the remaining shortage is shown on the primary alternate.
The demand is always fully met on time. - 3: Unconstrained plan without alternate search.
This unconstrained plan leaves material, capacity and operation problems when shortages are found. It doesn't evaluate availability on alternates.
The demand is always fully met on time. The default is 1.
virtual size_t frepple::SolverMRP::getSize | ( | ) | const [inline, virtual] |
Return the memory size of the object in bytes.
Implements frepple::utils::Object.
virtual const MetaClass& frepple::SolverMRP::getType | ( | ) | const [inline, virtual] |
This returns the type information on the object, a bit similar to the standard type_info information.
Reimplemented from frepple::Solver.
PythonFunction frepple::SolverMRP::getUserExitBuffer | ( | ) | const [inline] |
PythonFunction frepple::SolverMRP::getUserExitDemand | ( | ) | const [inline] |
PythonFunction frepple::SolverMRP::getUserExitFlow | ( | ) | const [inline] |
PythonFunction frepple::SolverMRP::getUserExitOperation | ( | ) | const [inline] |
PythonFunction frepple::SolverMRP::getUserExitResource | ( | ) | const [inline] |
int frepple::SolverMRP::initialize | ( | ) | [static] |
Reimplemented from frepple::Solver.
Definition at line 54 of file solverplan.cpp.
bool frepple::SolverMRP::isCapacityConstrained | ( | ) | const [inline] |
bool frepple::SolverMRP::isConstrained | ( | ) | const [inline] |
bool frepple::SolverMRP::isFenceConstrained | ( | ) | const [inline] |
bool frepple::SolverMRP::isLeadtimeConstrained | ( | ) | const [inline] |
bool frepple::SolverMRP::isMaterialConstrained | ( | ) | const [inline] |
PyObject * frepple::SolverMRP::rollback | ( | PyObject * | self, |
PyObject * | args | ||
) | [static] |
Python method for undoing the plan changes.
Definition at line 392 of file solverplan.cpp.
void frepple::SolverMRP::scanExcess | ( | CommandManager * | mgr | ) | [protected] |
Scan the operationplans that are about to be committed to verify that they are not creating any excess.
Definition at line 346 of file solverdemand.cpp.
void frepple::SolverMRP::scanExcess | ( | CommandList * | l | ) | [protected] |
Scan the operationplans that are about to be committed to verify that they are not creating any excess.
Definition at line 353 of file solverdemand.cpp.
int frepple::SolverMRP::setattro | ( | const Attribute & | attr, |
const PythonObject & | field | ||
) | [virtual] |
Default setattro method.
Subclasses are expected to implement an override if the type supports settattro.
Reimplemented from frepple::Solver.
Definition at line 307 of file solverplan.cpp.
void frepple::SolverMRP::setAutocommit | ( | const bool | b | ) | [inline] |
void frepple::SolverMRP::setConstraints | ( | short | i | ) | [inline] |
void frepple::SolverMRP::setIterationAccuracy | ( | double | d | ) | [inline] |
void frepple::SolverMRP::setIterationThreshold | ( | double | d | ) | [inline] |
void frepple::SolverMRP::setLazyDelay | ( | TimePeriod | l | ) | [inline] |
void frepple::SolverMRP::setUserExitBuffer | ( | const string & | n | ) | [inline] |
void frepple::SolverMRP::setUserExitBuffer | ( | PyObject * | p | ) | [inline] |
void frepple::SolverMRP::setUserExitDemand | ( | const string & | n | ) | [inline] |
void frepple::SolverMRP::setUserExitDemand | ( | PyObject * | p | ) | [inline] |
void frepple::SolverMRP::setUserExitFlow | ( | const string & | n | ) | [inline] |
void frepple::SolverMRP::setUserExitFlow | ( | PyObject * | p | ) | [inline] |
void frepple::SolverMRP::setUserExitOperation | ( | const string & | n | ) | [inline] |
void frepple::SolverMRP::setUserExitOperation | ( | PyObject * | p | ) | [inline] |
void frepple::SolverMRP::setUserExitResource | ( | const string & | n | ) | [inline] |
void frepple::SolverMRP::setUserExitResource | ( | PyObject * | p | ) | [inline] |
void frepple::SolverMRP::solve | ( | const Operation * | oper, |
void * | v = NULL |
||
) | [protected, virtual] |
Behavior of this solver method is:
- It will ask the consuming flows for the required quantity.
- The quantity asked for takes into account the quantity_per of the producing flow.
- The date asked for takes into account the post-operation time of the operation.
Reimplemented from frepple::Solver.
Definition at line 459 of file solveroperation.cpp.
void frepple::SolverMRP::solve | ( | const OperationRouting * | oper, |
void * | v = NULL |
||
) | [protected, virtual] |
Behavior of this solver method is:
- Asks each of the routing steps for the requested quantity, starting with the last routing step.
The time requested for the operation is based on the start date of the next routing step.
Reimplemented from frepple::Solver.
Definition at line 555 of file solveroperation.cpp.
void frepple::SolverMRP::solve | ( | const OperationAlternate * | oper, |
void * | v = NULL |
||
) | [protected, virtual] |
Behavior of this solver method is:
- The solver loops through each alternate operation in order of priority. On each alternate operation, the solver will try to plan the quantity that hasn't been planned on higher priority alternates.
- As a special case, operations with zero priority are skipped in the loop. These operations are considered to be temporarily unavailable.
- The requested operation can be planned over multiple alternates. We don't garantuee that a request is planned using a single alternate operation.
- The solver properly considers the quantity_per of all flows producing into the requested buffer, if such a buffer is specified.
Reimplemented from frepple::Solver.
Definition at line 694 of file solveroperation.cpp.
void frepple::SolverMRP::solve | ( | const BufferInfinite * | b, |
void * | v = NULL |
||
) | [protected, virtual] |
Behavior of this solver method:
- No propagation to upstream buffers at all, even if a producing operation has been specified.
- Always give an answer for the full quantity on the requested date.
Reimplemented from frepple::Solver.
Definition at line 285 of file solverbuffer.cpp.
void frepple::SolverMRP::solve | ( | const Buffer * | b, |
void * | v = NULL |
||
) | [protected, virtual] |
Behavior of this solver method:
- Consider 0 as the hard minimum limit. It is not possible to plan with a 'hard' safety stock reservation.
- Minimum inventory is treated as a 'wish' inventory. When replenishing a buffer we try to satisfy the minimum target. If that turns out not to be possible we use whatever available supply for satisfying the demand first.
- Planning for the minimum target is part of planning a demand. There is no planning run independent of demand to satisfy the minimum target.
E.g. If a buffer has no demand on it, the solver won't try to replenish to the minimum target.
E.g. If the minimum target increases after the latest date required for satisfying a certain demand that change will not be considered. - The solver completely ignores the maximum target.
Reimplemented from frepple::Solver.
Definition at line 42 of file solverbuffer.cpp.
void frepple::SolverMRP::solve | ( | const BufferProcure * | b, |
void * | v = NULL |
||
) | [protected, virtual] |
Behavior of this solver method:
- When the inventory drops below the minimum inventory level, a new replenishment is triggered. The replenishment brings the inventory to the maximum level again.
- The minimum and maximum inventory are soft-constraints. The actual inventory can go lower than the minimum or exceed the maximum.
- The minimum, maximum and multiple size of the replenishment are hard constraints, and will always be respected.
- A minimum and maximum interval between replenishment is also respected as a hard constraint.
- No propagation to upstream buffers at all, even if a producing operation has been specified.
- The minimum calendar isn't used by the solver.
Reimplemented from frepple::Solver.
Definition at line 84 of file solverprocure.cpp.
void frepple::SolverMRP::solve | ( | const Flow * | fl, |
void * | v = NULL |
||
) | [protected, virtual] |
Behavior of this solver method:
- This method simply passes on the request to the referenced buffer. It is called from a solve(Operation*) method and passes on the control to a solve(Buffer*) method.
- See also:
- checkOperationMaterial
Reimplemented from frepple::Solver.
Definition at line 40 of file solverflow.cpp.
void frepple::SolverMRP::solve | ( | const Resource * | res, |
void * | v = NULL |
||
) | [protected, virtual] |
Behavior of this solver method:
- The operationplan is checked for a capacity overload. When detected it is moved to an earlier date.
- This move can be repeated until no capacity is found till a suitable time slot is found. If the fence and/or leadtime constraints are enabled they can restrict the feasible moving time.
If a feasible timeslot is found, the method exits here. - If no suitable time slot can be found at all, the operation plan is put on its original date and we now try to move it to a feasible later date. Again, successive moves are possible till a suitable slot is found or till we reach the end of the horizon. The result of the search is returned as the answer-date to the solver.
Reimplemented from frepple::Solver.
Definition at line 36 of file solverresource.cpp.
void frepple::SolverMRP::solve | ( | const ResourceInfinite * | res, |
void * | v = NULL |
||
) | [protected, virtual] |
Behavior of this solver method:
- Always return OK.
Reimplemented from frepple::Solver.
Definition at line 483 of file solverresource.cpp.
void frepple::SolverMRP::solve | ( | const Load * | l, |
void * | v = NULL |
||
) | [protected, virtual] |
Behavior of this solver method:
- This method simply passes on the request to the referenced resource. With the current model structure it could easily be avoided (and thus gain a bit in performance), but we wanted to include it anyway to make the solver as generic and future-proof as possible.
- See also:
- checkOperationCapacity
Reimplemented from frepple::Solver.
Definition at line 41 of file solverload.cpp.
void frepple::SolverMRP::solve | ( | const Demand * | l, |
void * | v = NULL |
||
) | [protected, virtual] |
Behavior of this solver method:
- Respects the following demand planning policies:
1) Maximum allowed lateness 2) Minimum shipment quantity This method is normally called from within the main solve method, but it can also be called independently to plan a certain demand.- See also:
- solve
Reimplemented from frepple::Solver.
Definition at line 36 of file solverdemand.cpp.
void frepple::SolverMRP::solve | ( | void * | v = NULL | ) | [virtual] |
This is the main solver method that will appropriately call the other solve methods.
The demands in the model will all be sorted with the criteria defined in the demand_comparison() method. For each of demand the solve(Demand*) method is called to plan it.
Implements frepple::Solver.
Definition at line 172 of file solverplan.cpp.
PyObject * frepple::SolverMRP::solve | ( | PyObject * | self, |
PyObject * | args | ||
) | [static] |
Python method for running the solver.
Reimplemented from frepple::Solver.
Definition at line 335 of file solverplan.cpp.
void frepple::SolverMRP::writeElement | ( | XMLOutput * | , |
const Keyword & | , | ||
mode | = DEFAULT |
||
) | const [virtual] |
Called while writing the model into an XML-file. The user class should write itself out, using the IOutStream members for its "simple" members and calling writeElement recursively for any contained objects. Not all classes are expected to implement this method. In instances of such a class can be created but can't be persisted. E.g. Command
Reimplemented from frepple::Solver.
Definition at line 216 of file solverplan.cpp.
Member Data Documentation
const short frepple::SolverMRP::CAPACITY = 4 [static] |
SolverMRPdata frepple::SolverMRP::commands [protected] |
short frepple::SolverMRP::constrts [protected] |
const short frepple::SolverMRP::FENCE = 8 [static] |
const short frepple::SolverMRP::LEADTIME = 1 [static] |
const short frepple::SolverMRP::MATERIAL = 2 [static] |
const MetaClass * frepple::SolverMRP::metadata [static] |
Reimplemented from frepple::Solver.
The documentation for this class was generated from the following files:
Documentation generated for frePPLe by
