feat(PowerSystems): add SecurityConstrainedDispatch benchmark

[Yunn1633]

Background

This task optimizes generator active-power and voltage setpoints under normal and N-1 operating scenarios. An independent AC power-flow verifier checks feasibility and scores operating cost and robustness.

Source

The bundled MATPOWER cases come from PGLib-OPF v23.07 at commit dc6be4b2f85ca0e776952ec22cbd4c22396ea5a3. License and provenance information are included under references/.

Validation

From the benchmark directory:

../../../.venvs/frontier-pglib-scd/bin/python verification/evaluator.py scripts/init.py --metrics-out metrics.json --artifacts-out artifacts.json

From the repository root:

python -m frontier_eval task=unified task.benchmark=PowerSystems/SecurityConstrainedDispatch task.runtime.python_path=uv-env:frontier-pglib-scd algorithm=openevolve algorithm.iterations=0

[github-actions]

🤖 AI Code Review (gemini-3-flash-preview)

🇬🇧 English Analysis

1. Executive Summary

• Core Purpose: This PR introduces a new benchmark task, SecurityConstrainedDispatch, to the PowerSystems suite. The task requires an agent to optimize generator active-power and voltage setpoints to minimize costs while maintaining grid stability under normal and N-1 contingency scenarios (single line outages), using real-world PGLib-OPF datasets.
• Modified File Structure & Modifications:
  • benchmarks/PowerSystems/README(.md|_zh-CN.md): Added entries for the new SecurityConstrainedDispatch task.
  • benchmarks/PowerSystems/SecurityConstrainedDispatch/README(.md|_zh-CN.md): Comprehensive documentation on setup, environment, and execution.
  • benchmarks/PowerSystems/SecurityConstrainedDispatch/Task(.md|_zh-CN.md): Detailed technical specifications, input/output schemas, and scoring metrics.
  • benchmarks/PowerSystems/SecurityConstrainedDispatch/baseline/: Included a feasible but non-optimal baseline solution (solution.py) and its performance log.
  • benchmarks/PowerSystems/SecurityConstrainedDispatch/frontier_eval/: Metadata files (constraints, file lists, run scripts) for integration with the frontier_eval framework.
  • benchmarks/PowerSystems/SecurityConstrainedDispatch/references/: Data provenance, PGLib source cases, and a sophisticated scenario generation script (build_scenarios.py).

2. AI Content Analysis

• Estimated AI Component: 15%
• Reasoning & Evidence: The core logic, particularly in references/build_scenarios.py, demonstrates deep domain expertise in power systems engineering (e.g., adversarial linear-cost OPF to create baselines, handling MATPOWER indices like GEN_STATUS, PMAX, PMIN). This is unlikely to be purely AI-generated. However, the documentation structure and the boilerplate metadata files in frontier_eval/ follow a highly standardized template, suggesting AI assistance in generating documentation and configuration files.

3. Engineering & Economic Assessment

• Engineering Reality Check: Production-Grade. Unlike "toy" power flow problems, this benchmark uses AC power-flow (nonlinear physics), respects N-1 contingency constraints (industry standard for reliability), and utilizes the PGLib-OPF dataset (the gold standard in the research community). It also implements seccomp for process isolation, showing a high level of engineering maturity.
• Economic Value: High. Optimal Power Flow (OPF) with security constraints is a critical real-world problem. Even marginal improvements in cost efficiency (the 70% weight in the score) while maintaining safety margins can translate to millions of dollars in operational savings for grid operators.

4. Quality Assurance

• Verification & Testing:
  • frontier_eval Integration: Yes.
  • task_name: PowerSystems/SecurityConstrainedDispatch
  • Execution & Dependencies: The README.md and README_zh-CN.md clearly document the environment setup using venv and the installation of dependencies from verification/requirements.txt.
