Skip to main content

Type Alias: Parameters

Parameters = { absoluteGapTolerance?: number; absoluteImprovementStep?: number; color?: "Never" | "Auto" | "Always"; cumulPropagationLevel?: number; fdsDualStrategy?: "Minimum" | "Random" | "Split"; integralPropagationLevel?: number; lnsMode?: "Auto" | "Robust" | "Focused"; lnsUseWarmStartOnly?: boolean; logLevel?: number; logPeriod?: number; nbWorkers?: number; noOverlapPropagationLevel?: number; noOverlapTransitionPropagationLevel?: number; positionPropagationLevel?: number; preset?: "Auto" | "Default" | "Large"; printLog?: NodeJS.WritableStream | boolean; processExitTimeout?: number; randomSeed?: number; relativeGapTolerance?: number; relativeImprovementStep?: number; reservoirPropagationLevel?: number; searchType?: "Auto" | "LNS" | "FDS" | "FDSDual" | "SetTimes" | "FDSLB"; simpleLBWorker?: number; solutionLimit?: number; solver?: string; solverArgs?: string[]; timeLimit?: number; usePrecedenceEnergy?: number; verifyExternalSolutions?: boolean; verifySolutions?: boolean; warningLevel?: number; workers?: WorkerParameters[]; }

Parameters specify how the solver should behave.

Remarks​

Parameters specify how the solver should behave. For example, the number of workers (threads) to use, the time limit, etc.

Parameters can be passed to the solver functions Model.solve and Solver.solve.

Examples​

In the following example, we are using the TimeLimit parameter to specify that the solver should stop after 5 minutes. We also specify that the solver should use 4 threads. Finally, we specify that the solver should use FDS search (in all threads).

let params = {
  timeLimit: 300, // In seconds, i.e. 5 minutes
  nbWorkers: 4,   // Use 4 threads
  searchType: "FDS"
};
let result = await myModel.solve(params);

Worker-specific parameters​

Some parameters can be specified differently for each worker. For example, some workers may use LNS search while others use FDS search. To specify worker-specific parameters, use the workers parameter and pass an array of WorkerParameters.

Not all parameters can be specified per worker. For example, TimeLimit is a global parameter. See WorkerParameters for the list of parameters that can be specified per worker.

If a parameter is not set specifically for a worker, the global value is used.

In the following example, we are going to use 4 workers; two of them will run FDS search and the remaining two will run LNS search. In addition, workers that use FDS search will use increased propagation levels.

// Parameters for a worker that uses FDS search.
// FDS works best with increased propagation levels, so set them:
let fdsWorker: CP.WorkerParameters = {
  searchType: "FDS",
  noOverlapPropagationLevel: 4,
  cumulPropagationLevel: 3,
  reservoirPropagationLevel: 2
};
// Global parameters:
let params = {
  timeLimit: 60,       // In seconds, i.e. 1 minute
  searchType: "LNS",   // The default search type. It is not necessary, as "LNS" is the default value.
  nbWorkers: 4,        // Use 4 threads
  // The first two workers will use FDS search.
  // The remaining two workers will use the defaults, i.e., LNS search with default propagation levels.
  workers: [fdsWorker, fdsWorker],
};
let result = await myModel.solve(params);

See​

WorkerParameters for worker-specific parameters.

Parameters​

solver?​

optional solver?: string

Path to the solver executable or WebSocket URL.

Remarks​

Specifies how to connect to the solver.

  • Local path: Path to the optalcp executable (e.g., /usr/bin/optalcp). The API spawns the solver as a subprocess.
  • WebSocket URL: URL starting with ws://, wss://, http://, or https:// (e.g., ws://localhost:8080). The API connects via WebSocket to a remote solver. In browser environments, a WebSocket URL is required since browsers cannot spawn local processes.

If not specified, the solver is searched as described in Solver.findSolver.

See​

solverArgs?​

optional solverArgs?: string[]

Additional command-line arguments for the solver subprocess.

Remarks​

These arguments are passed directly to the solver subprocess when it is spawned. This parameter is only used in subprocess mode (not when connecting to a remote solver via WebSocket).

