# Search settings in RoboPol Math (Beta)

## Start with a profile

Open the calculation settings and choose Fast, Normal or Strong. Fast uses a smaller search for an initial result. Normal uses the adapter's standard settings. Strong allows more runs and a broader, deeper search. A stronger profile does not guarantee a better answer within the same short time limit.

Changing the profile clears custom parameter adjustments. Empty advanced fields use the selected profile's defaults. To remove your adjustments without changing profile, choose Reset custom adjustments. Time and work limits remain separate controls.

## Learning within a calculation

Learning uses observations made during the current calculation and its search runs. It does not automatically reuse learning from earlier calculations in history.

With multiple runs, Separate learning per run keeps observations local to each run. Share learning at epoch boundaries exchanges observations between groups of iterations. Sequential shared learning executes the runs in order, even if parallel runs were requested. Adaptive portfolios also require multiple runs. An enabled mechanism can remain inactive when there is too little work or evidence for it to contribute.

## Accelerated CPU proposals

RoboPol Math (Beta) performs calculations and proposal generation on the server CPU. It uses neither the server GPU nor the visitor's GPU.

The installed QAP, function optimization, Costas, mixed-integer, preference and JSSP adapters support accelerated CPU proposal generation. They cheaply rank many proposed changes, then replay shortlisted proposals and check their actual scores. Normal local search also runs on the CPU. Imported Rust SDK v1 adapters have no accelerator service.

Enable Accelerated CPU proposals where the adapter supports it. Larger proposal batches spend more CPU work and do not guarantee a better result. Unsupported controls remain disabled with an explanation.

The versioned settings format accepts only `acceleratorBackend: "cpu_only"`. Imported automatic/GPU-required choices are rejected rather than silently changed. The editor omits that fixed selector and the inactive GPU batch thresholds. No installed adapter implements accelerated local-search batches.

## CPU parallelism and advanced parameters

CPU execution can be serial, parallel across runs, parallel across candidates, or both. The application admits at most four combined workers per calculation. More configured runs do not necessarily mean more simultaneous workers. Sequential shared learning still executes runs in order.

Advanced groups cover search breadth, candidate racing, learning and sharing, proposal generation, stagnation escapes, repair and memory. Read each parameter's label and allowed range. A value in ppm is a proportion in parts per million: 500000 means 50%. Zero means automatic only where the label says so; it does not generally mean unlimited.

The number of elite slots is capped below the search breadth so that at least one slot remains available for exploration. Adapter-specific limits and time, memory and work limits continue to apply.

## Example JSON settings

The following is an options.engine object for the installed QAP adapter. It enables learning and CPU proposal acceleration with the Strong profile. Copy the whole object's contents into options.engine in a matching task; do not add these fields to the mathematical expression language.

~~~json
{
  "profile": "strong",
  "overrides": {
    "learningEnabled": true,
    "sharedLearningMode": "epoch_merged",
    "acceleratorEnabled": true,
    "acceleratorBackend": "cpu_only",
    "acceleratorPhase": "both",
    "acceleratorRawBatchSize": 512,
    "acceleratorProgramLen": 4
  }
}
~~~

The application rejects unknown fields, unsupported adapter mechanisms and invalid worker combinations. The settings schema is available in the handbook under schemas/engine-settings.schema.json. Use the current exported task as the starting point.

## Read what actually happened

The result lists the effective settings and actual learning-update counts. New online calculations use the server CPU. Imported historical results retain their original GPU activity when it was recorded. Configured runs, callback counts and objective evaluations are different quantities.

Supported adapters share a genuinely certified result between runs so that the remaining runs stop redundant search. Existing synchronous operations finish at their next cooperative checkpoint. The unchanged core can still perform run and epoch bookkeeping. Numeric find-mode acceptance remains a tolerance-checked feasible result where appropriate, not a new analytic optimum proof.

Multi-stage calculations keep the settings and budgets for each stage. Changing settings now does not change the record of an earlier calculation. A manually stopped calculation may have no validated partial result because the worker returns its checked result at completion. Learning-profile reuse between saved calculations and detailed candidate tracing are not connected to the current user workflow.