• Documentation Quality: High, with minor issues. The documentation is thorough and bilingual. However, there is a significant formatting/encoding error in Task_zh-CN.md under the "Input" section, where many characters are replaced by ? (e.g., case ??????????????). This needs immediate correction.
• Organizational Structure: Excellent. The structure is modular, separating reference data, verification logic, and agent scripts. The use of a references/ directory for data provenance is a best practice.

5. Security & Privacy Check

• Sensitive Files: Clean. No .env, API keys, or IDE-specific files were detected.
• Absolute Paths: None detected. The scripts (e.g., build_scenarios.py) correctly use Path(__file__).resolve() to handle relative paths.

---

🇨🇳 中文分析

1. 摘要

• 核心目的: 此 PR 在 PowerSystems 序列中引入了名为 SecurityConstrainedDispatch 的新基准任务。该任务要求 Agent 优化发电机的有功功率和电压设定值，在利用真实 PGLib-OPF 数据集的情况下，在正常和 N-1 故障场景（单线路断开）下最小化成本并保持电网稳定性。
• 修改的文件结构与变更摘要:
  • benchmarks/PowerSystems/README(.md|_zh-CN.md): 增加了新任务 SecurityConstrainedDispatch 的入口。
  • benchmarks/PowerSystems/SecurityConstrainedDispatch/README(.md|_zh-CN.md): 提供了关于设置、环境和执行的详尽文档。
  • benchmarks/PowerSystems/SecurityConstrainedDispatch/Task(.md|_zh-CN.md): 详细的术规范、输入/输出架构和评分指标。
  • benchmarks/PowerSystems/SecurityConstrainedDispatch/baseline/: 包含了一个可行但非最优的基准解决方案 (solution.py) 及其性能日志。
  • benchmarks/PowerSystems/SecurityConstrainedDispatch/frontier_eval/: 用于集成到 frontier_eval 框架的元数据文件（约束、文件列表、运行脚本）。
  • benchmarks/PowerSystems/SecurityConstrainedDispatch/references/: 数据来源、PGLib 原始案例以及复杂的场景生成脚本 (build_scenarios.py)。

2. AI 成分分析

• 预估 AI 含量: 15%
• 判断依据与证据: 核心逻辑，特别是 references/build_scenarios.py 中的内容，展示了电力系统工程方面的深厚领域知识（例如，使用对抗性线性成本 OPF 来创建基准，处理 MATPOWER 索引如 GEN_STATUS, PMAX, PMIN）。这不太可能是纯 AI 生成的。然而，文档结构和 frontier_eval/ 中的模板化元数据文件遵循高度标准化的模式，表明在生成文档和配置文件时使用了 AI 辅助。

3. 工程与经济评估

• 工程现实检验: 生产级。 与“玩具级”潮流问题不同，该基准测试使用交流潮流（非线性物理），遵守 N-1 应急约束（工业可靠性标准），并利用 PGLib-OPF 数据集（研究界的黄金标准）。它还实现了 seccomp 进行进程隔离，展示了极高的工程成熟度。
• 经济价值: 高。 带有安全约束的最优潮流 (OPF) 是一个关键的现实世界问题。即使在保持安全边际的同时对成本效率（评分中占 70% 权重）进行微小改进，也可以为电网运营商节省数百万美元的运营成本。

4. 质量保证

• 验证与测试:
  • frontier_eval 集成: 是
  • task_name: PowerSystems/SecurityConstrainedDispatch
  • 运行与依赖: README.md 和 README_zh-CN.md 清晰地记录了使用 venv 的环境设置以及从 verification/requirements.txt 安装依赖的过程。
• 文档质量: 优秀，但存在细微问题。 文档详尽且为双语。然而，Task_zh-CN.md 的“输入”部分存在明显的格式/编码错误，许多字符被替换为 ?（例如 case ??????????????）。这需要立即修正。
• 组织结构: 极佳。 结构模块化，将参考数据、验证逻辑和 Agent 脚本分开。使用 references/ 目录记录数据来源是最佳实践。