This can be useful for debugging or passing special flags to the solver that are not exposed through the Parameters API.

import * as cp from '@scheduleopt/optalcp';

const model = new cp.Model();
// ... build model ...

// Pass custom arguments to the solver
const result = await model.solve({
  solverArgs: ['--some-debug-flag'],
  timeLimit: 60
});

See​

Parameters.solver to specify a custom solver path.

workers?​

optional workers?: WorkerParameters[]

Per-worker parameter overrides.

Remarks​

Each worker can have its own parameters. If a parameter is not specified for a worker, then the global value is used.

Note that parameter Parameters.nbWorkers specifies the number of workers regardless of the length of this list.

See​

WorkerParameters for the list of parameters that can be set per worker.

fdsDualStrategy?​

optional fdsDualStrategy?: "Minimum" | "Random" | "Split"

A strategy to choose objective cuts during FDSDual search.

Remarks​

Possible values are:

  • Minimum: Always change the cut by the minimum amount.
  • Random: At each restart, randomly choose a value in range LB..UB. The default.
  • Split: Always split the current range LB..UB in half.

The default value is Random.

Gap Tolerance​

absoluteGapTolerance?​

optional absoluteGapTolerance?: number

Stop the search when the gap is below the tolerance

Remarks​

The search is stopped if the absolute difference between the current solution value and current lower/upper bound is not bigger than the specified value.

This parameter works together with Parameters.relativeGapTolerance as an OR condition: the search stops when either the absolute gap or the relative gap is within tolerance.

The gap tolerance only decides when the search stops. How much better the next solution must be is set by Parameters.absoluteImprovementStep and Parameters.relativeImprovementStep. The search never asks for a smaller improvement than the gap tolerance allows to ignore.

The parameter takes a floating point value.

The default value is 0.

absoluteImprovementStep?​

optional absoluteImprovementStep?: number

Minimum absolute improvement of the next solution

Remarks​

When the search finds a solution, it then looks only for solutions that are better at least by the specified value. A bigger step skips small improvements and can reach good solutions faster.

The step never leads to a false claim of optimality. When the search fails to find a solution better by the step, it does not claim optimality. Instead it proves a new lower/upper bound and continues with a smaller step. The search stops only when the gap is within Parameters.absoluteGapTolerance or Parameters.relativeGapTolerance.

However, LNS search proves new bounds only rarely. So an LNS worker can miss improvements smaller than the step. With a time limit, the solve can then end with a worse solution than with a smaller step.

This parameter works together with Parameters.relativeImprovementStep as an OR condition: the bigger of the two improvements is required. The step used by the search is never smaller than the gap tolerance.

For integer objectives, the search always requires an improvement of at least 1.

The parameter takes a floating point value.

The default value is 0.

relativeGapTolerance?​

optional relativeGapTolerance?: number

Stop the search when the gap is below the tolerance

Remarks​

The search is stopped if the relative difference between the current solution value and current lower/upper bound is not bigger than the specified value.

This parameter works together with Parameters.absoluteGapTolerance as an OR condition: the search stops when either the absolute gap or the relative gap is within tolerance.

The gap tolerance only decides when the search stops. How much better the next solution must be is set by Parameters.absoluteImprovementStep and Parameters.relativeImprovementStep. The search never asks for a smaller improvement than the gap tolerance allows to ignore.

The parameter takes a floating point value.

The default value is 0.

relativeImprovementStep?​

optional relativeImprovementStep?: number

Minimum relative improvement of the next solution

Remarks​

When the search finds a solution, it then looks only for solutions that are better at least by the specified fraction of the objective value. A bigger step skips small improvements and can reach good solutions faster.

The step never leads to a false claim of optimality. When the search fails to find a solution better by the step, it does not claim optimality. Instead it proves a new lower/upper bound and continues with a smaller step. The search stops only when the gap is within Parameters.absoluteGapTolerance or Parameters.relativeGapTolerance.

However, LNS search proves new bounds only rarely. So an LNS worker can miss improvements smaller than the step. With a time limit, the solve can then end with a worse solution than with a smaller step.

This parameter works together with Parameters.absoluteImprovementStep as an OR condition: the bigger of the two improvements is required. The step used by the search is never smaller than the gap tolerance.

