Core namespace. More...
Namespaces | |
namespace | utils |
Utilities for the frePPle core. | |
Classes | |
class | Buffer |
A buffer represents a combination of a item and location. It is the entity for keeping modeling inventory. More... | |
class | BufferDefault |
This class is the default implementation of the abstract Buffer class. More... | |
class | BufferInfinite |
This class represents a material buffer with an infinite supply of extra material. More... | |
class | BufferIterator |
class | BufferProcure |
This class models a buffer that is replenish by an external supplier using a reorder-point policy. More... | |
class | Calendar |
This is the class used to represent variables that are varying over time. More... | |
class | CalendarBucketIterator |
class | CalendarDouble |
A calendar storing double values in its buckets. More... | |
class | CalendarEventIterator |
class | CalendarIterator |
class | CommandCreateOperationPlan |
This command is used to create an operationplan. More... | |
class | CommandDeleteOperationPlan |
This command is used to delete an operationplan. More... | |
class | CommandMoveOperationPlan |
This class represents the command of moving an operationplan to a new date and/or resizing it. More... | |
class | Customer |
This abstracts class represents customers. More... | |
class | CustomerDefault |
This class implements the abstract Customer class. More... | |
class | CustomerIterator |
class | Demand |
Represents the (independent) demand in the system. It can represent a customer order or a forecast. More... | |
class | DemandDefault |
This class is the default implementation of the abstract Demand class. More... | |
class | DemandIterator |
class | DemandPlanIterator |
class | Flow |
This class defines a material flow to/from a buffer, linked with an operation. This default implementation plans the material flow at the start of the operation. More... | |
class | FlowEnd |
This class defines a material flow to/from a buffer, linked with an operation. This subclass represents a flow that is at end date of the operation. More... | |
class | FlowIterator |
class | FlowPlan |
A flowplan represents a planned material flow in or out of a buffer. More... | |
class | FlowPlanIterator |
class | FlowStart |
This class defines a material flow to/from a buffer, linked with an operation. This subclass represents a flow that is at the start date of the operation. More... | |
class | HasLevel |
The purpose of this class is to compute the levels of all buffers, operations and resources in the model, and to categorize them in clusters. More... | |
class | HasProblems |
Classes that keep track of problem conditions need to implement this class. More... | |
class | Item |
An item defines the products being planned, sold, stored and/or manufactured. Buffers and demands have a reference an item. More... | |
class | ItemDefault |
This class is the default implementation of the abstract Item class. More... | |
class | ItemIterator |
class | LibraryModel |
This class is used for initialization. More... | |
class | LibrarySolver |
This class holds functions that used for maintenance of the solver code. More... | |
class | Load |
This class links a resource to a certain operation. More... | |
class | LoadIterator |
class | LoadPlan |
This class represents the resource capacity of an operationplan. More... | |
class | LoadPlanIterator |
class | Location |
This abstract class is used to associate buffers and resources with a physical or logical location. More... | |
class | LocationDefault |
This class implements the abstract Location class. More... | |
class | LocationIterator |
class | Operation |
An operation represents an activity: these consume and produce material, take time and also require capacity. More... | |
class | OperationAlternate |
This class represents a choice between multiple operations. The alternates are sorted in order of priority. More... | |
class | OperationFixedTime |
Models an operation that takes a fixed amount of time, independent of the quantity. More... | |
class | OperationIterator |
class | OperationPlan |
An operationplan is the key dynamic element of a plan. It represents a certain quantity being planned along a certain operation during a certain date range. More... | |
class | OperationPlanIterator |
class | OperationPlanState |
A simple class to easily remember the date, quantity and owner of an operationplan. More... | |
class | OperationRouting |
Represents a routing operation, i.e. an operation consisting of multiple, sequential sub-operations. More... | |
class | OperationSetup |
Models an operation to convert a setup on a resource. More... | |
class | OperationTimePer |
Models an operation whose duration is the sum of a constant time, plus a cetain time per unit. More... | |
class | PeggingIterator |
This class allows upstream and downstream navigation through the plan. More... | |
class | Plan |
This is the (logical) top class of the complete model. More... | |
class | Plannable |
This class needs to be implemented by all classes that implement dynamic behavior in the plan. More... | |
class | Problem |
A problem represents infeasibilities, alerts and warnings in the plan. More... | |
class | ProblemBeforeCurrent |
A problem of this class is created when an operationplan is being planned in the past, i.e. it starts before the "current" date of the plan. More... | |
class | ProblemBeforeFence |
A problem of this class is created when an operationplan is being planned before its fence date, i.e. it starts 1) before the "current" date of the plan plus the release fence of the operation and 2) after the current date of the plan. More... | |
class | ProblemCapacityOverload |
A problem of this class is created when a resource is being overloaded during a certain period of time. More... | |
class | ProblemCapacityUnderload |
A problem of this class is created when a resource is loaded below its minimum during a certain period of time. More... | |
class | ProblemDemandNotPlanned |
A Problem of this class is created in the model when a new demand is brought in the system, but it hasn't been planned yet. More... | |
class | ProblemEarly |
A problem of this class is created when a demand is planned earlier than the accepted tolerance before its due date. More... | |
class | ProblemExcess |
A problem of this class is created when a demand is planned for more than the requested quantity. More... | |
class | ProblemInvalidData |
A Problem of this class is created in the model when a data exception prevents planning of certain objects. More... | |
class | ProblemIterator |
class | ProblemLate |
A problem of this class is created when a demand is satisfied later than the accepted tolerance after its due date. More... | |
class | ProblemMaterialExcess |
A problem of this class is created when a buffer is carrying too much material during a certain period of time. More... | |
class | ProblemMaterialShortage |
A problem of this class is created when a buffer is having a material shortage during a certain period of time. More... | |
class | ProblemPrecedence |
A problem of this class is created when the sequence of two operationplans in a routing isn't respected. More... | |
class | ProblemShort |
A problem of this class is created when a demand is planned for less than the requested quantity. More... | |
class | Resource |
This class represents a workcentre, a physical or logical representation of capacity. More... | |
class | ResourceDefault |
This class is the default implementation of the abstract Resource class. More... | |
class | ResourceInfinite |
This class represents a resource that'll never have any capacity shortage. More... | |
class | ResourceIterator |
class | SetupMatrix |
This class is used to represent a matrix defining the changeover times between setups. More... | |
class | SetupMatrixDefault |
This class is the default implementation of the abstract SetupMatrix class. More... | |
class | SetupMatrixIterator |
class | SetupMatrixRuleIterator |
class | Solvable |
This class needs to be implemented by all classes that implement dynamic behavior, and which can be called by a solver. More... | |
class | Solver |
This class is an implementation of the "visitor" design pattern. It is intended as a basis for different algorithms processing the frePPLe data. More... | |
class | SolverIterator |
class | SolverMRP |
This solver implements a heuristic algorithm for planning demands. More... | |
Enumerations | |
enum | SearchMode { PRIORITY = 0, MINCOST = 1, MINPENALTY = 2, MINCOSTPENALTY = 3 } |
Functions | |
SearchMode | decodeSearchMode (const string &c) |
PyObject * | eraseModel (PyObject *self, PyObject *args) |
This Python function erases the model or the plan from memory. | |
ostream & | operator<< (ostream &os, const SearchMode &d) |
PyObject * | printModelSize (PyObject *self, PyObject *args) |
This Python function prints a summary of the dynamically allocated memory to the standard output. This is useful for understanding better the size of your model. | |
PyObject * | readXMLdata (PyObject *, PyObject *) |
This Python function is used for processing XML input data from a string. | |
PyObject * | readXMLfile (PyObject *, PyObject *) |
This Python function is used for reading XML input. | |
PyObject * | savePlan (PyObject *, PyObject *) |
This Python function writes the dynamic part of the plan to an text file. | |
PyObject * | saveXMLfile (PyObject *, PyObject *) |
This python function writes the complete model to an XML-file. | |
bool | sortFlow (const Flow *lhs, const Flow *rhs) |
bool | sortLoad (const Load *lhs, const Load *rhs) |
double | suggestQuantity (const BufferProcure *b, double f) |
Detailed Description
Core namespace.
Enumeration Type Documentation
enum frepple::SearchMode |
This type defines what mode used to search the alternates.
- Enumerator:
Function Documentation
SearchMode frepple::decodeSearchMode | ( | const string & | c | ) |
Translate a string to a search mode value.
Definition at line 1042 of file operation.cpp.
PyObject * frepple::eraseModel | ( | PyObject * | self, |
PyObject * | args | ||
) |
This Python function erases the model or the plan from memory.
The function allows the following modes to control what to delete:
- plan:
Deletes the dynamic modelling constructs, such as operationplans, loadplans and flowplans only. Locked operationplans are not deleted.
The static model is left intact.
This is the default mode. - model:
The dynamic as well as the static objects are removed. You'll end up with a completely empty model. Due to the logic required in the object destructors this mode doesn't scale linear with the model size.
Definition at line 397 of file model/actions.cpp.
ostream& frepple::operator<< | ( | ostream & | os, |
const SearchMode & | d | ||
) | [inline] |
PyObject * frepple::printModelSize | ( | PyObject * | self, |
PyObject * | args | ||
) |
This Python function prints a summary of the dynamically allocated memory to the standard output. This is useful for understanding better the size of your model.
The numbers reported by this function won't match the memory size as reported by the operating system, since the dynamically allocated memory is only a part of the total memory used by a program.
Definition at line 453 of file model/actions.cpp.
PyObject * frepple::readXMLdata | ( | PyObject * | , |
PyObject * | |||
) |
This Python function is used for processing XML input data from a string.
The function takes up to three arguments:
- XML data string to be processed
- Optional validate flag, defining whether or not the input data needs to be validated against the XML schema definition. The validation is switched ON by default. Switching it ON is recommended in situations where there is no 100% guarantee on the validity of the input data.
- Optional validate_only flag, which allows us to validate the data but skip any processing.
Definition at line 83 of file model/actions.cpp.
PyObject * frepple::readXMLfile | ( | PyObject * | , |
PyObject * | |||
) |
This Python function is used for reading XML input.
The function takes up to three arguments:
- XML data file to be processed. If this argument is omitted or None, the standard input is read.
- Optional validate flag, defining whether or not the input data needs to be validated against the XML schema definition. The validation is switched ON by default. Switching it ON is recommended in situations where there is no 100% guarantee on the validity of the input data.
- Optional validate_only flag, which allows us to validate the data but skip any processing.
Definition at line 38 of file model/actions.cpp.
PyObject * frepple::savePlan | ( | PyObject * | , |
PyObject * | |||
) |
This Python function writes the dynamic part of the plan to an text file.
This saved information covers the buffer flowplans, operationplans, resource loading, demand, problems, etc...
The main use of this function is in the test suite: a simple text file comparison allows us to identify changes quickly. The output format is only to be seen in this context of testing, and is not intended to be used as an official method for publishing plans to other systems.
Definition at line 162 of file model/actions.cpp.
PyObject * frepple::saveXMLfile | ( | PyObject * | , |
PyObject * | |||
) |
This python function writes the complete model to an XML-file.
Both the static model (i.e. items, locations, buffers, resources, calendars, etc...) and the dynamic data (i.e. the actual plan including the operationplans, demand, problems, etc...).
The format is such that the output file can be re-read to restore the very same model.
The function takes the following arguments:
- Name of the output file
- Type of output desired: STANDARD, PLAN or PLANDETAIL. The default value is STANDARD.
Definition at line 120 of file model/actions.cpp.
bool frepple::sortFlow | ( | const Flow * | lhs, |
const Flow * | rhs | ||
) |
Definition at line 33 of file solverflow.cpp.
bool frepple::sortLoad | ( | const Load * | lhs, |
const Load * | rhs | ||
) |
Definition at line 34 of file solverload.cpp.
double frepple::suggestQuantity | ( | const BufferProcure * | b, |
double | f | ||
) |
Definition at line 34 of file solverprocure.cpp.
Documentation generated for frePPLe by
