Describe the task in natural language. Let the agent choose the route, patch inputs, run checks, execute stage by stage, and report results back in chat.
Crystal/material inputs in, curated GW/RPA workflow, band-structure artifact out.
oh-my-LibRPA is an AI experience layer for ABACUS + LibRPA.
The idea is simple:
- users should talk in natural language, not memorize workflow commands
- the agent should understand whether the case is molecule / solid / 2D
- the workflow should follow curated experience, not ad-hoc guessing
- expensive runs should still respect fresh directories, static checks, and stage-by-stage validation
In practice, that means the agent can help with:
- preparing GW / RPA inputs
- auditing uploaded bundles instead of blindly rewriting them
- catching route mismatches before remote execution
- running and reporting each critical stage
- producing a final scientific artifact such as a paper-style GW band plot
Tip
Think of it as a chat-native workflow harness for real ABACUS + LibRPA work — not just a pile of templates.
Copy this into your AI assistant:
Install and configure oh-my-LibRPA by following:
https://raw.githubusercontent.com/AroundPeking/oh-my-LibRPA/main/docs/guide/installation.md
curl -fsSL https://raw.githubusercontent.com/AroundPeking/oh-my-LibRPA/main/install.sh | bashFor local development:
cd ~/code/oh-my-librpa
bash install.shExample prompts:
Help me run GW for GaAs with a conservative setup first.This is a molecular system. Prepare inputs using the molecular route.How do we fix this error? Give me the minimal repair action.Mirror an existing FHI-aims + LibRPA QSGW case and stage a new k-point sweep first.
After the first install, use the in-place updater instead of repeating the full install flow:
~/.openclaw/workspace/oh-my-librpa/update.shIf the local updater is missing:
curl -fsSL https://raw.githubusercontent.com/AroundPeking/oh-my-LibRPA/main/update.sh | bashFor Windows + Git Bash agent updates, see:
- single entry-point skill:
oh-my-librpa - stack-layer skill:
oh-my-librpa-abacus-librpa - stack-layer skill:
oh-my-librpa-fhi-aims-qsgw - file-first intake for structures, inputs, logs, and archives
- compute-location handshake before expensive work starts
- route selection by
molecule,solid, or2D
- molecular GW short route
- periodic GW full route
- periodic GW symmetry lane with ABACUS symmetry metadata carried by
stru_out - RPA split from GW-only preprocessing
- FHI-aims + LibRPA QSGW/G0W0 supplement for case mirroring and staged campaigns
- spin / SOC consistency checks across helper scripts and
librpa.in
- new isolated run directory per run chain
- when reusing an old case, copy only source inputs and helper scripts into the new run directory; never carry over generated outputs such as
OUT.ABACUS,band_out,coulomb_*,LibRPA*.out,librpa.d,time.json, or old GW data - static preflight before remote execution
- Markdown run reports written both in-run and to archive
- stage-by-stage reporting for SCF / pyatb / NSCF / preprocess / LibRPA
- absolute reproducibility: all conversations, intermediate specs, and code versions are archived with structured naming — enabling quantitative evaluation of AI-assisted physics workflows (inspired by DMRG-LLM, arXiv:2604.04089)
- curated rule cards
- route-aware templates
- workflow helpers for preflight, checks, execution, and reporting
- bundled plotting helper for periodic GW results
- example server-profile conventions for reproducible runtime setup
Molecule GW: SCF -> LibRPA
Periodic GW: SCF -> pyatb -> NSCF -> preprocess -> LibRPA
Periodic GW sym: SCF(symmetry=1,rpa=1,no SOC, stru_out metadata) -> pyatb -> NSCF(symmetry=-1) -> preprocess -> LibRPA(symmetry flags)
RPA: SCF -> LibRPA
For SOC cases, do not use the periodic symmetry lane. Keep the ABACUS side on symmetry = -1 and do not enable the LibRPA symmetry flags.
The agent should decide the lane from the user's files, intent, and system type — then explain what it is doing and why.
If you only open three pages, open these:
| Page | What it is for |
|---|---|
docs/guide/installation.md |
Full install flow for agents and humans |
docs/guide/chat-guidance.md |
What the user should say, what the agent should ask, and how the interaction should feel |
examples/si-k444-gw/README.md |
A realistic periodic GW walkthrough with final output expectations |
Useful supporting material:
| Path | Purpose |
|---|---|
skills/ |
Chat-facing skills |
docs/guide/fhi-aims-librpa-qsgw.md |
Supplemental route for FHI-aims + LibRPA QSGW/G0W0 cases |
rules/cards/ |
Structured experience: scene → symptom → root cause → fix → verify |
templates/ |
Workflow templates and plotting helpers |
scripts/ |
Preflight, consistency checks, stage reporting, and workflow runners |
references/ |
Shared notes such as server-profile conventions |
registry/ |
Example runtime profiles and registry-style assets |
Paper-style GW band figure generated from a chat-driven periodic GW workflow.
chat request
-> route selection
-> intake / consistency checks
-> stage-by-stage execution
-> archived run report
-> final scientific artifact
This is the shape the project is aiming for: not just “some scripts,” but a workflow that is explainable, checkable, and pleasant to drive from chat.
- chat orchestrator skill:
oh-my-librpa - stack-layer routing skill:
oh-my-librpa-abacus-librpa - stack-layer routing skill:
oh-my-librpa-fhi-aims-qsgw - core workflow skills:
abacus-librpa-gw,abacus-librpa-rpa,abacus-librpa-debug - rule cards for workflow defaults and repair patterns
- route materialization for molecular GW and generic periodic lanes
- intake / preflight / consistency helper scripts
- stage-aware GW and RPA runners
- Markdown run logging in both run directory and archive
- self-test after install/update
- periodic GW plotting helper for compact paper-style figures
oh-my-librpa/
|-- skills/
| |-- oh-my-librpa/
| |-- oh-my-librpa-abacus-librpa/
| |-- abacus-librpa-gw/
| |-- abacus-librpa-rpa/
| |-- oh-my-librpa-fhi-aims-qsgw/
| `-- abacus-librpa-debug/
|-- references/
|-- rules/cards/
|-- templates/
|-- scripts/
|-- examples/
|-- registry/
`-- docs/
- Chat-first — users should not memorize custom workflow commands
- Experience-driven — curated rules are preferred over ad-hoc prompting
- Route-aware — molecule, solid, and 2D cases should not be treated as the same workflow
- Extension-friendly — keep the ABACUS mainline intact while adding supplemental routes for other DFT stacks such as FHI-aims
- Safety-first — fresh run directories, static checks first, no silent overwrite of source data
- Report what happened — every important stage should say what was done, what was observed, and what is next
- Reproducible by default — every conversation, spec, and code version is preserved for post-hoc analysis and quantitative evaluation
- prefer static checks before remote execution
- every run chain must use a new isolated directory
- never overwrite original data directories
- for expensive or long jobs, confirm compute location and resource choice first
oh-my-LibRPA is the domain skill for the AITP Research Protocol — a protocol-first research runtime that turns AI agents into disciplined physics collaborators.
- AITP manages the research lifecycle (projects, layers, gates, human interaction).
- oh-my-LibRPA provides the domain knowledge (contracts, operations, invariants, routing).
- They communicate through structured contract files on disk.
Both projects share a commitment to externalized specifications and absolute reproducibility, formalized in the AITP Externalized Spec Protocol.
For the full integration guide, see docs/aitp-integration.md.
The domain manifest is at registry/domain-manifest.abacus-librpa.json.
oh-my-LibRPA turns ABACUS + LibRPA workflow knowledge into a chat-native, route-aware, safety-conscious agent layer.