The parameter takes a floating point value.

The default value is 0.0001.

lnsMode?​

optional lnsMode?: "Auto" | "Robust" | "Focused"

LNS solution pool strategy.

Remarks​

Controls how LNS manages its solution pool.

  • Auto: Let the Parameters.preset decide (the default). The Default preset resolves Auto to Robust; the Large preset resolves it to Focused.

  • Robust: Maintain multiple solution tiers for diverse exploration. The solver keeps several solutions of varying quality and occasionally works on improving worse solutions. This provides robustness against getting stuck in local optima.

  • Focused: Concentrate all LNS effort on improving the best solution. Secondary solution tiers are disabled, reducing memory and CPU overhead. Recommended for large problems where maintaining multiple solutions is too expensive.

The Large Parameters.preset automatically selects Focused mode. If you explicitly set lnsMode to Robust or Focused, your value takes precedence over the preset — for example, setting Robust keeps the multiple solution tiers even under the Large preset.

import * as CP from "optalcp";

let model = new CP.Model();
// ... build your model ...

// Default: robust mode with multiple solution tiers
let result = await model.solve();

// Focused mode for large problems
result = await model.solve({ lnsMode: "Focused" });

// Or use the Large preset, which enables Focused mode automatically
result = await model.solve({ preset: "Large" });

See​

lnsUseWarmStartOnly?​

optional lnsUseWarmStartOnly?: boolean

Use only the user-provided warm start as the initial solution in LNS

Remarks​

When this parameter is on, the solver will use only the user-specified warm start solution for the initial solution phase in LNS. If no warm start is provided, the solver will search for its own initial solution as usual.

The default value is false.

Limits​

solutionLimit?​

optional solutionLimit?: number

Stop the search after the given number of solutions

Remarks​

Terminates the solve after the specified number of solutions have been found and reported.

Automatic behavior (value 0):

When set to 0 (the default), the limit is determined automatically based on the problem type:

  • Decision problems (no objective): The solver stops after finding the first solution. This is usually what you want for feasibility problems.

  • Optimization problems: No limit is applied. The solver continues searching for better solutions until it proves optimality, hits another limit (like Parameters.timeLimit), or is stopped manually.

Explicit values:

You can set an explicit limit to control solution enumeration:

  • 1: Stop after the first solution. Useful when you just need any feasible solution quickly, even for optimization problems.

  • N > 1: Find up to N solutions. Useful for:

    • Generating multiple alternative solutions for warm starts
    • Enumerating all solutions to small problems
    • Finding a diverse set of solutions for analysis

Note on optimization problems:

For optimization problems, only improving solutions are counted. If you set solutionLimit=5, the solver will stop after finding 5 solutions, each better than the previous. Non-improving solutions (which can occur during the search) are not counted toward the limit.

Note on LNS and decision problems:

When using LNS search (see Parameters.searchType) on decision problems (no objective), be aware that LNS may report duplicate solutions. LNS works by iteratively improving a solution, and for decision problems without an objective to guide the search, it may find the same solution multiple times. If you need unique solutions, consider using FDS search instead, or filter duplicates in your application code.

import * as CP from "optalcp";

let model = new CP.Model();
// ... build your model ...

// Automatic behavior (default)
// - Decision problem: stops after 1 solution
// - Optimization: no limit
let result = await model.solve();

// Stop after first solution (useful for quick feasibility check)
result = await model.solve({ solutionLimit: 1 });

// Find up to 10 solutions for warm starts
result = await model.solve({ solutionLimit: 10 });

See​

Parameters.timeLimit for limiting solve time.

timeLimit?​

optional timeLimit?: number

Wall clock limit for execution in seconds

Remarks​

Caps the total wall-clock time spent by the solver. The timer starts as soon as the solve begins, and it includes presolve, search, and verification. When the limit is reached, all workers stop cooperatively. Leave it at the default Infinity to run without a time bound.

The parameter takes a floating point value in range 0..Infinity.

The default value is Infinity.

Major options​

logLevel?​

optional logLevel?: number

Level of the log

Remarks​

