Main > Reference Manual > Modeling > Solver

A solver represents modules of functionality that manipulate the model.
Examples are solvers to generate a plan, solvers to compute safety stocks, solvers to create production or purchase orders, etc...

Only one solver is included in the core library: solver_mrp, which uses a heuristic algorithm to generate plans.
Other solvers are implemented as optional modules.

For running a solver see the command command_solve.

Fields and methods

Field Type Description
name non-empty string

Name of the solver.
This is the key field and a required attribute.

loglevel 0 - 3

Amount of logging and debugging messages:

  • 0: Silent operation. Default logging level.
  • 1: Show minimum output.
  • 2: Show standard output.
  • 3: Show debugging output.
action A
C
AC (default)
R

Type of action to be executed:

  • A: Add an new entity, and report an error if the entity already exists.
  • C: Change an existing entity, and report an error if the entity doesn't exist yet.
  • AC: Change an entity or create a new one if it doesn't exist yet.
  • R: Remove an entity, and report an error if the entity doesn't exist.
Method Description
solve()

This method runs the solver algorithm.

solver_mrp

Field Type Description
plantype unsignedShort The type of plan being generated:
  • 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 in 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.

constraints unsignedShort

Sum up the values of the constraints you want to enable in the solver:

  • 1: Lead times, ie don't plan in the past
  • 2: Material supply, ie don't allow inventory values to go negative
  • 4: Capacity, ie don't allow to overload resources
  • 8: Operation fences, ie don't allow to create plans in the frozen fence of operations

The default value is 15, ie all constraints are enabled.

maxparallel positive integer

Specifies the number of parallel threads the solver creates during planning.
The default value depends on whether the solver is run in verbose mode or not:

  • In normal mode the solver uses as many threads as specified by the NUMBER_OF_PROCESSORS environment variable.
  • When the logging level is different from 0 the solver runs in a single thread to avoid mangling the debugging output of different threads.
iterationthreshold double In certain models the solver algorithm will iteratively solve to get better approximations. This iterations stop when the difference between iterations is below this threshold.
The value is a positive value and its default is 1.
iterationaccuracy double In certain models the solver algorithm will iteratively solve to get better approximations. This parameter sets the desired accuracy level.
The value must be between 0 and 100 and the default is 1%.
autocommit boolean

When true (which is the default) the plan changes are automatically committed after planning a demand.
When false the plan changes need to explicitly committed or undone.

userexit_buffer Python function The Python function registered in this field as a callback function is called automatically when the solver is about to plan a buffer.
The function is passed two arguments: the buffer being evaluated and a boolean that specifies whether the planning mode is constrained or not. The return value of the function is not used.
userexit_demand Python function The Python function registered in this field as a callback function is called automatically when the solver is about to plan a demand.
The function is passed two arguments: the demand being planned and a boolean that specifies whether the planning mode is constrained or not. The return value of the function is not used.
This user exit enables users to plug in customized logic to adjust the planning parameters in the supply path, or to print debugging information.
Note that changes to the due date, quantity or priority of the demand are possible, but such changes won't influence the sort order of the demand compared to other demands any more.
userexit_flow Python function The Python function registered in this field as a callback function is called automatically when the solver evaluates alternate flows.
The function is passed two arguments: the flowplan being evaluated and a boolean that specifies whether the planning mode is constrained or not. When the function returns True the alternate is acceptable. When it returns False the alternate is not acceptable.
This user exit enables users to plug in customized logic to control complex configuration rules in the bill of material.
userexit_operation Python function The Python function registered in this field as a callback function is called automatically when the solver is about to plan an operation.
The function is passed two arguments: the operation being evaluated and a boolean that specifies whether the planning mode is constrained or not. The return value of the function is not used.
userexit_resource Python function The Python function registered in this field as a callback function is called automatically when the solver is about to plan a resource.
The function is passed two arguments: the resource being evaluated and a boolean that specifies whether the planning mode is constrained or not. The return value of the function is not used.
Method Description
solve()
solve([Demand])

Without arguments it recreates the complete plan.
When a demand is passed as argument, the demand is planned incrementally.

commit()

Commits the changes to the plan.
This method is only meaningfull when the autocommit flag is set to false.

undo()

Undo the changes to the plan.
This method is only meaningfull when the autocommit flag is set to false.

Example XML structures

  • Adding or changing a solver
 <plan>
    <solvers>
       <solver name="MRP" xsi-type="solver_mrp">
         <constraints>7</constraints>
         <maxparallel>2</maxparallel>
       </solver> 
    </solvers>
 </plan>
  • Deleting a solver
 <plan>
    <solvers>
       <solver name="MRP" action="R"/>
    </solvers>
 </plan>

Example Python code

  • Adding or changing a solver, and running it
    sol = frepple.solver_mrp(name="MRP", constraints=7, maxparallel=2)
    sol.solve()
  • Deleting a solver
    frepple.solver(name="MRP", action="R")