5. 安全与隐私检查

• 敏感文件: 未发现异常。 未检测到 .env、API 密钥或 IDE 特定文件。
• 绝对路径: 未检测到。 脚本（如 build_scenarios.py）正确使用了 Path(__file__).resolve() 来处理相对路径。

[y-ji24]

感谢贡献 SecurityConstrainedDispatch。整体任务设计比较完整，数据集、Evaluator、Docker 隔离以及验证流程都已经搭建起来，文档也比较齐全。整个 benchmark 已经具备基本的可运行性。

合并前，建议先处理下面几个与 benchmark 有效性和评测正确性相关的问题。

1. 建议说明评分函数的设计依据

目前 evaluator 使用

• 70 × cost_efficiency + 20 × thermal_margin + 10 × voltage_margin

计算场景得分，再采用

• 0.75 × mean + 0.25 × min

汇总最终成绩。

这组权重直接决定了 benchmark 的优化目标，但目前没有看到相关说明，例如是否参考了实际调度场景、行业标准，还是经验设置。

建议在 README 或设计文档中补充评分设计的来源。如果属于经验参数，也建议简单说明设计考虑，或者提供权重敏感性分析，方便理解 benchmark 的评价目标。

2. 当前评分区分度较小

根据提交中的结果，baseline 得分约为 71.27，参考 AC-OPF 解约为 78.00。

理论分数范围虽然是 0–100，但目前有效方案主要集中在一个较窄的区间内，可能导致不同方案之间的区分度有限，也容易受到求解器版本或数值误差影响。

建议考虑重新设计评分映射，适当拉开不同方案之间的差距，或者在 Task 文档中明确说明这是一个 credit-based optimization benchmark，而不是绝对评分。

3. 建议进一步考虑固定测试集的过拟合问题

目前所有评测场景均来自公开的 PGLib-OPF 数据，并直接保存在 benchmark 中。

由于 agent 可以读取这些数据，也可以调用 MATPOWER 等工具重新求解，因此 benchmark 更容易评估针对固定数据集的优化能力，而不是算法本身的泛化能力。

后续可以考虑保留部分测试集作为 holdout，或者对已有案例进行一定程度的随机扰动，以降低固定数据集带来的过拟合风险。

4. Evaluator 建议检查同母线发电机的 VG 一致性

Task 中明确要求：

All online generators at the same bus must use the same voltage setpoint.

不过目前 evaluator 主要检查格式、收敛性和 OPF 验证，没有看到对应约束的验证逻辑。

建议在评测前增加这一检查，将同一母线上的发电机进行分组，确认其 VG 保持一致（允许合理数值容差），避免不满足任务约束的方案仍然参与评分。

5. 建议进一步完善 seccomp 的隔离策略

目前 candidate_worker.py 采用的是 seccomp 黑名单方式，仅屏蔽部分系统调用。

这种方式容易因为遗漏新的 syscall 而留下安全风险，例如目前没有看到 io_uring 相关系统调用的限制。另外，Python audit hook 主要覆盖高层文件操作，对直接使用底层系统调用的情况保护有限。

建议评估是否采用白名单策略，仅开放 benchmark 运行所需的最小 syscall 集合；如果继续采用黑名单，也建议补充 io_uring 相关限制。

非阻塞建议

以下内容不会影响本次合并，但可以考虑完善：

• 当前 evaluator 为了检查确定性，会对每个场景运行两次 candidate，整体评测时间约增加一倍，可以考虑采用更轻量的确定性验证方式；
• 超时检测目前依赖异常字符串匹配，建议优先基于异常类型进行判断，提高鲁棒性；
• Task_zh-CN.md 当前存在编码问题，建议统一保存为 UTF-8，避免中文文档乱码。

整体来看，benchmark 的整体方向没有问题，建议解决以上问题后继续审核。