This parameter controls the amount of text the solver writes on standard output. The solver is completely silent when this option is set to 0.

The parameter takes an integer value in range 0..3.

The default value is 2.

logPeriod?​

optional logPeriod?: number

How often to print log messages (in seconds)

Remarks​

When Parameters.logLevel ≥ 2 then solver writes a log message every logPeriod seconds. The log message contains the current statistics about the solve: number of branches, number of fails, memory used, etc.

The parameter takes a floating point value in range 0.01..Infinity.

The default value is 10.

nbWorkers?​

optional nbWorkers?: number

Number of threads dedicated to search

Remarks​

When this parameter is 0 (the default), the number of workers is determined the following way:

  • If environment variable OPTALCP_NB_WORKERS is set, its value is used.
  • Otherwise, all available cores are used.

The parameter takes an integer value.

The default value is 0.

preset?​

optional preset?: "Auto" | "Default" | "Large"

Preset configuration for solver parameters

Remarks​

Presets provide reasonable default values for multiple solver parameters at once. Instead of manually tuning individual parameters, you can select a preset that matches your problem characteristics. The solver will then configure search strategies and propagation levels appropriately.

Available presets:

  • Auto: The solver automatically selects a preset based on problem size (the default). Problems with more than 100,000 variables use Large, otherwise Default.

  • Default: Balanced configuration for most problems. Uses strong propagation and distributes workers across different search strategies: half use LNS, 3/8 use FDS, and the rest use FDSDual. This provides a good mix of exploration and exploitation.

  • Large: Optimized for big problems with more than 100,000 variables. Uses weaker propagation to reduce overhead, all workers use LNS search, and Parameters.lnsMode is set to Focused. This trades propagation strength for scalability.

Parameters affected by presets:

The preset sets default values for the following parameters:

When you explicitly set any of these parameters, your value takes precedence over the preset's default. This allows you to use a preset as a starting point and fine-tune specific parameters as needed.

When to use presets:

Presets are a good starting point for most problems. They are not guaranteed to be optimal for your specific problem, but they provide reasonable defaults that work well in practice. If you find that the default preset is not working well for your problem, consider:

  • Trying the Large preset for very big problems, even if they have fewer than 100,000 variables
  • Explicitly setting Parameters.searchType to use a specific search strategy
  • Adjusting propagation levels based on your problem structure
import * as CP from "optalcp";

let model = new CP.Model();
// ... build your model ...

// Use automatic preset selection
let result = await model.solve();

// Or explicitly select a preset for a large problem
result = await model.solve({ preset: "Large" });

// Or use Default preset but override search type
result = await model.solve({ preset: "Default", searchType: "FDS" });

See​

processExitTimeout?​

optional processExitTimeout?: number

Timeout for solver process to exit after finishing

Remarks​

After the solver finishes, wait up to this many seconds for the process to exit. If it doesn't exit in time, it is silently killed.

The parameter takes a floating point value in range 0..Infinity.

The default value is 3.

randomSeed?​

optional randomSeed?: number

Random seed

Remarks​

The solver breaks ties randomly using a pseudorandom number generator. This parameter sets the seed of the generator.

Note that when Parameters.nbWorkers is more than 1 then there is also another source of randomness: the time it takes for a message to pass from one worker to another. Therefore with 1 worker the solver is deterministic (random behavior depends only on random seed). With more workers the solver is not deterministic.

Even with the same random seed, the solver may behave differently on different platforms. This can be due to different implementations of certain functions such as std::sort.

The parameter takes an integer value.

The default value is 1.

Environment variable OPTALCP_RANDOM_SEED​

When randomSeed is not explicitly set (i.e. it remains at its default value of 1), the solver checks the environment variable OPTALCP_RANDOM_SEED. If the variable is set:

  • A numeric value (e.g. 42) is used directly as the random seed.
  • The special value RANDOM (case-insensitive) tells the solver to generate a time-based seed.

This is useful for randomizing test runs without changing application code.

searchType?​

optional searchType?: "Auto" | "LNS" | "FDS" | "FDSDual" | "SetTimes" | "FDSLB"

Type of search to use

Remarks​

