arm-hpc-monitoring

Arms real-time log monitors on in-flight A2MC HPC ensemble processes at session start.

Updated Aug 28, 2026
One-click install
npx skills add https://github.com/jingtao-lbl/A2MC --skill arm-hpc-monitoring-jingtao-lbl
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: arm-hpc-monitoring
Source: https://github.com/jingtao-lbl/A2MC/tree/main/.claude/skills/arm-hpc-monitoring
Command: npx skills add https://github.com/jingtao-lbl/A2MC --skill arm-hpc-monitoring-jingtao-lbl

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a multi-thousand-case calibration ensemble is running on Perlmutter, a crashed process looks identical to a healthy one if you only watch for progress events. This Skill ensures every long-running HPC process (auto-monitor, submitter, extractor) is detected and covered by a persistent monitor with both progress and error filters, so failures are caught instead of silently missed. ## Core Features & Use Cases - Process Detection: Uses ps -ef to find live auto-monitor, submitter, and extractor processes, cross-checked against the latest handoff dev log. - Error-Aware Monitoring: Arms persistent Monitor tasks with filters combining progress signals (TRANS_DONE, MILESTONE) and failure signatures (ERROR, Traceback, FAILED, OOM, MaxJobsExceeded). - Event-Driven Reactions: Provides a reaction table mapping events to concrete proposals, such as queue headroom math with model-dependent job multipliers and next-phase recommendations. - Zombie Job Cleanup: Detects and surgically cancels dead SLURM dependency chains that would otherwise hang completion watchers forever. - Use Case: You resume a session while a 1,140-case ELM-FATES round is in flight. The Skill detects the running auto-monitor and submitter, arms monitors on their logs in tmp/, and proposes the next batch when the queue drops below threshold. ## Quick Start Detect any in-flight A2MC ensemble processes on Perlmutter and arm persistent monitors on their logs with both progress and error filters.

Frequently Asked Questions about arm-hpc-monitoring

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I monitor a running SLURM ensemble job on Perlmutter?▼

Detect live processes with ps -ef filtered for auto-monitor, submitter, and extractor scripts, then arm a persistent tail -F monitor on each log with a filter combining progress events and error signatures like ERROR, Traceback, FAILED, and OOM.

How do I check the status of a standalone model ensemble without log files?▼

Run tools/model_ensemble_status.py with the model name and run root to reconcile Slurm job state against the model's own success check. For job arrays, pass --ensemble-jobs so dead cases are not misreported as still running.

Why does my log monitor stay silent when the HPC job crashes?▼

A filter containing only happy-path events produces identical output for a crashed process and a healthy one. Include at least three failure signals such as ERROR, Traceback, FAILED, Killed, or OOM alongside progress signals before arming the monitor.

Why does my SLURM completion watcher never finish?▼

A crashed phase in a dependency chain leaves downstream zombie jobs stuck in PD|Dependency forever, so a watcher counting runnable jobs never reaches zero. Detect DependencyNeverSatisfied jobs with squeue and cancel the dead chain by explicit job IDs.

Does pgrep -f work for checking if a watcher process is alive?▼

No, pgrep -f matches the monitoring command's own command line, so the liveness loop never terminates. Record the PID at launch with echo $! and test liveness with kill -0 on that PID instead.