CHANGELOG.md

Changelog

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

Unreleased

Added

• TwoStageStochasticBlock: the cross-check of BSPar-BDS-2S.txt also has the BendersDecompositionSolver with HiGHS in the master and in the subproblems (BDSCfg-2S-HiGHS.txt, BDSMCfg-MILP-HiGHS.txt, BDSSCfg-HiGHS.txt), i.e., the Benders decomposition where there is no licence of GUROBI, next to the one with GUROBI, whose ComputeConfig is now the fragment BDSCfg-2S.txt that both include

• SVMBlock: FWBSCfg.txt also registers FrankWolfeSolver with the primal-dual bundle direction (intFWDirection eDirPrimalDual), on the balls and on the box of the dual alike

• SMS++/AbstractBlock: AbstractBlock_BDS_test also runs the phase one on four scenarios with the subproblems solved by DAQP, which gives no Farkas certificate (BSPar-BDS-Phase1-DAQP.txt), the ComputeConfig of the phase one being the fragment BDSCfg-Phase1.txt

• HQPBlock, the suite of HQPBlock, HQPDistBlock and HQPSolver: HQPBlock_test compares level by level every HQPSolver of BSPar.txt, a map from the classname of the Block to its BlockSolverConfig (on the HQPBlock, DAQP, qpOASES, MOSEK and Clarabel as inner Solver, each with the rows of the lower levels relaxed or in the model and with the center of the regularization at the previous solution or at 0, and DAQP and qpOASES solving each level from scratch), and those of each formulation of HQPDistForms.txt, given with -F, on the HQPDistBlock of the same hierarchies split among 3 owners (with the structure kConsensus, DAQP and qpOASES on the whole tree; with kBenders, DAQP on the whole tree), with an independent null-space implementation; batch-generated on random and degenerate hierarchies, on a step of Model Predictive Control and on a run of 10 small ones, where DAQP and qpOASES starting from the previous solve of each level must take fewer iterations than from scratch (-I), batch-radial on the instances in data/nc4 of the module, each step also reached by Modification of the previous one, with the label HQPBlock;MILPSolver

• MILPSolver/QuadFunction/LPPar_CL_C-dense.txt also attaches HPIPMMILPSolver, with QPCfg-C.txt, so that batchCL_C_dense, batchMPC_C_dense and batchMM_C_dense run it next to the other dense QP :MILPSolver

• MILPSolver/QuadFunction also has the convex QPs of two test sets of qpbenchmark (Apache License 2.0): the 64 of model predictive control in robotics of mpc_qpbenchmark in MPC, and 61 of the dense subset of the Maros-Meszaros test set in MarosMeszaros, written as LP files by qpb2lp.py, with their optimal values in available_instances.txt; batchMPC_C, batchMM_C (with LPPar_CL_C.txt) and batchMPC_C_dense, batchMM_C_dense (with LPPar_CL_C-dense.txt) solve them

• import_modules, built when SMSpp_BUILD_MODULE is ON, imports the C++20 module of each SMS++ module in the build, names their main classes and gets a Block or a Solver of each one from the factory