This parameter controls which search algorithm the solver uses. Different search types have different strengths:

  • Auto: Automatically determined based on the Parameters.preset (the default). With the Default preset, workers are distributed across LNS, FDS, and FDSDual. With the Large preset, all workers use LNS.

  • LNS: Large Neighborhood Search. Starts from an initial solution and iteratively improves it by relaxing and re-optimizing parts of the solution. Good for finding high-quality solutions quickly, especially on large problems. Works best when a good initial solution can be found.

  • FDS: Failure-Directed Search. A systematic search that learns from failures to guide exploration. Uses restarts with no-good learning. Often effective at proving optimality and works well with strong propagation.

  • FDSDual: Failure-Directed Search working on objective bounds. Similar to FDS but focuses on proving bounds on the objective value. Useful for optimization problems where you want to know how far from optimal your solutions are.

  • SetTimes: Depth-first set-times search (not restarted). A simple chronological search that assigns start times in order. Can be effective for tightly constrained problems but generally less robust than other methods.

Interaction with presets:

When searchType is set to Auto, the actual search type is determined by the Parameters.preset:

  • Default preset: Distributes workers across different search types. Half use LNS, 3/8 use FDS, and the rest use FDSDual. This portfolio approach provides robustness across different problem types.

  • Large preset: All workers use LNS. For very large problems, the overhead of systematic search methods like FDS becomes prohibitive, so LNS is used exclusively.

If you explicitly set searchType to a specific value (not Auto), that value is used regardless of the preset.

import * as CP from "optalcp";

let model = new CP.Model();
// ... build your model ...

// Let the preset decide (default behavior)
let result = await model.solve();

// Or explicitly use FDS for systematic search
result = await model.solve({ searchType: "FDS" });

// Or use LNS for quick solutions on large problems
result = await model.solve({ searchType: "LNS" });

See​

verifyExternalSolutions?​

optional verifyExternalSolutions?: boolean

Whether to verify correctness of external solutions

Remarks​

External solutions can be passed to the solver as a warm start via Model.solve, or using Solver.sendSolution during the search. Normally, all external solutions are checked before they are used. However, the check may be time consuming, especially if too many external solutions are sent simultaneously. This parameter allows to turn the check off.

The default value is true.

verifySolutions?​

optional verifySolutions?: boolean

When on, the correctness of solutions is verified

Remarks​

Verification is an independent algorithm that checks whether all constraints in the model are satisfied (or absent), and that objective value was computed correctly. Verification is a somewhat redundant process as all solutions should be correct. Its purpose is to double-check and detect bugs in the solver.

The default value is false.

warningLevel?​

optional warningLevel?: number

Level of warnings

Remarks​

This parameter controls the types of warnings the solver emits. When this parameter is set to 0 then no warnings are emitted.

The parameter takes an integer value in range 0..3.

The default value is 2.

Propagation levels​

cumulPropagationLevel?​

optional cumulPropagationLevel?: number

How much to propagate constraints on cumul functions

Remarks​

This parameter controls the amount of propagation done for CumulExpr.le constraint when used with a sum of Model.pulse pulses.

Higher levels use more sophisticated algorithms that can detect more infeasibilities and prune more values from domains, but at the cost of increased computation time.

Propagation levels:

  • Level 1: Basic timetable propagation
  • Level 2: Adds time-table edge-finding
  • Level 3: Adds disjunctive reasoning between pulses that are too high to overlap
  • Level 4: Maximum propagation. Adds a redundant Model.noOverlap over the pulses higher than half of the capacity, and max-energy reasoning that limits the length and height of pulses whose length or height is not fixed

Automatic selection (level 0):

When set to 0 (the default), the Parameters.preset chooses the level. The Default preset uses strong propagation. The Large preset uses a lower level to reduce the propagation overhead on big models. The exact levels may change between versions.

Performance considerations:

More propagation doesn't necessarily mean better overall performance. The trade-off depends on your problem:

  • Resource-constrained problems with tight capacity limits often benefit from higher propagation levels because cumulative reasoning can prune many infeasible assignments.

  • Problems with loose resource constraints may not benefit much from higher levels because the extra computation doesn't lead to significant pruning.

  • Very large problems may perform better with lower propagation levels because the overhead becomes prohibitive.

  • FDS search (see Parameters.searchType) typically benefits from higher propagation levels.

