IndusCP: Dual Benchmark for CP and Plasma Simulation

• IndusCP is a dual-use artifact that distinguishes between an industrial constraint programming benchmark and a modular plasma discharge simulation suite.
• In the CP context, it offers 140 NP-hard CSP/COP instances with an average of 101 variables and 240 constraints to stress-test solver performance.
• In plasma modeling, it integrates hydrodynamic and electromagnetic solvers via preCICE, validated on LTE/NLTE torch applications with under 5% deviation.

Searching arXiv for papers using the term “IndusCP” to disambiguate the topic and ground the article in the current literature. Found multiple usages of “IndusCP”; retrieving the most relevant records for precise citation and disambiguation. IndusCP is a name used in recent arXiv literature for two distinct research artifacts. In constraint programming, it denotes an openly released, 140-task benchmark of industrial-level constraint satisfaction and constraint optimization problems introduced alongside ConstraintLLM (Shi et al., 7 Oct 2025). In plasma modeling, it denotes a modular, self-consistent inductively coupled plasma discharge modeling suite built in the CHESS software stack around HEGEL, PLATO, FLUX, and preCICE (Munafo' et al., 2023). The shared label creates an immediate disambiguation problem: one usage concerns neuro-symbolic formal modeling for CP, whereas the other concerns multi-physics simulation of inductively coupled plasmas.

1. Nomenclature and domain disambiguation

A common source of confusion is that the same term appears in unrelated technical contexts. In the CP literature, IndusCP is defined as an industrial-level benchmark for CP modeling, motivated by the observation that existing LLM-based benchmarks emphasize linear or small logical formulations rather than the scale, diversity of global constraints, and NP-hard combinatorial structure of real industrial CP instances (Shi et al., 7 Oct 2025). In the plasma literature, IndusCP denotes a self-consistent ICP modeling suite based on separate hydrodynamic and electromagnetic solvers coupled through preCICE, with HEGEL handling non-equilibrium plasma flow, PLATO providing plasma properties, and FLUX solving the electric field (Munafo' et al., 2023).

The distinction is substantive rather than terminological. One line of work studies formal model generation, symbolic solver interaction, and benchmark construction for CSP/COP instances; the other studies Maxwell-fluid coupling, NLTE plasma transport, and multi-physics software architecture. Context is therefore essential whenever the term appears in citations, software repositories, or derivative discussions.

2. IndusCP as an industrial-level benchmark for constraint programming

In the CP setting, IndusCP was created to fill the gap left by benchmarks such as NL4OPT, LGPs, and LogicDeduction, which do not capture the scale and industrial combinatorial structure emphasized in CP practice (Shi et al., 7 Oct 2025). The benchmark contains 140 NP-hard COP/CSP instances, each with 2–5 test cases at varying scales. Its stated industrial motivation is that CP is widely used in scheduling, routing, resource allocation, and configuration, but correct and efficient CP modeling remains expertise-intensive and time consuming.

The benchmark spans a broad spectrum of domains, constraint types, and problem scales. The reported domain distribution is as follows:

Domain	# Tasks	%
Scheduling & Sequencing	31	23.8
Resource Allocation & Assignment	23	17.7
Combinatorial Puzzles & Games	21	16.2
Configuration & Design	16	12.3
Routing & Logistics	12	9.2
Layout & Packing / Cutting	10	7.7
Data-Driven Optimization / Analytics	6	4.6
Cryptography & Algorithmic Puzzles	4	3.1
Manufacturing & Production Planning	4	3.1
Telecommunications / Network Design	2	1.5
Others	1	0.8

The benchmark description also associates these domains with characteristic difficulty indicators. Scheduling & Sequencing includes job shop, flow shop scheduling, and timetabling with large makespan variables and Cumulative; Resource Allocation & Assignment includes task-worker and shift rostering with AllDifferent and capacity constraints; Routing & Logistics includes vehicle routing and pathfinding with Circuit, element, and sum constraints. This suggests that IndusCP was designed not merely as a natural-language-to-code dataset, but as a stress test for compositional CP modeling under heterogeneous global-constraint regimes.

The reported statistical profile reinforces that interpretation. IndusCP has an average of 101.24 variables per problem and 240.14 constraints per problem, with average domain size varying by problem but often in the tens or hundreds for discrete domains. By comparison, LogicDeduction is reported at 6.00 variables and 5.06 constraints, LGPs at 12.00 and 12.62, and NL4OPT at 2.02 and 4.25. A plausible implication is that benchmark difficulty is driven not only by linguistic ambiguity, but also by downstream solver-relevant structure.

3. Formal task representation and model specification

Each IndusCP instance is formulated as a Constraint Satisfaction/Optimization Problem with decision variables $X = \{x_1, x_2, \ldots, x_n\}$, where $x_i \in D_i = [a_i, b_i] \cap \mathbb{Z}$ or a finite set such as $\{0,1\}$ (Shi et al., 7 Oct 2025). The constraint set is written as $C = \{C_1(X), C_2(X), \ldots, C_m(X)\}$, and the benchmark explicitly includes representative forms such as linear constraints $\sum_{i=1}^n a_i x_i \le B$, AllDifferent(X), Cumulative(start, duration, use, capacity), and Circuit/Element/Global constraints as needed. For optimization instances, the objective function may be a weighted maximization $\max \sum_{i=1}^n w_i x_i$, a makespan minimization $\min \max_i\{\text{end}_i\}$, or a cost minimization $\min \sum_i c_i(x)$.

All models are encoded in the PyCSP3 Python DSL, which compiles to a standard XCSP3/FlatZinc-style formalism. The benchmark description gives a typical schema consisting of four stages: unpacking input data, declaring VarArray variables, posting constraints through satisfy(...), and specifying an objective through minimize(...). Search directives, including branching strategy and time limits, are passed through the PyCSP3/Choco solver API, with the example maxTime=20 000 ms.

The evaluation protocol centers on Solving Accuracy (SA): the percentage of instances for which a generated model, after being fed to Choco via PyCSP3, produces a verified correct solution within a 20 s time limit. This metric evaluates the full neuro-symbolic chain from language understanding to formal model generation to solver verification, rather than text similarity or partial symbolic overlap.

4. Empirical performance on the benchmark

The primary reported empirical result is that ConstraintLLM achieves state-of-the-art SA on IndusCP, and that the Tree-of-Thoughts variant reaches 51.3% SA (Shi et al., 7 Oct 2025). The benchmark comparison table is:

Method	SA (%)
Qwen2.5-Coder-32B Direct	23.3
Qwen2.5 CoT (one-shot)	20.9
Qwen2.5 RAG (4-shot)	24.3
CP-LLM-ICL	22.7
LLMOPT	3.3
Logic-LM	–
ChatGPT-4o + RAG	33.5
DeepSeek-V3 + RAG	51.0
ConstraintLLM-32B (w/o ToT)	40.0
ConstraintLLM-32B (w/ ToT)	51.3

The paper states that, relative to the best zero-shot/RAG CP baseline at 24.3%, ConstraintLLM with Tree-of-Thoughts doubles SA on IndusCP, corresponding to a 2.11× improvement. It also attributes the gains to the Constraint-Aware Retrieval Module, Tree-of-Thoughts exploration, and iterative self-correction guided by solver feedback.

Per-domain SA indicates substantial heterogeneity. Manufacturing & Production Planning reaches 83.3%, Telecommunications / Network Design 75.0%, and Others 100.0%, whereas Cryptography & Algorithmic Puzzles is reported at 0.0% and is explicitly marked as the hardest category. The paper further notes that the model generalizes across domains even where external exemplars are scarce, citing Manufacturing at 2.7% knowledge coverage. This suggests that at least part of the observed performance depends on transferable constraint-pattern induction rather than pure memorization. At the same time, the collapse on extremely heavy cryptography puzzles indicates a failure mode under very high variable and constraint counts, and the authors identify richer domain-specific retrieval or specialized solver integration as future directions.

5. IndusCP as a self-consistent ICP modeling suite

In the plasma-physics setting, IndusCP is summarized as a modular, self-consistent ICP modeling suite based on HEGEL and PLATO for plasma hydrodynamics and FLUX for electromagnetic fields, coupled via preCICE in the CHESS software stack (Munafo' et al., 2023). The governing electromagnetic model adopts a time-harmonic, quasi-static approximation under low frequency and quasi-neutrality, with $E(r,t)=E_{(c)}(r)e^{i\omega t}$. The electric-field phasor satisfies the induction equation

$$\nabla \times \nabla \times E_{(c)} + i\mu_0 \sigma \omega E_{(c)} = -\,i\mu_0\omega j_s.$$

Once $x_i \in D_i = [a_i, b_i] \cap \mathbb{Z}$0 is known, the framework defines time-averaged Joule heating and Lorentz force as

$x_i \in D_i = [a_i, b_i] \cap \mathbb{Z}$1

The plasma fluid model is a non-equilibrium two-temperature formulation written in conservative form as

$x_i \in D_i = [a_i, b_i] \cap \mathbb{Z}$2

with $x_i \in D_i = [a_i, b_i] \cap \mathbb{Z}$3, where the state collects partial densities, momentum, total energy, internal group energies, and electron translational energy. The source vector

$x_i \in D_i = [a_i, b_i] \cap \mathbb{Z}$4

contains mass-production rates due to chemical reactions, Lorentz force, Joule heating, and internal-energy source terms due to kinetics and electron-heavy collisions. The momentum and energy balances are correspondingly written as

$x_i \in D_i = [a_i, b_i] \cap \mathbb{Z}$5

$x_i \in D_i = [a_i, b_i] \cap \mathbb{Z}$6

with $x_i \in D_i = [a_i, b_i] \cap \mathbb{Z}$7.

The constitutive closure is supplied through PLATO. Thermodynamics uses the ideal-gas Dalton law $x_i \in D_i = [a_i, b_i] \cap \mathbb{Z}$8, with $x_i \in D_i = [a_i, b_i] \cap \mathbb{Z}$9 and $\{0,1\}$0, and species number densities are obtained from Saha or multi-temperature partition functions. Viscosity is given by Newton’s law,

$\{0,1\}$1

with heavy-particle transport computed from the transport matrix system $\{0,1\}$2 and $\{0,1\}$3. Thermal conductivity and heat flux are modeled as

$\{0,1\}$4

with $\{0,1\}$5, $\{0,1\}$6, and $\{0,1\}$7 obtained from a third-order Sonine approximation. Diffusion follows the Stefan-Maxwell equation with ambipolar constraints, and electrical conductivity is given through the stated Ohm’s law expression for $\{0,1\}$8. Kinetics uses Maxwellian reaction-rate expressions for dissociation, ionization, exchange, and recombination as moments of the Boltzmann collision operator under Maxwellian distributions at $\{0,1\}$9 or $C = \{C_1(X), C_2(X), \ldots, C_m(X)\}$0.

6. Numerical realization, validation, and projected extensions in the plasma context

The numerical architecture separates hydrodynamics and electromagnetics rather than using a monolithic solver (Munafo' et al., 2023). HEGEL is a multi-block structured, cell-centered finite-volume solver implemented in Fortran 2008 with MPI and PETSc. Its inviscid fluxes use Roe’s Riemann solver or AUSM-family methods with MUSCL or WENO reconstruction; diffusive fluxes are computed by Green-Gauss gradients; and time integration may be explicit, implicit, or IMEX, with backward-Euler plus local time-stepping for steady state. FLUX is a finite-element electromagnetic solver built on MFEM in C++, using a mixed finite-element discretization of the induction equation with curl-conforming Nédélec elements and complex-valued basis functions for phasors. Linear systems are solved with PETSc/hypre preconditioners. preCICE provides the coupling layer: at each coupling step, HEGEL sends $C = \{C_1(X), C_2(X), \ldots, C_m(X)\}$1 on the fluid mesh to FLUX, and FLUX returns $C = \{C_1(X), C_2(X), \ldots, C_m(X)\}$2 and $C = \{C_1(X), C_2(X), \ldots, C_m(X)\}$3 on the coupling interface, with explicit or quasi-Newton iterations until residual drop falls below tolerance.

The paper reports validation and example cases for an LTE argon/air ICP torch and an NLTE two-temperature air model. For the 2D axisymmetric annular-injection torch, the stated conditions are $C = \{C_1(X), C_2(X), \ldots, C_m(X)\}$4 g/s, $C = \{C_1(X), C_2(X), \ldots, C_m(X)\}$5 Pa, $C = \{C_1(X), C_2(X), \ldots, C_m(X)\}$6 MHz, and $C = \{C_1(X), C_2(X), \ldots, C_m(X)\}$7 kW. The results include an axial temperature of approximately $C = \{C_1(X), C_2(X), \ldots, C_m(X)\}$8 K on axis and a recirculation eddy attributed to electromagnetic pumping, with temperature profiles agreeing within a few percent of Ref. [42]. For the NLTE air model based on Park 2T and Dunn-Kang kinetics, the reported distributions of heavy-particle temperature $C = \{C_1(X), C_2(X), \ldots, C_m(X)\}$9, vibrational temperature $\sum_{i=1}^n a_i x_i \le B$0, and electron temperature $\sum_{i=1}^n a_i x_i \le B$1 show larger plasma volume and lower peak temperatures, again with good agreement to Ref. [42]. The observed accuracy is reported as less than 5% deviations in temperature and velocity.

The stated limitations are that radiation losses are not included and the treatment is 2D axisymmetric only. The same source identifies possible extensions for IndusCP in this plasma sense: 3D unsteady simulations, multi-coil configurations, higher-order time coupling, radiation losses, surface catalysis, fully state-to-state kinetics via PLATO, turbulence models such as LES and DNS, dynamic mesh refinement, and GPU acceleration. These are presented as differences or extensions rather than implemented capabilities. In that form, IndusCP occupies a specific place in the ICP simulation landscape: a modular, coupled, non-equilibrium framework whose defining features are rigorous kinetic-theory transport, mixed FEM and FVM discretizations, and preCICE-mediated multi-solver interoperability.