• InvestmentBlock/batches-sddp/batch compares, at a fixed design, the simulation that the InvestmentFunction runs over an SDDPBlock with the simulation of the same SDDPBlock by sddp_solver, and both with the value by hand, on four toy instances written by InvestmentBlock/gen_sddp_initud.py whose thermal unit is started up at the last instant of the first stage with MinUpTime 3 or 1, is off there, or shuts down there with MinDownTime 3, the first being a known defect of the InvestmentFunction that is printed and does not fail the battery; it runs where investmentblock_solver, sddp_solver, Python and ncgen are, with the configurations InvestmentBlock/*-sddp*.txt

• SingleFlowDCRBlock/batches-multiflow/batch also runs the LagrangianDualSolver whose flows are solved by the SingleFlowDCRBendersSolver with intReuseCuts 1 (BSPar-multi-reuse.txt, DCRBSCfg-reuse.txt) and with intWarmLambda 1 (BSPar-multi-warm.txt, DCRBSCfg-warm.txt), which no test turned on

• SingleFlowDCRBlock/batches-multiflow/batch runs the instances with 1 flow too, and none is left out any more: with the multi-flow instances of the data version 2026-10-18 of SingleFlowDCRBlock, whose mutual capacity is the sum of the individual ones, the 18 instances of topo that were infeasible are not, and Gurobi solves the 6 it did not

• the first-stage rows of AbstractBlock_BDS_test: an instance whose first-stage Variable have Constraint of their own, a ramp between consecutive ones and a minimum on their sum that the starting point violates, solved in the MILP regime and in the convex one with the primal (BSPar-BDS-Primal.txt, BDSMCfg-Primal.txt) and the dual master problem in the BundleSolver against the monolithic model; the ComputeConfig of the BundleSolver of the master is now the fragment BDSMCCfg.txt, which BDSMCfg.txt includes and BDSMCfg-Primal.txt overrides

• batch-instances-bx of SingleFlowDCRBlock: a BranchAndXSolver whose nodes are solved by the SFDCRBRelaxationSolver next to the Solver of BSPar.txt (BSPar-BX.txt, BXCfg.txt, InnerBSCfg-BX.txt), on the SOCP formulation with its BlockConfig, hence with its feasibility tolerance (on the P/C one in CI, as batch-instances); the build adds it only when it has the BranchAndXSolver and the SingleFlowDCRBlock in it has the SFDCRBRelaxationSolver

• the LagrangianDualRelaxationSolver next to the PrimalProximalHeur in the cross-checks of UCBlock (BSPar.txt, BSPar-DP.txt, BSPar-AC.txt, BSPar-AC-24h.txt, BSPar-PYPSA.txt, BSPar-par.txt, BSPar-par-aggr.txt) and of TwoStageStochasticBlock (BSPar-2S-LD-IP.txt), with the same ComputeConfig (that of BSPar-PYPSA.txt now the fragment PPHCfg-PYPSA.txt); its upper bound is the other side of the relaxation, so the batteries declare it a relaxation and hold its lower bound to correctness alone (-R ...,r -E ...,inf)

• SVM_FW_test in the suite of SVMBlock and its battery batch-fw: FrankWolfeSolver on two problems built out of the data sets of the suite, the least-squares fit in Euclidean balls, a feasible region that is not a polytope whose oracle is the closed-form BallSolver of the tester, and the Wolfe dual of the SVM on a box, whose oracle is BoxSolver, the variants of the direction of FWBSCfg.txt cross-checked against a :MILPSolver by their bounds

• sweep of batch_common.sh, which runs a command for every combination of the values of some parameters, the batteries of BinaryKnapsackBlock_test that sweep the parameters of a generated instance (batch, batch-mixed, batch-negative) writing only the values, and their run once in batches/bkb_battery.sh; the runs are those they made before

• UCBlock/batches/batch-acad also solves the two bus UCBlock of constant/ in the data of UCBlock (version 2026-10-13), whose own Objective has the constant term of the network (+1000 and -1000), against their optimum by hand, skipping them when they are not in the data: the value a Solver reports of its solution and its bounds must both count it

• SolveVariants() of common_utils: given copies of a Block, each configured by one variant of its BlockConfig, it cross-checks the Solver of each copy as SolveAll() does and then the Solver of all the copies against each other, since whatever the formulation they bound the same optimum; -F <list> is a standard option of the testers, the list a SimpleConfiguration<std::vector<Configuration*>> whose elements are (meta-)BlockConfig or pairs (meta-)BlockConfig + BlockSolverConfig (SimpleConfiguration<std::pair<Configuration*, Configuration*>>), read by get_BlockConfig_variants(), and solver_config_of() gives the BlockSolverConfig of each copy

• UCBlock_test takes -F, and UCBlock/batches/batch-pypsa runs each PyPSA instance once with the formulations of the DCNetworkBlock listed in InnerBVar-DCN.txt (PTDF, CYCLE, KIRCHHOFF) instead of once per formulation, comparing them with each other as well as with PyPSA

• TUDPS_test compares formulations with each other: given with -F a list of (meta-)BlockConfig, a SimpleConfiguration<std::vector<Configuration*>> such as UCBlock/TUBVar-PC.txt, it reads the unit once per element, gives each copy its own BlockConfig and the same BlockSolverConfig, makes each random change to all the copies, and besides the two Solver of each copy checks that the copies have the same optimum, which no battery did while each formulation was a run of its own; read_BlockConfig_variants() of common_utils reads the list for any tester

• UCBlock/batches/batch-ac also runs 6 of the 53 AC instances over 24 hours (ES_acopf_srd_id_*_24h_1: c01, c14, da, g2, d2_c03, d2_c12, both days and the extremes of the total demand), on the SOCP relaxation of ACNetworkBlock [InnerBCfg-SOCP.txt, ACBCfg-SOCP.txt], with a limit on the iterations of the LagrangianDualSolver (with dblMaxTime it ends with kError past the limit) and on the time of the PrimalProximalHeur [BSPar-AC-24h.txt, LDCfg-AC-24h.txt, PPHCfg-AC-24h.txt]: their verdict says that the bounds are consistent, not that the values agree; BSPar-AC.txt is made of the fragments MILPCfg-AC.txt (now with NonConvex 0, so that GUROBI reports the optimum of the convex relaxation as its lower bound and not OBJBOUND), LDCfg-AC.txt and PPHCfg-AC.txt, whose warm start [WSBSCfg-AC.txt] solves the relaxation with the settings of MILPCfg-AC.txt, on which it no longer stops on numerical trouble (GUROBI status 12)

• UCBlock/batches/batch-conversion runs the instances with a ConversionUnitBlock: the multi-energy ones of UCBlock (a combined heat and power plant as a ConversionUnitBlock and as a ThermalUnitBlock with hyperarcs, a meshed network with a heat node) against their known optimum, and those that pypsa2smspp makes of the committable links of its test networks (nc4/conversion, data version 2026-10-15: time-varying efficiency, delays, modules, design, also with ramps and on before the horizon) against the optimum of PyPSA, each with the three formulations of the network (InnerBVar-DCN.txt), skipping them when they are not in the data; the ConversionUnitBlock inner to the LagrangianDualSolver is solved with its integer commitment [see CUBSCfg-MIP.txt and InnerBSCfg-DP.txt], and on the units of several modules, whose commitment is integer and not binary, the PrimalProximalHeur only bounds the optimum and is declared a relaxation

• UCBlock/batches/batch-conversion also runs the multi-energy cases with the electricity and the heat as two carriers, the plant being a ThermalUnitBlock with two outputs (me_*_carrier) or the ConversionUnitBlock whose generators have each its output on its carrier (me_*_unitcarrier), the PyPSA networks with the electricity, the hydrogen, the gas and the heat as carriers (carriers_*) and the cases of the committable links of pypsa2smspp with the gas, the electric and the heat buses as three carriers (conversion/*_carriers.nc4), against the optimum by hand and of PyPSA, and per instance the tolerances of its Solver (EPS_OF)

• the carrier form of the PyPSA instances, where the buses of each carrier of the network are the nodes of a carrier of the UCBlock and the links between two carriers are units with outputs (*_carriers.nc, written by the generators of pypsa-eur-instances with --carriers), held to the same reference as the network form: the networks with the hydrogen in UCBlock/batches/batch-pypsa and InvestmentBlock/batches/batch-pypsa, the trees of the PyPSA-Eur network with ten carriers, whose CO2 pipeline is a line with a design in the network of its carrier, in MultiStageStochasticBlock/batches/batch-pypsa and, with the investment outside, in InvestmentBlock/batches/batch-stochastic (from initial_investment_stochastic_carriers.txt, the point of the other form in the order of the assets of this one), and the flat two-stage equivalent of one tree, in both forms, in TwoStageStochasticBlock/batches/batch-pypsa

Changed

• MILPSolver/QuadFunction: HPIPMMILPSolver has in LPPar_CL_C-dense.txt the ComputeConfig HPIPMCfg-C.txt, that of QPCfg-C.txt with a limit of 1000 iterations instead of the 100 of the default mode of HPIPM, with which it stopped with no solution, an interval that the tester accepts, on QCAPRI, QSCAGR7 and QSCAGR25 of batchMM_C_dense; with the 1000 it solves the last two, and returns an error on QCAPRI, which batchMM_C_dense leaves out as it does the other models some of its Solver do not solve

• SVMBlock/BSPar.txt adds to GRBMILPSolver and SMOSolver one :MILPSolver for each other kind of algorithm for a convex quadratic program: the active-set QPOASESMILPSolver, the interior-point MOSEKMILPSolver and the first-order OSQPMILPSolver, so that the batteries of the SVM dual and primal also check how they take the changes of the training problem

• the makefiles that include LagrangianDualSolver no longer include BranchAndXSolver, which it no longer needs, save those of the tests whose configurations use it (UCBlock)

• MILPSolver/QuadFunction/LPPar_CL_C.txt gives MOSEKMILPSolver two threads, with MOSEKCfg-C.txt, since its interior point fails on QGROW7 of batchMM_C with 4 threads or more and on QPCSTAIR with one, and solves both with two, so that the outcome of the battery does not depend on the cores of the machine

• SolveAll() reports a Solver whose compute() throws as an error in the line of the instance, with Error! (throw) and the message of the exception on the standard error, and goes on with the other Solver, rather than ending the tester: the exception of one Solver (e.g., the active set of HiGHSMILPSolver that does not solve a QP) left the others without a value

• the tester of UCBlock is built without the LagrangianDualSolverML library, whose loading of Torch cost more than many of the instances, and UCBlock_ML_test is the same tester with it; batch-acad-s, whose BSPar-DP-BX.txt asks for a Solver of that library, names it as its default executable and is run with it when the build has it

• every test and every battery runs with OPENBLAS_NUM_THREADS=1, unless the caller sets it, OpenBLAS starting one idle thread per core as soon as it is loaded

• InvestmentBlock/batches-sddp/batch holds the InvestmentFunction to the value by hand on minup3 too, now that it simulates on a copy of the SDDPBlock; GreedyCfg-sddp.txt gives the SDDPGreedySolver the BlockSolverConfig of the stages (UCBSCfg-sddp.txt)

• the batteries of MILPSolver/QuadFunction solve each model with every Solver of their BlockSolverConfig and check them against each other and against the known optimal value (SolveAll()), where the tester used the first one alone; the models of the class CL (a convex objective and linear constraints) have configurations of their own, LPPar_CL_C.txt with MOSEKMILPSolver, ClarabelMILPSolver, PIQPMILPSolver (sparse) and OSQPMILPSolver next to SCIPMILPSolver, and LPPar_CL_I.txt with MOSEKMILPSolver, the ComputeConfig of each Solver being a fragment; batchCL_C_dense runs the dense DAQPMILPSolver, QPOASESMILPSolver, ProxQPMILPSolver, QPMADMILPSolver and QuadProgMILPSolver (the last two with their Hessian regularized) of LPPar_CL_C-dense.txt, which the tester takes from -S, on the models of the class with up to about 2000 variables

• intDoEasy in the configurations follows the new bits of BundleSolver (e.g., 13 is now 7, 45 is now 23), as do the comments that name them

• the batteries batch, batch-mcf and batch-cuts of CapacitatedFacilityLocationBlock run the Yang and TBED instances in CI too, the first instance of each Yang size and the first TBED one with seed 0 only, and all of them locally as before (cfl_yang takes the numbers of the instances); they were skipped in CI as running for hours, which was MCFSimplex pivoting for ever on an infeasible round of the MCF R3Block (batch-cuts, which has none, had only copied the skip), and with it fixed the 40 rounds take seconds

• the LMO of the MCFBlock suite (MCFBlock/MCFBSCfg.txt) runs MCFSimplex with the tolerances of MCFClass, no longer at 1e-9: they had been set because goto10_8_1 pivoted for ever, which does not happen any more

• what the testers compare with -F is called a formulation everywhere, and no longer a variant: the lists are *Form*.txt (TUBForm*.txt, NUBForm*.txt, InnerBForm-DCN*.txt, InnerBForm-LD.txt, CFLBForm*.txt, SATBForm.txt, DCRForm.txt, NDForm.txt, MetaForm.txt, formerly *Var*.txt), the long option is --formulations, the functions of common_utils are read_formulations(), get_formulations(), SolveFormulations() and attach_formulation_Solvers(), and the output says formulation Fk: and formulations against each other:

• the five options of the rounds of random changes (-e seed, -k what to change, -n rounds, -m changes, -q probability) are written once in common_utils [see RoundOptions and add_round_options()] and used by the nine testers that change their Block at random: those of SMS++/BoxSolver, AbstractBlock (box), MCFBlock, CapacitatedFacilityLocationBlock and UCBlock (TUDPS), which had a copy each, and those of SMS++/PolyhedralFunction, PolyhedralFunctionBlock, LagBFunction and AbstractBlock (readwrite), which took positional arguments; the NDOBlock configuration of LagBFunction_test is the standard -S, and MILPSolver/QuadFunction takes -t and -r in place of its positional arguments

• IB_test takes -F, the list of the BlockConfig to compare, like the other testers: InvestmentBlock/batches/batch-pypsa and batch-stochastic solve each instance with a network with the three formulations of it (InnerBVar-DCN.txt, InnerBVar-DCN-CI.txt in CI), and the modular ones with the inner Block solved as a linear program and by the recursive Lagrangian dual in one run (InnerBVar-LD.txt), the copies being compared with each other

• BSPar-2S.txt of TwoStageStochasticBlock, the default of batch-pypsa and batch-ec, has the master problem of the bundle of its LagrangianDualSolver solved by GUROBI's barrier (MPBCfg-barrier.txt, from the ComputeConfig of the master now in MILPCfg-MPB.txt, which MPBCfg.txt includes, as in UCBlock): with the dual simplex the master of the maxpower instance of batch-pypsa failed numerically at every call after a few dozen iterations, and the Lagrangian Dual ended in error, while with the barrier no master fails

• UCBlock/batches/batch-p4r solves the pHydro instances with BSPar-DPb.txt, whose LagrangianDualSolver, PrimalProximalHeur and LagrangianDualRelaxationSolver have the master problem of the bundle solved by GUROBI's barrier (MPBCfg-barrier.txt, from the ComputeConfig of the master now in MILPCfg-MPB.txt, which MPBCfg.txt includes): with the dual simplex the Lagrangian Dual stopped at the 300 seconds of the battery on four of the five, and on pHydro_18 its master failed numerically, while with the barrier it converges on all of them in less than half of that time; a BlockSolverConfig given on the command line is still used for every instance

• UCBlock/batches/batch-ec solves each instance with the three formulations of the network (InnerBVar-DCN.txt, InnerBVar-DCN-CI.txt in CI) and compares them with each other

• UCBlock/batches-tub/batch-nuclear compares the formulations of the NuclearUnitBlock: the T formulation with Perspective Cuts and its tight forms of the operating rules (NUBVar.txt with NUBCfg-T-PC-{R,M,RM,RC}.txt, NUBVar-CI.txt in CI), which describe the same set of schedules

• the batteries of MultiStageStochasticBlock and batch-ec of TwoStageStochasticBlock solve each instance with the three formulations of the network of its inner Block (InnerBVar-DCN.txt, PTDF and KIRCHHOFF only in CI), comparing them with each other; the copies are read as with one copy, by the lower bound of their Solver

• batch-pypsa of TwoStageStochasticBlock solves each instance with the three formulations of the network of its inner Block (InnerBForm-DCN.txt, InnerBForm-DCN-CI.txt in CI), comparing them with each other and with the reference, as batch-ec does; the runs on the Benders form keep the one formulation of InnerBCfg.txt

• SatellitesBlock_test and MultiKnapsackAssignBlock_test are a call of load_solve_test() of common_utils, which loads the Block out of the file, once per variant of -F, and cross-checks its Solver with SolveVariants(); their runs are those they made before

• the testers no longer define their own RED/GREEN macros, which are those of common_utils.h, and UCBlock_test and MMCFBlock_test no longer carry the commented-out template of a loop of changes they never made, nor the random generator and the macros it would have used

• MCFBlock/batches/batch and batch-dense share batches/mcf_battery.sh, the sweep of the changes over the instances being the values of its parameters [see sweep], each battery naming only its sizes; the runs are those they made before

• the batteries of MMCFBlock_test share batches/mmcf_battery.sh, the Canad instances with a list of BlockSolverConfig and the Mnetgen ones, the runs being those they made before (the commented-out instances of 256 nodes are gone)

• the six batteries of MILPSolver/QuadFunction share batches/qf_battery.sh, each only naming its family of instances and its type, the runs being those they made before

• the batteries of CapacitatedFacilityLocationBlock share batches/cfl_battery.sh, the arguments, the runs of an instance for every seed and the ORLib, Yang and TBED instances: each of them only says its variants, its changes, its seeds and which instances it runs, the runs being those it made before

• the header and END boxes of the configuration files that lacked them or had them with another name or the name glued to the dashes, the author lines and the lines over 77 columns, the comments being rewrapped and nothing else of the files changing

• TSSB_test and MSSB_test are one main, stochastic_test.{cpp,h}, the two test.cpp only saying which class they read and what they add (the Benders form of -b, the round trip of the Solution); both take -F, reading the instance once per variant of the BlockConfig and comparing the copies with SolveVariants(), and -R

• MMCFND_test takes the two formulations of MMCFNetworkDesignBlock with -F NDVar.txt (pairs BlockConfig + BlockSolverConfig) instead of -m/-M/-b/-B, its options being parsed by common_utils

• SingleFlowDCRBlock/batches/batch runs each instance in both formulations, the SOCP and the P/C one, with -F DCRVar.txt, whose variants carry their BlockSolverConfig and their -R, and compares them with each other; batch-pc is gone, and batch-instances runs the two formulations in one run where it runs both

• a variant of -F may be the vector of its BlockConfig, its BlockSolverConfig and a SimpleConfiguration<std::vector<int>> saying which of its Solver solve a relaxation, i.e., its own -R; attach_variant_Solvers() of common_utils applies the BlockSolverConfig of a copy and gives SolveVariants() the -R of that copy, each copy taking out of it the Solver this build does not have (before, a run of several copies took them out of -R once per copy)

• SATBlock_test and SingleFlowDCRBlock_test take -F [see SolveVariants()], given which they read the instance once per BlockConfig of the list; SATBlock/batches/batch-structure gives each instance both structures in one run (SATBVar.txt: the relaxation of BPar-R.txt and the decomposition of BPar-D.txt), each round of Modification making the same change to both copies, and compares them with each other; get_BlockConfig_variants() takes optional, for the testers that may be given no BlockConfig at all

• the tester of CapacitatedFacilityLocationBlock takes its configuration from the list of -F, one per battery (CFLBVar*.txt): the pair BlockConfig + BlockSolverConfig of the original Block, then one or more R3Block, each the vector of the Configuration it is made with, its BlockConfig and its BlockSolverConfig, with its own UpdateSolver; the lower bounds of all their Solver are compared, not only those of the first one, so that the flow relaxation is solved by every :MCFSolver its BlockSolverConfig lists; its positional arguments are options (-t, -s, -e, -k, -n, -m, -q, -T); the sub-folders cuts, MCF, LD, LDVScuts and Ben with their copies of BPar1.txt, BPar2.txt, BSPar1.txt, BSPar2.txt and R3BCfg.txt are gone, the configurations being flat files named after what they configure (CFLBCfg-*.txt, CFLBSCfg-*.txt, MCFBCfg.txt, MCFBSCfg*.txt, R3BCfg-copy.txt, R3BCfg-MCF.txt), the identical ones merged

• compare_formulations is a thin wrapper of SolveVariants(): it takes -F and the variants of MetaVar.txt, each a pair BlockConfig + BlockSolverConfig, instead of -X/-Y; its CMake target links UCBlock and MILPSolver when they are in the build, without which it could not read the instances of its batch

• UCBlock_test --scale no longer builds the BlockConfig of the formulations of the unit in code: it reads them from the lists UCBlock/TUBVar.txt (the seven formulations, new) and UCBlock/TUBVar-PC.txt (the seven with the Perspective Cuts) with read_BlockConfig_variants(), and it is run in the directory of the suite, which holds them

• b_config_Block() of common_utils applies a clone of a plain BlockConfig, as it already did for a meta one: apply() moves the Configuration it holds into the Block, so the same BlockConfig applied twice gave nothing the second time

• the batteries of UCBlock/batches-tub that looped over the formulations of the unit in bash (batch, batch-acad-all, batch-acad-red, batch-mustrun, batch-reserve, batch-reserve-red, batch-shutdown) run each instance once with -F and the list of its formulations (TUBVar-PC.txt, TUBVar-PC-3bin-T.txt on the long horizons, TUBVar-mustrun.txt, TUBVar-shutdown.txt); each run reports the Solver of every formulation as before and, when they agree, the line formulations ... agree in <n> solves before its verdict

• the comments of UCBlock/batches/batch-ac and of the AC configurations say what is solved: a convex relaxation of the AC model, whose McCormick inequalities are not separated in a continuous solve, by GUROBI (not SCIP); the 24h instances stay skipped, with the measured reason (the :MILPSolver alone solves one in a few minutes, the Lagrangian chain does not converge in 90 minutes and exceeds the sessions of the license)

• compare of ml_bench prints a line when each side of an instance starts and one when it ends, with its time and iterations or why it failed, so that a side that does not end is seen while it runs

• the tests that set up the instances of a module are named after the target they build (extract_<prefix>_<fmt>, run_<tool>), set up the fixture <prefix>_<fmt>_extracted or <tool>_generated and share the lock <prefix>_data; fetch_bk_data, fetch_sat_data and fetch_canad_data are now extract_bk_txt, extract_sat_cnf with extract_sat_wcnf, and extract_mmcf_Canad, whose archive MMCFBlock downloads as the modules do

Removed

• UCBlock/batches-tub/batch-acad-all, which made the runs of batches-tub/batch but those of Frank-Wolfe, so that ctest made them twice

Fixed

• the Frank-Wolfe decomposition with the network simplex of LEMON in batch and batch-dense of MCFBlock runs the reduced lineup, as the one with the network simplex of MCFClass does, through the new FatherBSPar-fast-lemon.txt: FatherBSPar-lemon.txt gives the whole lineup, whose Away-step and Blended Pairwise variants with an unbounded active set did not end in hours on those instances

• the makefiles of the tests and of the tools build also with g++: they take the option that stops at the first error and the one of the debugging information, which clang++ and g++ spell differently (-ferror-limit=1 and -glldb against -fmax-errors=1 and -ggdb), from SMSppSWERR and SMSppSWDBG of lib/makefile-OS of SMS++

• the makefiles that include the one of LagrangianDualSolver include also the one of BranchAndXSolver, whose branching rules LagrangianDualSolver uses, and so build again

• BinaryKnapsackBlock/makefile links CPLEX only through MILPSolver, which adds it when it is there, and so builds without it

• MMCFBlock/MMCFClass compiles MMCFCplex only if CPLEX is there (CPLEX_PRESENT of extlib), and MMCFBlock/makefile then leaves out MMCF_test, whose reference solver is MMCFCplex, as CMake does

• MILPSolver/QuadFunction/MOSEKCfg-I.txt asks MOSEK for the outer approximation of the conic relaxations: with the nonlinear ones and the few threads of a CI runner, MOSEK 11.0 declared optimal -33.7755 on QPLib_10056, whose optimum is -33.8568, and batchCL_I failed

• the SingleFlowDCRBlock tester checks the Solution of a Solver against the problem only if the formulation of its copy does not declare it a relaxation: with -F it read the -R of the command line, which is empty, so the point of the P/C relaxation of DCRForm.txt was found to violate the delay, and batches/batch-instances stopped at its first instance; each check now also names the formulation of the Solver

• the here-and-now AbstractPath of the network design Variable of the two s_5 instances of TwoStageStochasticBlock/data-scenred give the position of each design line, not its line index: past the 11 lines out of design they pointed to the wrong Variable, and the last 11 past the end of the group, on which TSSB_reduction_test crashed

• batches-scenred/batch of TwoStageStochasticBlock fails when the tester fails on some instance, rather than always passing

• the Benders form benders_form.cpp builds for TSSB_test and the check of TSSB_reduction_test for here-and-now Variable shared by the scenarios take the elements of a here-and-now AbstractPath selecting an explicit, non-contiguous subset of a group, rather than the ones following the first element

• the BundleSolver of BSPar-Inv.txt of TwoStageStochasticBlock asks 1e-6 of relative accuracy, the tolerance within which TSSB_BDS_test compares the ad hoc Benders form with the extensive optimum, not 1e-4, where it could stop on the bound of the box of the variables above that tolerance

• the BundleSolver of BSPar.txt of InvestmentBlock asks 1e-5 of relative accuracy, not 1e-4: IB_test reads its value as the optimum and compares it with the reference within 1e-5, and the BundleSolver, which now stops on the bound of the box of the variables, stops where 1e-4 asks, 1.7e-5 above the reference on smspp_2n_2c_1g_1lext.nc of batch-pypsa

• the Solver that an option names by its position, i.e., the heuristic that -w of the stochastic testers reads by its upper bound, follows the Solver that the build does not have as -E and -R do [see name_Solver()]: it moves down past one before it, rather than landing on another Solver, and if it is itself not there the warning says so and the run goes on as without the option; and a BlockSolverConfig that adds its Solver to those already registered to the Block (as the reference one of fw_test) takes out of -E and -R the entries of its Solver after them, not of the first ones. BSPar-2S-IP-missing.txt names the missing Solver before the PrimalProximalHeur, and batch-pypsa of TwoStageStochasticBlock runs it also with -w

• with -F and a BlockSolverConfig naming a Solver that the build does not have, the entry of that Solver in -E was taken out once per copy of the Block rather than once, so that the tolerances of the Solver after it landed on others (a single entry left applied to all of them): each copy now filters -E anew out of what was given [see attach_formulation_Solvers()]; the Solver of the sub-Block of a meta BlockSolverConfig that are not in the build no longer take out entries of -E and -R, which are positional on the Solver of the root alone, and the warning names the BlockSolverConfig rather than the formulations. TwoStageStochasticBlock/batches/batch-pypsa checks it on the thermal instance (BSPar-2S-IP-missing.txt, with a Solver that no build has)

• the meta BlockSolverConfig of the LagBFunction of UCBlock give the NuclearUnitBlock its own entry, which fell on * since the match is on the exact classname(): NUBSCfg-DP.txt (NuclearUnitExtDPSolver) in InnerBSCfg-DP.txt, as ThermalUnitBlock has its dynamic programming, and TUBSCfg-CLP.txt / TUBSCfg-QCP.txt in InnerBSCfg.txt / InnerBSCfg-AC.txt, as ThermalUnitBlock

• MMCFBlock_test passes only if every round of the online training of its Solver passes, not only the last one

• SMS++/PolyhedralFunctionBlock/batch exits with 1 on any failure: the number of failures, which it returned, is 0 again from 256

• the batteries say at their end which runs they skipped, i.e., exited with 77 since the build has none of their Solver [see report_skipped of batch_common.sh], as the comment there said they did

• CapacitatedFacilityLocationBlock/CFLBSCfg-ldvscuts.txt gives its GRBMILPSolver the parameters of GUROBI (it gave those of CPLEX, which stopped every run of batch-ldvscuts), the root node being solved with its cut loop (NodeLimit 1); the battery stays off ctest, the gap between the two bounds being larger than with CPLEX

• compare_formulations/BSCfg1.txt and BSCfg2.txt attach a GRBMILPSolver rather than a HiGHSMILPSolver, which cannot separate the user cuts that intCutSepPar 7 asks for, so that the batch failed on every instance

• UCBlock/batches/batch-p4r holds the solution the LagrangianDualSolver reconstructs on L_H_C_35 to the violation its convergence gives (-V 0.5, the largest entry of the residual being 0.157 MW on node injection rows of right-hand side 0, under the dblNZEps test the bundle stops by), where the default 0.1 made the battery fail on a correct reconstruction

0.7.0 - 2026-10-09

Added

• the tester of LagBFunction takes as its last argument, detach, whether the Solver of NDOBlock are unregistered and registered again before each compute(), which was the compile-time macro DETACH_NDO; batch and batch-easy have rows with it, with all the changes between two calls

• the suite MultiKnapsackAssignBlock, which cross-checks on the instances of the module a :MILPSolver on the whole tree and the Lagrangian decomposition into BinaryKnapsackBlock solved by the CoreDPBinaryKnapsackSolver, the latter declared a relaxation

• the tester of LagBFunction can write the transportation components with a size Variable tau, their balances and capacities scaled by it, so that the master problem scales them by its lambda and the easy components can be used with the level and doubly stabilized master problems: the argument size of the tester, the one before detach, is 0 for none, in which case the master scales a copy of the inner Block if bit 5 of intDoEasy asks for it, 1 for a Variable of the inner Block (Block::set_owned_size_variable()), which the master ties to lambda, and 2 for lambda itself, given to the inner Block, a SizedTransportBlock, by Block::set_size_variable(); bits 4 and 5 of intDoEasy are taken from the configuration file, so that the file says whether the master uses the size Variable and the copies batches/batch-easy, with the path of batch_common.sh corrected, is a ctest test, and its sized rows (in the default profile) run the three ways of scaling with the proximal, level and doubly stabilized masters (NDOPar-Mirror.txt, NDOPar-Lvl.txt, NDOPar-DS.txt, all with intDoEasy 33) and with the doubly stabilized one that leaves the easy components unscaled (NDOPar-DS-NoSize.txt, intDoEasy 17), also with bit 12 (4096) of the tester, by which the inner Block of an easy LagBFunction issues an NBModification, which a copy in the master cannot follow and which puts the inner Block back in its place

• the testers of PolyhedralFunction and LagBFunction check every Solver the BlockSolverConfig of NDOBlock attaches against the LP, one column each in the per-instance line; the ComputeConfig of their BundleSolver is the fragment BSCfg.txt. PolyhedralFunction/NDOPar.txt attaches three BundleSolver, with the proximal stabilization and with the trust region in the dual and in the primal master problem; LagBFunction/NDOPar.txt attaches two, with the proximal stabilization and with the trust region, both taking the easy components in their master problem

• UCBlock/batch-pypsa runs the edge cases of the network of the UCBlock data from 2026-10-03 with the PTDF, CYCLE and KIRCHHOFF formulations against the optimum of PyPSA: parallel DC lines in the same and in opposite directions, a triangle with a parallel side, DC components joined by a link and nodes reached only by links with losses; until then the instances of the battery had no susceptance, so that the three formulations wrote the same transport model

• MMCFBlock/BSPar-ML-K-train.txt, the configuration of the training of MMCFBlock_ML_bench: BSPar-ML-K.txt with the online training of the network on, both taking their ComputeConfig from LDCfg-ML-K.txt; train stops with an error when the configuration has intMLTrainOnline at 0, since the run would otherwise write weights that learned nothing

• bit 11 (2048) of the LagBFunction tester adds at runtime a dual pair to a single LagBFunction on an x that it does not have, as one does when dualizing a constraint born during the search, mirroring it on the LP side; the x is a new coordinate of the master when no other component has it, and one the master already has otherwise. batches/batch runs it with the dense and the sparse setup (3583 and 4095), with and without the linear objective and the PolyhedralFunction (nf = -2, -11, 0), and with hard and easy components

• the testers of PolyhedralFunction and PolyhedralFunctionBlock remove dynamic Variable as well as adding them (DYNAMIC_VAR_REMOVALS is 1): in the dual representation the coupling rows of the removed coordinates go first, then the columns of the LP side, which the UpdateSolver mirrors on the NDO side, and the Variables of both Blocks; the removal of the PolyhedralFunction tester uses the positions that follow the static Variable, and its ranged removal from the rows of the LP issues the Modification it skipped

• the IntegralityBarrierSolver of FrankWolfeSolver in the cross-check of SATBlock (BSPar.txt), a heuristic on the MILP formulation whose oracle is the BlockSolverConfig IBLPBSCfg.txt, a :MILPSolver on the linear relaxation (LPCfg.txt) applied to the copy of the formulation (strLMOBSCfg of IBCfg.txt), its Frank-Wolfe method looking at the rounding of the iterate every iteration (intEverykIt 1 of FWIBCfg.txt)

• MMCFBlock/MMCFND_test with batches/batch-nd: the network design problem of MMCFNetworkDesignBlock, solved monolithic by the MILP Solver and in Benders form, the two optimal values compared on the p33 instances with 3 and 5 commodities

• the tester of SATBlock applies the BlockConfig of -B, e.g., giving the SATBlock a structure out of the groups of its variables, and does not check the solution of the Solver declared with -R; batch-structure gives the instances of smspp_satgen both structures (BPar-R.txt, BPar-D.txt) and cross-checks the Solver of BSPar-LD.txt, i.e., those of BSPar.txt and the LagrangianDualSolver of the rows of the father, whose bound has to be below their optimum, also after 3 rounds of Modification that keep the structure

• the suite of SatellitesBlock: its tester loads an instance of the Satellite Constellation Design Problem into the Block given with -b (ConstellationBlock, DiscreteConstellationBlock or MultiTargetBlock) and cross-checks, with SolveAll(), a :MILPSolver on the whole tree with the LagrangianDualSolver, whose sub-Block get their Solver by classname from a meta-BlockSolverConfig (DiscreteSatelliteSolver or a :MILPSolver); batch runs it on the instances of the module, against their optimum, the Lagrangian dual being declared a relaxation, and stopped after 50 iterations on MultiTargetBlock (BSPar-target.txt)

• the suite of SATBlock: its tester reads a SATBlock out of a CNF, WCNF or netCDF file and cross-checks, with SolveAll(), the Solver of its physical representation (OLL, with CaDiCaL and with MiniSat) with those of its abstract one, i.e., the :MILPSolver on its MILP formulation, checking also on the clauses the solution each of them writes; batch-mse runs it on the instances of the MaxSAT Evaluation 2024 the module distributes, against their optimum, and batch-groups on instances made of groups of clauses written by smspp_satgen

• the tester of SATBlock changes the instance with -n rounds of Modification drawn with the seed of -e (the costs of a fifth of the variables moved by a step, as a Lagrangian term does, the weights of a range of clauses, or clauses added), repeating the cross-check after each with the Solver still registered, so that their reoptimization is tested; batch-groups makes 5 rounds per instance

• the suite of SATBlock cross-checks a BranchAndXSolver too, which enumerates on the SATSolver with CaDiCaL, OLL stopping after 20 calls of the SAT solver in each node (BXCfg.txt, BXBSCfg.txt, OLLCfg-node.txt)

• InvestmentBlock/batches/batch-pypsa runs the modular network with one scenario again with the inner UCBlock solved by the recursive Lagrangian dual over its units (InnerBCfg-LD.txt), against the reference of PyPSA

• the nested forms in the batteries: TwoStageStochasticBlock/batches/batch-pypsa runs the Benders form of the thermal instance with BendersDecompositionSolver whose subproblems are solved by the recursive Lagrangian dual (BSPar-BDS-2S-LD.txt, a relaxation), batch-pypsa-modular the same BDS with a bundle master (BSPar-BDS-2S-CVX-LD.txt, BDSCfg-CVX-LD.txt), and InvestmentBlock/batches/batch-stochastic runs the modular networks again with the inner Block of the InvestmentFunction solved by the recursive Lagrangian dual (InnerBCfg-LD.txt, IBOCfg-LD.txt, IFCfg-LD.txt, BSCfg-LD.txt)

• TSSB_scenred_test in the TwoStageStochasticBlock suite, the generic tester of the scenario reduction of a TwoStageStochasticBlock read from a file, which was the instance mode of the test of ScenarioReductionSolver and linked from there the Blocks and the :MILPSolver that module does not depend on; the batches-scenred batteries of UCBlock and CapacitatedFacilityLocationBlock run it, and are labelled with ScenarioReductionSolver, StochasticBlock and TwoStageStochasticBlock as well

• the tester of UCBlock takes -V, how much the point a relaxation reconstructs may violate the rows it has dualised, the default being the 1e-1 that was written in the test

• the same networks of pypsa2smspp in every form a module reads, each in the batch of its module: one scenario of the modular family with the design in the units in UCBlock/batches/batch-pypsa and under an InvestmentBlock in InvestmentBlock/batches/batch-pypsa, the modular family as an MSSB in MultiStageStochasticBlock/batches/batch-pypsa, next to the TSSB of batch-pypsa-modular, and the thermal family, whose scenarios are unit commitments, in TwoStageStochasticBlock/batches/ batch-pypsa with BSPar-2S-LD-IP.txt, i.e., a :MILPSolver on the integer problem, the PrimalProximalHeur and the recursive Lagrangian dual; on the modular family with a continuous design batch-pypsa-modular also runs BDS whose subproblems are solved by the recursive dual (BSPar-BDS-2S-LD.txt) and the recursive dual itself (BSPar-2S-LDrec-IP.txt)

• TSSB_test -R, which declares the Solver that solve a relaxation and makes the tester cross-check the intervals of the bounds of all the Solver, as the other testers do, instead of requiring two values to be equal: a Lagrangian dual of a unit commitment is below the optimum by the duality gap

• SingleFlowDCRBlock/batches/batch-instances, the two formulations of the DCR problem on the instances of the module, i.e., on 10 flows of each of 307 real and random networks, which the build of SingleFlowDCRBlock downloads and a ctest fixture extracts before the batteries that read them: the P/C one on all of them, the SOCP one on the 2969 that Gurobi solves with each of the numerical focus settings 0, 2 and 3, the other 101 being listed in socp-unstable.txt; batch-instances-cplex solves the SOCP formulation of those 101 with CPLEX, where CPLEX is available

• MultiFlowDCRBlock_test and SingleFlowDCRBlock/batches-multiflow/batch, which compare on the instances with the first 2 to 5 flows of each network a :MILPSolver on the formulation holding all the flows with the LagrangianDualSolver that relaxes the mutual capacities, its flows solved by the SingleFlowDCRBendersSolver or by a :MILPSolver: they take the place of the testers of the multi-flow and single-flow DCR problems that lived on the branches DCRFlow and feature/dcr-benders

• UCBlock_test --pollutant scales a unit with a LagrangianDualSolver attached, whose LagBFunction hold only the dual pairs of the rows their sub-Block is in, and checks that the rows of that unit follow the scale and that the Lagrangian dual is the optimum of the scaled instance, as it is when the unit is scaled before the Solver is attached; the test is run next to the configurations of the batches, whose LDCfg.txt it reads with a tighter threshold on the residual

• TwoStageStochasticBlock/batches/batch-mmcf: a stochastic multicommodity network design problem, i.e., a TwoStageStochasticBlock whose scenarios are MMCFBlock with one knapsack per arc, written by mmcf_tssb_gen out of the Canad instances, is solved by the MILP, by the Lagrangian dual over the scenarios, by the nested and by the recursive one (one run each, since duals that do not copy their components cannot share them) and, on its Benders form, by BendersDecompositionSolver with the scenarios as LPs and with the scenarios solved by the recursive Lagrangian dual (BSPar-MMCF-BDSLD.txt, a run of its own since a BendersDecompositionSolver reformulates its Block), all cross-checked against the MILP; the instances have complete recourse (mmcf_tssb_gen -r), which the Lagrangian subproblems need, and the knapsacks are solved by dynamic programming (BKBSCfg-DP.txt, in InnerBSCfg.txt)

• a configuration that names a Solver this build does not have no longer makes a run fail: the testers take those names out of the BlockSolverConfig before applying it [see Solver::has_Solver()] and warn, in the yellow of the other warnings and one line per name, that the run solves without it, so that the log of a run says what it has actually solved with and a configuration can name every Solver that makes sense on its instances, whatever each machine has; a run left with no Solver at all, and a run whose one Solver was the missing one, has nothing to do rather than something to fail, so it exits with the 77 that ctest and the batteries read as "skipped" (SKIP_RETURN_CODE), and a run left with one Solver out of several warns that there is nothing to cross-check it against. BSPar.txt and BSPar-large.txt of the MCFBlock suite and the two configurations of the flow relaxation of the capacitated facility location therefore name MCFSolver<MCFCplex> as well, the network solver of CPLEX, which joins the comparison wherever CPLEX is there and is left out, with a line saying so, wherever it is not

• the tester of BendersBFunction checks the global pool when a dynamic row of the sub-Block is removed: a row that is slack at the optimum, hence with a zero multiplier, leaves the entry of the pool where it is and the linearization it gives is the one it gave before, while a row that is active takes the entry away, what is left of its dual solution no longer satisfying the dual constraints

• the tester of MCFBlock checks what a direction of a MCFBlock is: on an instance with a negative cost cycle of infinite capacity the Solution a :MCFSolver gives has to say that it holds a direction, which the MCFBlock takes for one and not for a solution, while a :MCFSolver that gives no such certificate throws and is skipped

• a batch of LagBFunction over the easy components, which nothing was exercising

• a batch can set an algorithmic parameter in a ComputeConfig and time each run, so that a sweep over the values of one parameter is a batch and not a script written for the occasion; the two batch-aggr take the values of intCmpAggrRule that way

• batch-k of the multicommodity suite, the knapsack formulation asked for as a structure, and MMCFBlock_test links the ML variant of the BundleSolver, which batchML attaches

• a driver that runs the batteries backing the validation claim of the dynamic programming Solver of the thermal units, and the batteries require again the fixture that extracts the instances they read

• the batteries of UCBlock run the instances once per value of the rule that forms the groups of the parallel inner loop, and cross-check the academic and plan4res families over the exact Lagrangian chain; in the AC family the Lagrangian dual is declared a relaxation, its point being a convex combination, and the QCP sub-problems give the duals that chain needs

• the SVM suite cross-checks LIBLINEAR on the formulations that LIBSVM cannot express, exercises the exact path and the shrinking, which nothing was running, and compares the Lagrangian dual with a SMOSolver on each chunk

• batch-ec runs the Benders form of the energy community instances, the form the tester assembles giving the master a cost for every design Variable and keeping integer, in the master, a design that counts modules; the convex regime of the Benders Solver has its own cross-check configuration

• a batch for an InvestmentBlock wrapping a whole stochastic Block, two- stage or multi-stage, whose instances follow the trees they are built over; the inner Solver is asked for homogeneous dual directions, which the HiGHS variant cannot give, and the configuration says so where it happens

• the batteries of BinaryKnapsackBlock cover what BranchAndXSolver does: the lazy bounding protocol in every serial exploration strategy, the reoptimization with one Solver per strategy, the negative weights and the regime of a small instance re-solved many times, over the hard instances of Jooken as well, and the benchmarks of the coverage declare the greedy relaxation each of their configurations attaches

• the Frank-Wolfe decomposition is posed on the BinaryKnapsackBlock of that suite as well, in batch-pisinger, with the dynamic programme of each knapsack as the Linear Minimization Oracle: since no compact formulation describes the convex hull of a knapsack, what the decomposition computes is a lower bound on the monolithic optimum and not the same number, so the battery declares the variants relaxations (-R) and holds them to nothing (-E), so what is checked is that they agree with one another and that none of them passes the bound. The instances are the netCDF ones the bk2nc4 of the module writes out of the curated archive the rest of that battery reads

• UCBlock_test --scale, which checks the scale factor of a unit, i.e., the number of copies of it that a UCBlock holds, on two instances the tester writes itself, one carrying a thermal unit and one a nuclear one, each of them with a cost of every kind its Objective can hold, the two reserves and the reactive power: the model of a unit scaled once the abstract representation is built has to be the one of a unit scaled before it, which is compared coefficient by coefficient over the Objective of every unit and the rows of the UCBlock that use their Variable, and through the optimum; the data of the unit, being those of one copy, must not move although the Solver attached to it hears of the scaling; and the three dynamic programming Solvers have to answer for all the copies, i.e., to give the value of the Objective, also once a price has been written into it the way a dualizing Solver writes its multipliers. The thermal unit is taken in each of the seven formulations, with and without the perspective cuts. The comparison of the models asks for no Solver at all, so that it runs in a build that has none; the optimum and the dynamic programming Solvers are checked where a :MILPSolver is in the build

• the batch batch-nuclear of the ThermalUnitBlock_Solver suite, which compares the NuclearUnitExtDPSolver with a :MILPSolver on the operating rules of nuclear units, in eight families of rules, four regimes of the costs (energy only, rewarded reserves, priced reactive power, rounds of changes of the costs) and two formulations of the rules, the default one and the tight one; a further environment variable, TUDPS_FIXMOD, fixes one modulation variable out of the given number, so that the two Solver are compared on a unit whose rules are partly decided; two further BlockSolverConfig serve the study of the solve times, BSCfg-nuc-lim.txt, which holds the MILP solver to a time limit, and BSCfg-nuc-dponly.txt, which attaches the dynamic programming Solver alone, so that the optimal schedule can be looked at without paying for the MILP solve

• the PyPSA instances with the pollutant budget constraints of UCBlock in pypsa-data/pollutants/, run by UCBlock/batches/batch-pypsa: a PyPSA network with a CO2 limit twice and half the emissions of the unconstrained dispatch, a CO2 and a NOx limit, a CO2 floor, a CO2 equality, an operational limit on a carrier, and CO2 limits where a store and a hydro storage unit contribute through their final level, translated by pypsa2smspp and held to the PyPSA objective

• UCBlock_test --pollutant (the ctest UCBlock_test/pollutant), which checks the pollutant budget constraints of UCBlock on small instances it writes itself, whose optima are known: several zones per pollutant and a node in none, rates depending on time, lower bounds and equalities, the level of a battery, the scale of a unit, the setters of the budget and of its lower bound, the duals through a UCBlockSolution, the netCDF round trip and the data UCBlock::deserialize() must refuse

• the MILPSolver suite (the ctest MILPSolver_test/groups), which solves the same program with every :MILPSolver in the build, its Variable and Constraint grouped in every shape a Block allows

• the AbstractBlock_mirror suite, which checks the copy of the abstract representation of a Block that AbstractBlock::mirror() builds: that it is the same problem as the original, whichever :MILPSolver solves the two, that solution information moves back to the original, and that the copy follows the original when this changes

• the exact Lagrangian chain for UCBlock: BSPar-DP.txt attaches the three Solver over sub-Block solved to optimality by the dynamic programming Solver (TUBSCfg-DP.txt, InnerBSCfg-DP.txt, LDCfg-DP.txt, PPHCfg-DP.txt) and a :MILPSolver that solves the MIP rather than its continuous relaxation, stopping on a time limit so that what it gives is a valid pair of bounds rather than a claimed optimum (MILPCfg-MIP.txt). With the relaxation in the sub-Block the penalty of the PrimalProximalHeur acts on variables that are not binary there, and its first penalized call does not converge: on T-Ramp 10_0_1_w the heuristic goes from 86 to 13 seconds, its bound becomes the Lagrangian one rather than the value of the continuous relaxation, and every inner call ends on "optimal". No batch uses it yet: the LagrangianDualSolver is a relaxation with a duality gap there, so it has to be declared with -E ,inf

• the cross-check of common_utils: every Solver enters it as its [get_lb(), get_ub()] interval, valid by the base Solver contract, and is measured against the best bounds the whole set of them provides, since the optimum is not known. Correctness, i.e. not contradicting those bounds, is owed by every Solver; the quality it declares is owed only by the one that returns kOK, i.e. that says it delivered what it was asked, while kLowPrecision promises nothing. No Solver type or name is ever inspected

• the tolerance each Solver is held to, which is by default the dblRelAcc its ComputeConfig asks of it, and never less than the tolerance the cross-check is called with, below which the comparison would only measure its own numerical noise

• the -E option, overriding that tolerance per Solver (positionally with respect to the BlockSolverConfig, the empty field leaving the Solver to its dblRelAcc), for the Solver that does not say with kLowPrecision when it did not deliver the accuracy it was asked for, and whose dblRelAcc therefore says nothing about what it returns

Changed

• the tester of LagBFunction no longer writes intDoEasy of the BundleSolver it attaches: whether they treat the LagBFunction as easy components and which of their dual values they keep is in the BlockSolverConfig ndopar, NDOPar.txt by default and NDOPar-Hard.txt with positive #nt, and the rows of batch and batch-easy name the one their changes want, out of NDOPar-Hard.txt, NDOPar-Dual.txt (all the dual values) and NDOPar-RC.txt (the reduced costs), differential overrides of BSCfg.txt as the -Dual.txt version of NDOPar-Mirror.txt, NDOPar-Lvl.txt, NDOPar-DS.txt and NDOPar-DS-NoSize.txt are

• the inner Solver of the PrimalProximalHeur and of the LagrangianDualRelaxationSolver takes its iterations and its accuracy from its own ComputeConfig, given with str_LDSlv_ISCfg: ISCfg-PPH.txt in UCBlock, TwoStageStochasticBlock and SMS++/AbstractBlock, and ISCfg-LDRS.txt in UCBlock, in place of intInnerMaxIter and dblInnerRelAcc; intMaxThread, which the two Solver now keep for the threads of their primal recovery, is 0 in their configurations, as intRecoveryThreads was 1, and UCBlock/PPHCfg-DP.txt is PPHCfg.txt with only what differs

• UCBlock/batches/batch-acad-s cross-checks a BranchAndXSolver too, whose nodes are solved by the LagrangianDualRelaxationSolver over the same sub-Blocks that the dynamic programming solves exactly, as a fourth Solver of BSPar-DP-BX.txt stopped on time, branching on the commitment variables only (vstrBranchGroups); in CI it runs on the units of size 10 only, the other ones being solved with BSPar-DP.txt, as each instance takes 2 to 8 minutes and a test is given an hour on the runner of the nightly pipeline. batch-bx-ld and BSPar-BX-LD.txt, which ran it alone on four instances, are gone, and the configurations of the Lagrangian Dual and of the Branch-and-Bound are fragments (LDCfg-DPe.txt, LDRSCfg-DP.txt, BXLDCfg.txt, BXLDCfg-DP.txt)

• UCBlock/batches/batch-acad-s cross-checks a second BranchAndXSolver, whose nodes are solved by the LagrangianDualRelaxationSolverML with the branching rule learned online after 2 nodes of strong branching (LDRSCfg-DP-ML.txt, InnerBSCfg-BX-LD-DP-ML.txt, BXLDCfg-DP-ML.txt), in CI too on the units of size 10; a build without Torch leaves it out of the run, and UCBlock_test links LagrangianDualSolverML when there is

• in CI MultiFlowDCRBlock batches-multiflow/batch runs one instance in 10, and SingleFlowDCRBlock batch-instances the P/C formulation on one instance in 10 and not the SOCP one, on which Gurobi stops on numerical difficulties on the runner of the nightly pipeline, a different instance at each run, while it solves them on the machines of ours

• the meta BlockConfig and BlockSolverConfig of the tests accept the "*" entry for the classnames they do not name, as those of tools do, and the sub-Block of a Block are looked up after it has been configured

• in CI, MCFBlock/batches/batch and batch-dense leave out the Frank-Wolfe decomposition, a single run of which takes the best part of an hour there (batch-small runs it on the small instances), LagBFunction/batches/batch runs 3 seeds of the 20, and UCBlock/batches-tub/batch-reserve one instance in 10 of each family, so that each fits in the time limit of a test of the nightly pipeline

• the report of SolveAll() starts on a line of its own, below whatever the test printed before it, and pads the values to the widest of them, the reference included, so that the values and the times of the Solver are in columns whatever the length of their names and of their intervals

• LDCfg-easy.txt and BSPar-DP.txt of UCBlock name the hard components with vstrNoEasy of the inner BundleSolver, which replaces vstr_LDSl_NoEasy of LagrangianDualSolver: which components are easy is a concept of BundleSolver, and the classes listed are the same

• BDSCfg-LD.txt recovers a feasible solution at the design of the master (strRecoveryBSC BSCfg1-IP.txt), and the thermal run of TwoStageStochasticBlock/batches/batch-pypsa checks the interval of BendersDecompositionSolver, its bound below and that solution above, against the reference instead of its bound alone

• BDSMCfg-INV.txt declares the residual zero at 1e-6 instead of 1e-8: with the subproblems solved by a Lagrangian dual, whose linearizations are accurate to its own dblRelAcc, the bundle of the master reached the optimum without ever certifying its lower bound, and BendersDecompositionSolver reported -inf

• the testers are named after the component they test: AbstractBlock_Box_test is LagrangianDualSolver_Box_test, since what it exercises is the LagrangianDualSolver (and the PrimalProximalHeur of the same module) on a box-structured AbstractBlock whose LagBFunction are solved by BoxSolver, and its battery is LagrangianDualSolver_Box_test/batches/batch-box; BendersBFunction_test2 is BendersBFunction_linearization_test, whose source is test_linearization.cpp, since it checks the linearizations the BendersBFunction produces on small linear programs whose value is known

• PolyhedralFunctionBlock_prune_test tests only PolyhedralFunctionBlock::remove_redundant_rows(), which has to remove both the dominated and the inactive row, while the geometric pruning of PolyhedralFunction::remove_parallel_rows() is tested by PolyhedralFunction_prune_test, on a convex function with the dominated row after and before the dominating one and on a concave function, and needs nothing but the core library

• GenerateRand(), the random subset of k distinct indices out of 0 ... m - 1 that eight testers copied (and the tester of MMCFBlock kept commented out), is written once in common_utils and takes the generator as argument, the order of the subset being optional as it was in the testers of MCFBlock and of CapacitatedFacilityLocationBlock: the draws from the generator are the same as before, so every battery generates the same instances

• the TwoStageStochasticBlock suite is configured before those of CapacitatedFacilityLocationBlock and UCBlock, whose batteries of the scenario reduction run its TSSB_scenred_test

• BendersBFunction_test runs in the suite, on the 34 small instances of the capacitated warehouse location problem (cap41 to cap134), the large ones being left to a run by hand: it takes the instances as files as well as a directory, prints one line per instance and exits with 1 when an instance is KO, while it used to print KO and exit with 0; its directory has the SMS++ label, which ctest -L "SMS\+\+" selects (the label is read as a regex, where the + are operators)

• the ComputeConfig of the :MILPSolver of the SingleFlowDCRBlock suite is written once, in MILPCfg.txt, which BSPar.txt, BSPar-pc.txt and the configurations of the multi-flow problem include, Gurobi through GRBCfg.txt, which adds a numerical focus of 2: without it the barrier stops short of the optimum of the SOCP formulation on some instances of the module, with a "Numeric error" or with a value a little below it

• the configurations of the Benders tester of SVMBlock are named as the others are, BSPar-BDS-<variant>.txt (e.g., BSPar-BDS-SMO.txt, BSPar-BDS-LSVM.txt) and BSPar-LSVM-only.txt; the three variants of SMOCfg.txt are overrides of it, and the BSPar-SMO*.txt have the header of every other configuration

• the tester of UCBlock builds no configuration in code: it reads -B and -S and applies them. The LagrangianDualSolver of BSPar.txt and BSPar-DP.txt comes from LDCfg-easy.txt, which lists the hard components by class (vstrNoEasy of the inner BundleSolver), the parallel variants of batch-ec-par are BSPar-par.txt and BSPar-par-aggr.txt rather than a config rewritten by the batch, and the network formulations of batch-pypsa are InnerBCfg-PTDF.txt and InnerBCfg-CYCLE.txt

• the formulation of the unit of TUDPS_test is the BlockConfig given with -B, one file per formulation (TUBCfg-<form>.txt, -PC with the Perspective Cuts), which the batteries of batches-tub loop over; the tester reads it back, as the changes it makes depend on it. TUBCfg-DP.txt (DP with the cuts) is now TUBCfg-DP-PC.txt

• the budget of rounds of the two capped runs of CFL_BDS_test is int_BDSlv_MaxRounds in BDSCfg-MILP.txt, of which BDSCfg-Pareto.txt is the override with the Pareto-optimal cuts; BSPar-BDS-MILP.txt and BSPar-BDS-Pareto.txt include them

• what the testers give an InvestmentBlock and its InvestmentFunction comes from the configuration files, the testers only reading and applying them: in InvestmentBlock and in test_bds of TwoStageStochasticBlock, the OBlockConfig of the InvestmentBlock (IBOCfg.txt, the InvestmentBlock entry of InnerBCfg.txt) reformulates the bounds and gives the InvestmentFunction its ComputeConfig (IFCfg.txt) with the BlockSolverConfig of the inner Block, where the code built the BlockConfig, named BSCfg1.txt in code and set the file of the candidates; the InvestmentBlock of an SDDPBlock, in a problem file, has its stages configured by -B and its greedy Solvers given the passage of the state. BSCfg1.txt is now BSCfg.txt, and InvBCfg.txt of TwoStageStochasticBlock, a BlockSolverConfig, InvBSCfg.txt. The threshold of the Lagrangian case of UCBlock_test --pollutant is in LDCfg-tight.txt rather than set in code

• the instances of batches/batch-ec whose components are all ECNetworkBlock, and hence all easy, are solved with the BSPar.txt of every other instance of that battery, BundleSolver handling that case now: the battery no longer picks a configuration by the name of the file, the tester no longer forces one of the components to be hard, and UCBlock/BSPar-EASY.txt, which was BSPar.txt with intDoEasy at 0, is gone

• the Lagrangian duals of TwoStageStochasticBlock declare the residual zero at 1e-6 rather than 1e-2 (LDCfg.txt, which every one of them includes): with 1e-2 the bundle stopped with a dual value up to 1.6% below the optimal one and bounds that both lay below it, whence the cut of BendersDecompositionSolver over such a subproblem was never tight and its loop repeated it

• SMS++/LagBFunction/TPPar.txt asks HiGHS for feasibility tolerances of 1e-7, the default, rather than 1e-9: the tolerances are absolute, and 1e-9 goes beyond what double precision holds as soon as the objective grows past 1e7, which is how the suite of InvestmentBlock failed

• the ComputeConfig of the flow relaxation of the capacitated facility location, all of them the default one, are the single DfltCfg.txt that the two configurations point at instead of seven copies of the same block, which is what takes those two files from 338 and 340 lines to about 100

• the two batteries of MCFBlock run one seed of their three when $CI is set, as the one of the dynamic programming already runs 5 of its 100 ramp profiles: the three seeds are the same sweep with another random stream, while the whole of them takes more than an hour on a machine of ours and does not fit what a test is given on a shared runner

• the inner Solver of the BendersBFunction suite is Gurobi, the one the image of the pipeline carries, so that the suite runs where it is run and not only where a licence of another solver happens to be

• the comparison of the three forms of a two-stage stochastic investment problem lives with the suite of the Block it is posed on, and not with the one of a Solver: the monolithic form, the Lagrangian one and the Benders one are configured side by side there

• the makefile asks for -O3 -DNDEBUG and nothing else, the macro of the patch for boost::any on macOS having no reason to be there since there is no boost::any left in the core

• the tester of the copy of an AbstractBlock and the one of the reference of the multicommodity suite are named after what they are, the core having a target called as the first one was

• a suite is guarded on the modules it is labelled with, and the benchmark of BundleSolverML is skipped when its modules are not in the build, so that a build without a module has no test that cannot run rather than a test that fails

• the batteries of the Lagrangian dual of the unit commitment fit the three hours a job is given: the academic families are sampled in CI, the plan4res one is run as a smoke test, and the metabatch is not run there, being the batteries it is made of. batch-ac is added, and the variants of the energy community under the proximal heuristic are skipped in CI, where the objective of a thermal unit inside a LagBFunction is the known bug

• the batteries of the scenario reduction read their executables and their directories from the arguments instead of the paths of whoever wrote them, the tester is named after the Solver it drives, and the folder of the facility location is named after the Block it holds

• the tester of BendersBFunction reports and counts its checks instead of aborting at the first one that fails, so that one run says how many of them hold and not only that one does not

• the comparison of the two Benders decompositions of a facility location instance lives with the suite of that Block, its configurations take the names the other suites give them, the inner Solver of the Lagrangian is called BundleSolver, which is the name the factory has, and the BlockConfig files are in the format of now

• a run of the Frank-Wolfe tester attaches the reference and one FrankWolfeSolver per variant of the decomposition at once, cross-checking the variants against one another as well, the way the BSPar of a suite do with the Solver of its Block; the variants used to be run one at a time by a battery that rewrote the ComputeConfig file between them, which is gone together with the trap that put the file back. Each variant is an override of the shared fragment, and an override block writes the extra-Configuration slot even when it changes nothing of it: one that leaves it out is read on to the end of the stream and swallows the ComputeConfig that follows it, which is what made the Solver of every variant but the first run with its parameters at their default

• the configurations of the Frank-Wolfe tester live in the suite, flat beside those of every other Solver, rather than in a directory of their own that a battery selected with -c: they are the Father* files, the same set with the same names in each of the three suites the tester is built in

• the reference BlockSolverConfig of the Polyhedral path of the Frank-Wolfe tester is -F, -R going back to what it is everywhere else, i.e. the declaration of which Solver solve a relaxation of the problem

• the master problem of the Frank-Wolfe direction taken from a bundle (MPBCfg-FW.txt, the same in the three suites) is solved by the dual simplex of Gurobi rather than by the barrier Gurobi picks for a QP: with the barrier almost every solve ended SUBOPTIMAL, the primal residual stalling just above the feasibility tolerance, and the number of iterations of a run changed from one run to the next, while with the simplex every solve is optimal and two runs of the same case repeat to the last iteration

• the four sector-coupled instances batch-pypsa walks are written by the conversion as it stands, where an extendable asset with no upper bound keeps the infinite design cap it has instead of a finite number standing in for it: the ones the archive held carried 1e10 on nine converters and 1e9 on nine batteries, which the Lagrangian relaxation sends a design straight to, so that 262 of the 311 linearizations of a solve carried a subgradient entry of exactly 1e10 against function values of 1e9, the rows of the master of the bundle became a difference of terms of 1e12 giving 1e8, and on one of the four the master declared its numerical difficulties unrecoverable a step away from the optimum, upon which the bundle emptied itself one item at a time and the Lagrangian dual ended in error. The objective value of each of the four is the one it was, the caps having never been binding

• every directory of the suites is named after the module its tests are posed on, a suite living here exactly when the module cannot run it by itself: the testers of the objects of the core library are under SMS++, those of the quadratic programs a :MILPSolver is asked to solve under MILPSolver, the benchmark of the machine-learning driven bundle, which reads the Block of two modules that are not among its dependencies, under BundleSolver/ML, and the suite of the facility location takes the name of its module, CapacitatedFacilityLocationBlock. compare_formulations, which is posed on whichever two Block its configurations name, stays in the root

• the batteries of UCBlock that walk the instances carrying one unit alone are batches-tub, and each of them runs that family with every :Solver that applies to it: the dynamic programme against the :MILPSolver, and the Frank-Wolfe decomposition of a father of K copies of the unit, which used to be a batch of its own

• the suite of FrankWolfeSolver is dissolved into the suites of the Block it is posed on: the tester assumes nothing on the leaf Block it reads, hence it is fw_test.cpp in the root beside common_utils, and each suite builds it with its own modules; MCFBlock builds it and the tester of what a Modification of the feasible region of a sub-Block does, and UCBlock builds it on the thermal unit

• the runs of a Solver that is not the one of the Block are in the battery of the instances they are posed on rather than in a batch of that Solver, its configurations staying together in a directory of their own, which -c names; this is what FW is in the suites of MCFBlock and of UCBlock. The scenario reduction, which has no configurations of its own to keep apart, is in the suites instead: the generator of the scenarios of a unit commitment is in that of UCBlock and what a reduction costs on an investment problem is test_reduction.cpp in that of TwoStageStochasticBlock, the Block it is posed on, each with its battery in batches

• a battery runs every tester that applies to the family of instances it walks, and is therefore given all of them, the first as before and the others after it: add_batch_test() names them and hands over the ones that are in the build. In MCFBlock this is the Solver of the Block, the Frank-Wolfe decomposition and the rounds of Modification of the feasible region on the same instances, batch-small being the fast one that walks every code path of the decomposition; in UCBlock the dynamic programme and the decomposition on the same units

• the tester of the ways BendersDecompositionSolver has of writing a cut is not here: it writes the instance it runs on itself, hence it needs no Block of anyone else and it belongs to the test directory of that module, where it is and where it is being worked on. What stays here is the comparison of the ad hoc Benders decomposition a CapacitatedFacilityLocationBlock carries with the generic one, which is posed on that Block

• BSCfg-nuc-dponly.txt of UCBlock is gone: it registered the extended dynamic programming Solver of the nuclear unit twice, so that the tester, which compares a first and a second Solver, would run with it alone. A Solver compared with itself checks nothing, and no battery used it; timing the dynamic programme alone is a thing to ask the tester for, not something to obtain by declaring the same Solver twice

• • the report of a cross-check says what each Solver is called, one per line and with the values aligned one under the other, instead of numbering them S0, S1, ...: with several Solver of different families on the same Block, which of them disagrees is what one needs to read at a glance

• the three testers posed on an AbstractBlock are one directory, SMS++/AbstractBlock: the box-structured Block whose Lagrangian dual is computed (test_box.cpp), the copy of the abstract representation (test_mirror.cpp) and the round trip of a linear program through a file (test_readwrite.cpp), with a batch each in batches. The two regimes of the box one, the Lagrangian dual and the primal proximal heuristic, are one script taking which of them to run

• the batches of a suite are registered with add_batch_test(), written once in the root instead of the same loop copied in every directory

• the scenario reduction is run from the suite of the Block whose scenarios are reduced: the generator of the unit commitment instances and the runs on them are in the suite of UCBlock, those of the facility location in that of CapacitatedFacilityLocationBlock, each with the two configurations they read

• a suite is named after the Block its tests are posed on, not after a Solver that runs on it: AbstractBlock_mirror is AbstractBlock, and LagrangianDualSolver_Box is AbstractBlock_Box, the structured AbstractBlock of box-constrained sub-Block being what it builds and the Lagrangian dual one of the ways it solves it

• the suite of MILPSolver is the test directory of that module, where its two testers now live as test_farkas.cpp and test_groups.cpp: neither of them needs a Block of another module, hence neither of them needs to be here

• the suite of the dynamic programming solver of ThermalUnitBlock is part of the suite of UCBlock, whose instances it reads and whose Block it solves in two ways: the tester is test_tudps.cpp and its batches are in batches-tub, each of them run with that tester rather than with the one of the suite

• SVMBlock runs the comparison of the two dual decompositions of one training problem, the consensus one under LagrangianDualSolver and the Benders one under BendersDecompositionSolver, both cross-checked against the ad hoc solver of the module, and PolyhedralFunctionBlock runs the unit test of the pruning of the rows: both come from the test directory of BendersDecompositionSolver, which is not where a test that needs another Block to exist belongs

• SMS++/AbstractBlock runs the validation of BendersDecompositionSolver on a two-stage linear program written as an AbstractBlock, the tester being test_bds.cpp (AbstractBlock_BDS_test, labelled SMS++;MILPSolver;BundleSolver;BendersDecompositionSolver) and its configurations BSPar-BDS*.txt, BDSMCfg.txt, BDSMCfg-MILP.txt and BDSSCfg.txt, the master problem of the bundle using the MPBCfg.txt of the suite: it comes from the test directory of the module, which is not where a test belongs that needs a BundleSolver for the master and a :MILPSolver for the subproblems and the reference, neither being a dependency of the module

• batch-resilient of UCBlock, TwoStageStochasticBlock, MultiStageStochasticBlock and InvestmentBlock is now batch-pypsa, and the instances it reads are in data/nc4/pypsa-data instead of data/nc4/resilient-data, the folder that holds all the networks translated from PyPSA, one sub-folder per kind of problem: ucblock, pollutants, tssb (whose files are named after the perturbation, instead of lying in a sub-folder each) and mssb; the instances of EC_Data are divided in the same way, in ucblock, tssb and mssb

• the PyPSA instances of pypsa-data/ucblock and of the pypsa-data of InvestmentBlock are written by one generator, test/instance_generator.py of pypsa2smspp, which builds each test network once and writes it in the two forms the conversion supports, the one where the design variables are those of the UCBlock and the one where an InvestmentBlock wraps it: the two are therefore the same problem and are held to the same reference, the objective value PyPSA computes on that very network. The demand and the hydro inflow of a test network being drawn at random, the generator fixes the seed, so that the instances can be written again; the uncapped extendable assets take the finite caps of the instances with a pollutant budget, an unbounded design making some Lagrangian sub-problem unbounded. The reference values all change, the previous instances coming from an older state of the conversion, and one instance is named after its Excel case, 2n_1c_1g_1b_2l instead of 2n_1c_1g_1b

• the two-level scenario trees of pypsa-data/mssb, and the ones the InvestmentBlock runs with the investment stated outside the scenarios, are written by test/tree_instance_generator.py of pypsa2smspp from the trees references/gen_resilient_tree.py draws with a fixed seed, each form of a tree being held to the objective value PyPSA computes on the equivalent flat network. The reference values change, the instances in place having been emitted from trees that were drawn again since, and so do the file names, the trees now spanning a day of 24 instants rather than 100: over 100 the MultiStageStochasticBlock of one of them ends in an error after eleven minutes, and the InvestmentBlock over the flat form of another after twenty-four

• the two instances named after the inv_ Excel cases are gone, those cases giving the very networks 1n_1c_1gext and 2n_1c_1gext_1bext_2l give, to the byte

• UCBlock/batches/batch-pypsa runs with its own BlockSolverConfig, BSPar-PYPSA.txt, which is BSPar-EASY.txt with intWZNorm at 2 rather than the 10 of LDCfg.txt: that parameter says which norm of the residual the stopping condition uses and how dblNZEps is read, and the 8 of that 10 asks for a threshold scaled by the norm of the first full subgradient, which the plan4res instances want. The subgradients of these instances are the productions of the units on the very rows the demand sits on, so that norm is 7.27e+06 against an aggregate of 1.96e+04, and 1e-2 of it stops the Bundle at the first iteration on a value two orders of magnitude below the optimum; read as the absolute value it is on develop, their duals converge in 50 to 600 iterations on the value the MILP computes; InvestmentBlock/batches/batch-pypsa fails when it finds no instance at all, which is how a batch that has tested nothing was until now indistinguishable from one where everything went well

• check_relaxation_solutions() holds the point a relaxation reconstructs to the dualised rows only where that relaxation is exact, i.e., where the bound it reports is the optimum: where it is not, that point is a convex combination which violates those rows by the very gap, and holding it to them called a duality gap an error. The reference value is the new argument that says which of the two cases one is in

• InvestmentBlock/batches/batch-pypsa fails when it finds no instance at all, which is how a batch that has tested nothing was until now indistinguishable from one where everything went well

• the nested chain of TwoStageStochasticBlock (BSPar-2S-LD.txt, where each scenario sub-problem is solved by an inner LagrangianDualSolver) evaluates every component at each iteration, dblMinNrEvls = -1: a component being an entire inner Lagrangian Dual, an iteration made on one of them alone buys little and pays a master problem anyway; on the NC instances of the energy community the oracle calls go from 865 and 1705 down to 132 and 168, and nothing gets worse on the others

• LPBSCfg-LD-noeasy.txt, the inner LagrangianDualSolver of that chain with intDoEasy = 0, which the instances with no installable asset need: every unit of theirs is "easy", and a Lagrangian Dual all of whose components are easy is not supported

• with -v 2 the cross-check prints, before solving, the parameters of every Solver it is about to run, the inner ones included; the level of -v can be written attached or separate, since getopt only hands over the attached form

• the solve-a-Block-with-Solvers cross-check testers renamed after the Block they exercise: UCBlock (was LagrangianDualSolver_UC, executable UCBlock_test) and MCFBlock (was MCF_MILP, executable MCFBlock_test); LagrangianDualSolver_MMCF was merged into MMCFBlock as a second executable (MMCFBlock_test) alongside the existing MMCF_test, sharing its instance data

• the one-per-instance cross-check line of SolveAll() (timings, every Solver value, reference, verdict) is now always printed; only the per-round lines of the tests that re-solve in a loop of modifications remain verbose-only

• PrimalProximalHeur is attached to the AC and resilient batteries too (BSPar-AC.txt and BSPar-EASY.txt now cross-check it as well)

• the PPHCfg of UCBlock solves the Lagrangian Dual of every proximal iteration to convergence, with the stopping parameters BSPar.txt gives to the LagrangianDualSolver on the same Lagrangian Dual, so that the fractional solution the penalty is built on is the convexified one, and follows the parameters of PrimalProximalHeur being now named after the algorithm they belong to; no -E is needed for the LagrangianDualSolver, which says with its return code that it is a relaxation; the LagBFunctions solve the sub-Block with the same BlockSolverConfig the LagrangianDualSolver gives them, rather than with the plain relaxation of every one of them

• UCBlock cross-checks every Solver of its BlockSolverConfig at once, rather than selecting one of them from the command line: the meta- batches are gone and each batch is a ctest test of its own

Removed

• the batteries batch-aggr of MMCFBlock and of CapacitatedFacilityLocationBlock, which measure the times of the partial aggregation of BundleSolver for a paper and check nothing (no ctest runs them): they live with the other experiments of that paper; with them go cfg_set_par and run_timed of batch_common.sh, which only they used

• the options -l, -n, -r and -s of the tester of InvestmentBlock, which had no effect, and the functions only they or nobody called; the configurations of InvestmentBlock that the suite never read (BSCfg.txt as it was, BSCfg2.txt, BlockConfig1.txt, BlockConfig2.txt, RBlockConfig1.txt, RBlockConfig2.txt, SimpleConfig1.txt, SimpleConfig2.txt), copies of those of compare_formulations

• the option -f of the tester of UCBlock, the formulation of the HydroSystemUnitBlock and the rest of the configuration it built, which -B and -S give; OUBSCfg.txt and SRSCfg.txt, which no test read

• the option -f of TUDPS_test and the third argument of CFL_BDS_test (the budget of rounds), which the configuration files give; the relaxation that the tester of QuadFunction set on top of LPPar_C.txt, which already asks for it

Fixed

• the variants of FrankWolfeSolver in one run of fw_test start from the same point: a FrankWolfeSolver starts from the vertex its oracle gives at the values it finds in the Block, which were those the previous Solver had left, so that the same variant gave a different value according to what ran before it and the comparison depended on the order of the BlockSolverConfig; SolveAll() takes a Solution to write into the Block before each Solver, and fw_test passes the one the father has before any of them computes

• SolveAll() takes the side of the bound of a Solver declared a relaxation from the sense of the objective of the Block, which a Block without an Objective of its own (its objective being the sum of those of its sub-Block, as for MultiKnapsackAssignBlock) also gives, the bound of such a maximization problem having been taken for a lower one

• SMS++/AbstractBlock/test_box changes the RHS of the <= linking rows and the LHS of the >= ones, and checks each against the value it set

• the CapacitatedFacilityLocationBlock batteries require the fixture that extracts data/txt, which they read, and the conversion to netCDF waits for it

• UCBlock/MPBCfg.txt asks Gurobi for FeasibilityTol 1e-8 rather than the 1e-9 of the other MPBCfg.txt: the units of the Lagrangian relaxation of the UC give no vertical rows, against which the tighter value is there, and with it the master stopped with status 12 (numerical difficulties) after the presolve, 18 times in a row on T-Ramp 10_0_4_w

• the test run_dmx2nc4 of MCFBlock and MCFClassSolver_run_dmx2nc4 share a RESOURCE_LOCK: they build the same target, and under ctest -j they ran at the same time and wrote the same instances, leaving one of them empty, so that MCFBlock_test/batches/batch failed on it

• check_relaxation_solutions() does not hold to the dualised rows the reconstruction of a Solver that stopped before converging (anything but kOK, which SolveAll() now records, last_status()), since its residual is not zero yet: on a slower machine the Lagrangian dual of L_B_N_9 stops at its time limit, and its combination was taken for a wrong one

• TSSB_test/batches/batch-mmcf requires the fixture canad_fetched, so that the Canad instances its generator reads are there when it starts rather than when fetch_canad_data happens to have run before it

• batch-p4r declares the interval of the Lagrangian dual on L_B_N_1, 2.5e-3 wide while the bundle reports kOK, as it does for L_B_C_24

• the tests of BinaryKnapsackBlock and test_tudps perturb the solution they read back only in the Variable that are not fixed, as writing a different value in a fixed ColVariable throws

• the cross-check of SolveAll() declares the infeasibility unanimous when all the Solver that are not relaxations say infeasible and those that are have a one-sided bound, which is no claim of feasibility (the Lagrangian dual of an infeasible problem with feasible subproblems grows without ever proving it), rather than taking them for a disagreement, and so for a Solver whose interval is the whole line, such as a heuristic that has found nothing

• a tester picks the :Solver it solves with through first_Solver_of() of common_utils, which returns the first of the given names that the factory holds and says on std::cerr which ones it has looked for, and what the run gives up, when it holds none of them: Solver::new_Solver() throws on a name that is not there, so UCBlock_test --scale, which asked the factory for one name after the other, died with "CPXMILPSolver not present in Solver factory" on every build without CPLEX, the pipeline comprised

• the two fixtures that bring in the curated knapsack data, fetch_bk_data and run_bk2nc4, hold the same RESOURCE_LOCK: run at once, as ctest -j2 did, they drive the build system on the same txt.tgz, which tar then reads as an archive that ends too soon

• the archive of the Canad instances of MMCFBlock is extracted by cmake -E tar, which also works with the tar of macOS, where the option --warning=no-unknown-keyword of GNU tar stopped the build

• the tester of MultiStageStochasticBlock writes the round trip of the Solution to a file of its own name, since the batteries of the suite run in parallel in the same directory and read each other's file

• a tester whose instance file is not there says so and stops with 1, where Block::load( std::string ) wrote on std::cerr and returned, leaving an empty Block on which the run went on until something else broke: on CapacitatedFacilityLocationBlock an exception about the number of facilities being too small, which reached std::terminate() and dumped core, hiding the missing file behind a message about the instance. The check is load_Block_or_exit() of common_utils, used by the testers of CapacitatedFacilityLocationBlock and MCFBlock; CFL_BDS_test keeps skipping the comparison instead, the ORLib instances being downloaded by the build and not always there

• CFLScenarioGenerator/batches-scenred/batch asks for the fixture that writes the netCDF instances it reads, without which it failed in a fresh build tree

• the tester of CapacitatedFacilityLocationBlock applied BSPar1.txt and BSPar2.txt by itself, so that the Solver this build does not have were not left out as the other testers leave them [see s_config_Block()], and a run died on MCFSolver<MCFCplex> not present in Solver factory wherever CPLEX is not there, the pipeline included

• InvestmentBlock/MPBCfg.txt leaves the presolve of the master at its default: with it off the master of a design over several extendable lines ends in "Bundle::FormD: unrecoverable MP failure"

• MCFBlock/BSPar-static.txt, the configuration with every Solver of a MCFBlock whose graph does not change, is in the repository: batch, batch-small and the README of the suite read it, and without it batch-small stopped at its first run

• BinaryKnapsackBlock/batches/batch-jooken and batch-pisinger-large run with OPENBLAS_NUM_THREADS=1, and BSPar-milp.txt gives HiGHS a single thread: the memory cap of the two lineups is on the address space, and on a machine with many cores the threads that OpenBLAS starts at load time (one per core up to 64) and the pool of HiGHS (half of the cores) took the parallel depth-first BranchAndXSolver and the MILP past 8 GB, so both crashed on every instance while using a few tens of MB

• the step that fetches the data archive of the multicommodity suite says what went wrong when it goes wrong: the download is checked, an archive that did not arrive is removed instead of being left on disk for the build to take for the real one, and the message names the URL. A server that answers with an error page used to leave a file of a few bytes there, which made the next build fail while extracting it, with the message of tar and no mention of the download

• the build no longer waits for the data of the facility location: the tester of the Benders decomposition was hung on the target that extracts the archive, which put the download in the default target, so a registry that answers with an error stopped the build of the libraries as well, and it took a 503 of GitLab to see it. What the tester needs is prepared by a test fixture, as in every other suite

• the two configurations of the suite of InvestmentBlock asked HiGHS for a feasibility tolerance of 1e-9, which is absolute, on instances whose objective is of the order of 1e11, i.e., beyond what double precision holds: HiGHS declared the model optimal and its primal solution infeasible at the same time, which reaches the caller as a solve that went well with no solution in it, and the InvestmentFunction turned that into an error that stopped the bundle. They ask for 1e-7, the default, and batches/batch-pypsa passes

• LukFi_test stops with an error when the BlockSolverConfig it reads attaches no Solver to the LukFiBlock, e.g. because the file is empty or malformed, rather than crashing on the first element of an empty list

• the suites that try each :MILPSolver in turn skipped the ones the build does not have by constructing them, while Solver::new_Solver() throws rather than returning nullptr on a name the factory does not hold, so MILPSolver_test/groups and UCBlock_test/pollutant died with CPXMILPSolver not present in Solver factory wherever CPLEX is not installed; they ask Solver::has_Solver() first, and AbstractBlock_mirror_test, which named CPXMILPSolver and nothing else, takes the first :MILPSolver the factory holds unless one is named on the command line

• the tester of ThermalUnitBlock compares the Solution of a Solver with the state it left in the Variable once that is completed from (p, u) as the Solution is when it is written: with the perspective cuts the epigraph a Solver leaves is only as tight as the separated cuts, 1e-7 relative, and on an objective that is the difference of much larger terms this showed as a Solution worth 4e-6 more than the Variable

0.6.0 - 2025-12-12

Added

• tests comparing UCBlock solutions with expected values

• tests for PrimalProximalHeur

• ComputeConfig for "easy" case in LagBFunction

• tests for duals in LDS_MMCF

• [big] tests for Quadratic Problems

• LEMON to tests/MCF_MILP

• support for both LP and MPS fles in Write-Read

Changed

• MMCFBlock/gen and the README accordingly to account for the new way of distributing the instances

• all things that can be changed, and the common definitions, are now in makefile_common to reduce code duplication within makefiles and to make adapting to one's environment quicker

• adapted to new standard organization of makefiles

Fixed

• several fixes throughout the testers

0.5.4 - 2024-02-29

Added

• compare_formulations tester

• Write-Read tester

• added -Wno-enum-compare to Makefiles (we regularly do that in SMS++)

Changed

• adapted to new CMake / makefile organisation

• significant updates to CapacitatedFacilityLocation

Fixed

• many minor fixes to testers and/or config files

0.5.3 - 2023-05-17

Added

• Early stop in test of ThermalUnitBlock.

Removed

• GoogleTest-based test for DPThermalUnitBlock.

Fixed

• LagrangianDualSolver_UC/test.

0.5.2 - 2022-07-01

Added

• CapacitatedFacilityLocation tester.

• Code to test different formulations of some problem.

Changed

• Complete rehaul of MCF_MILP tester.

0.5.1 - 2021-12-08

Added

• New tester for ThermalUnitDPSolver.

0.5.0 - 2021-12-08

Added

• ThermalUnitBlock_Solver tester.

• BinaryKnapsackBlock tester.

Changed

• Completion of dynamic variables handling in test/PolyhedralFunction.

0.4.0 - 2021-02-05

Added

• Significant improvements in LagBFunction testing.

• Testers now better use BlockSolverConfigs to be more general.

• Significant improvements in BendersBFunction testing.

• Added MMCFBlock tester.

• Added LagrangianDualSolver_UC tester.

• Added BoxSolver tester.

• Added LagrangianDualSolver_Box tester.

• Added LagrangianDualSolver_MMCF tester.

• Improved UCBlock tester.

• Improve README.md with ones for individual testers.

Fixed

• Too many individual fixes to list.

0.3.2 - 2020-09-24

Fixed

• Workaround for default MCFSolver setting.

0.3.1 - 2020-09-24

Fixed

• Compilation issue under Debian/Clang 7.

0.3.0 - 2020-09-16

Added

• Support for concurrency.

• Support for new configuration framework.

Changed

• Files reorganized.

0.2.0 - 2020-03-06

Added

• Changelog.

Fixed

• Minor fixes.

0.1.0 - 2020-01-10

Added

• First test release.