If you're unsure, start with the automatic selection (level 0) and let the preset choose.

import * as CP from "optalcp";

let model = new CP.Model();
// ... build your model with cumulative constraints ...

// Let the preset decide (default)
let result = await model.solve();

// Or use maximum propagation for resource-constrained problems
result = await model.solve({ cumulPropagationLevel: 4 });

// Or use minimum propagation for very large problems
result = await model.solve({ cumulPropagationLevel: 1 });

See​

integralPropagationLevel?​

optional integralPropagationLevel?: number

How much to propagate integral expression

Remarks​

This parameter controls the amount of propagation done for Model.integral expressions. In particular, it controls whether the propagation also affects the minimum and the maximum length of the associated interval variable:

  • 1: The length is updated only once during initial constraint propagation.
  • 2: The length is updated every time the expression is propagated.

The parameter takes an integer value in range 1..2.

The default value is 1.

noOverlapPropagationLevel?​

optional noOverlapPropagationLevel?: number

How much to propagate noOverlap constraints without transition times

Remarks​

This parameter controls the amount of propagation done for noOverlap constraints without transition times. For noOverlap constraints with transition times, see Parameters.noOverlapTransitionPropagationLevel. Higher levels use more sophisticated algorithms that can detect more infeasibilities and prune more values from domains, but at the cost of increased computation time.

Propagation levels:

  • Level 1: Basic timetable propagation only
  • Level 2: Adds detectable precedences algorithm
  • Level 3: Adds edge-finding reasoning
  • Level 4: Maximum propagation with all available algorithms

Automatic selection (level 0):

When set to 0 (the default), the Parameters.preset chooses the level. The Default preset uses strong propagation. The Large preset uses a lower level to reduce the propagation overhead on big models. The exact levels may change between versions.

Performance considerations:

More propagation doesn't necessarily mean better overall performance. The trade-off depends on your problem:

  • Dense scheduling problems with many overlapping intervals often benefit from higher propagation levels because the extra pruning reduces the search space significantly.

  • Sparse problems or very large problems may perform better with lower propagation levels because the overhead of sophisticated algorithms outweighs the benefit.

  • FDS search (see Parameters.searchType) typically benefits from higher propagation levels because it relies on strong propagation to guide the search.

If you're unsure, start with the automatic selection (level 0) and let the preset choose. You can then experiment with explicit levels if needed.

import * as CP from "optalcp";

let model = new CP.Model();
// ... build your model with noOverlap constraints ...

// Let the preset decide (default)
let result = await model.solve();

// Or use maximum propagation for dense problems
result = await model.solve({ noOverlapPropagationLevel: 4 });

// Or use minimum propagation for very large problems
result = await model.solve({ noOverlapPropagationLevel: 1 });

See​

noOverlapTransitionPropagationLevel?​

optional noOverlapTransitionPropagationLevel?: number

How much to propagate noOverlap constraints with transition times

Remarks​

This parameter controls the amount of propagation done for noOverlap constraints with transition times. For noOverlap constraints without transition times, see Parameters.noOverlapPropagationLevel. Higher levels use more sophisticated algorithms that can detect more infeasibilities and prune more values from domains, but at the cost of increased computation time.

Propagation levels:

  • Level 1: Reasoning on pairs of intervals and their transition times only
  • Level 2: Adds detectable precedences algorithm
  • Level 3: Adds edge-finding reasoning
  • Level 4: Maximum propagation with all available algorithms

From level 2 on, the algorithms work with each interval extended to the left by the smallest transition time it can have from a preceding interval.

When the sequence is used in IntervalVar.position, the propagation of the positions runs on every level.

Automatic selection (level 0):

When set to 0 (the default), the Parameters.preset chooses the level. The Default preset uses strong propagation. The Large preset uses a lower level to reduce the propagation overhead on big models. The exact levels may change between versions.

Performance considerations:

The same trade-offs apply as for Parameters.noOverlapPropagationLevel. Reasoning on pairs cannot detect that three or more intervals do not fit into a time window. When the transition times are small compared to the interval lengths, higher levels often pay off.

import * as CP from "optalcp";

let model = new CP.Model();
// ... build your model with noOverlap constraints with transition times ...

// Let the preset decide (default)
let result = await model.solve();

// Or use maximum propagation
result = await model.solve({ noOverlapTransitionPropagationLevel: 4 });

See​

positionPropagationLevel?​

optional positionPropagationLevel?: number

How much to propagate position expressions on noOverlap constraints

Remarks​

This parameter controls the amount of propagation done for position expressions on noOverlap constraints. The bigger the value, the more algorithms are used for propagation. It means that more time is spent by the propagation, and possibly more values are removed from domains. However, more propagation doesn't necessarily mean better performance. FDS search (see Parameters.searchType) usually benefits from higher propagation levels.

The parameter takes an integer value in range 1..3.

The default value is 2.

reservoirPropagationLevel?​

optional reservoirPropagationLevel?: number

How much to propagate constraints on cumul functions

Remarks​

This parameter controls the amount of propagation done for CumulExpr.le and CumulExpr.ge when used together with steps (Model.stepAtStart, Model.stepAtEnd, Model.stepAt).

The bigger the value, the more algorithms are used for propagation. It means that more time is spent by the propagation, and possibly more values are removed from domains. More propagation doesn't necessarily mean better performance. FDS search (see Parameters.searchType) usually benefits from higher propagation levels.

The parameter takes an integer value in range 1..2.

The default value is 1.

usePrecedenceEnergy?​

optional usePrecedenceEnergy?: number

Whether to use precedence energy propagation algorithm

Remarks​

Precedence energy algorithm improves propagation of precedence constraints when an interval has multiple predecessors (or successors) which use the same resource (noOverlap or cumulative constraint). In this case, the predecessors (or successors) may be in disjunction. Precedence energy algorithm can leverage this information and propagate the precedence constraint more aggressively.

The parameter takes an integer value: 0 to disable, 1 to enable.

The default value is 0.

Properties​

printLog?​

optional printLog?: NodeJS.WritableStream | boolean

Where to write solver log output.

Remarks​

Controls where solver log messages, warnings, and errors are written during solving.

Node.js:

  • undefined (default): Write to console (process.stdout)
  • false: Suppress all output
  • true: Write to console (explicit)
  • WritableStream: Write to the provided stream

Browser:

  • undefined (default): Silent (no output)
  • false: Silent
  • true: Write to browser console

Note that setting printLog to false only suppresses writing to the output stream. The solver still emits log, warning, and error events that can be intercepted using callback properties (Solver.onLog, Solver.onWarning, Solver.onError). To reduce the amount of logging at the source, use Parameters.logLevel.

ANSI colors: When writing to a stream, the solver automatically detects whether the stream supports colors by checking its isTTY property. In browser environment, colors are always disabled. To override automatic detection, use the Parameters.color parameter.

If the output stream becomes non-writable (e.g., a broken pipe), then the solver stops as soon as possible.

// Default - Node.js logs to console, browser is silent
await model.solve();

// Silent - no output
await model.solve({ printLog: false });

// Console output (useful in browser)
await model.solve({ printLog: true });

// Custom stream (Node.js only)
import * as fs from 'fs';
await model.solve({ printLog: fs.createWriteStream('solver.log') });

See​

Simple Lower Bound​

simpleLBWorker?​

optional simpleLBWorker?: number

Which worker computes simple lower bound

Remarks​

Simple lower bound is a bound such that infeasibility of a better objective can be proved by propagation only (without the search). The given worker computes simple lower bound before it starts the normal search. If a worker with the given number doesn't exist, then the lower bound is not computed.

The parameter takes an integer value in range -1..2147483647.

The default value is 0.

Terminal output​

color?​

optional color?: "Never" | "Auto" | "Always"

Whether to colorize output to the terminal

Remarks​

This parameter controls when terminal output is colorized. Possible values are:

  • Never: don't colorize the output.
  • Auto: colorize if the output is a supported terminal.
  • Always: always colorize the output.

The default value is Auto.