コンテンツにスキップ

LLZO Fast-charge bottleneck map

bulk / grain boundary / Li interface を 同一スキーマで横に並べて読むための比較ハブです。
ここでの主眼は full-cell のフル充電時間予測ではありません。
「どこが fast-charge のボトルネック候補になりやすいか」 を、A100x4 上の再現条件つきで見比べられる形に整理することが目的です。

結論（先に要点）

  • bulk だけ見ても足りません。 grain boundary と Li interface を同じ土俵に載せて比較する必要があります。
  • 今回は A100x4 + QE runbook 資産の再利用を前提に、比較を回せる再現条件を整理しました。
  • ただし canonical な再現条件は、現時点では core runbook script 直呼びではなく wrapper 経由 fixed stack です。
  • fixed stack を採った理由は drift 回避です。runbook script 内の 25.7 fallback と、親シェルの PATH / LD_LIBRARY_PATH が 25.7 を先頭に持っていたことが、観測 drift の根にありました。

このページの読み方

先に知りたいこと このページの見どころ
何を比較しているのか bulk / GB / interface を同一 schema で比較している点
何が今回の再現条件か wrapper 経由 fixed stack が canonical である点
baseline から壊れていないか doctor / verify(short) PASS、native-only bench PASS、np1/nk1 WALL 28.28s を確認している点
次に何を疑うべきか bulk 以外に GB / interface を切り分けるべき、という読み筋

これは何を示すページか

LLZO の fast-charge で問題になりやすいのは、「材料全体が遅いか」ではなく、
bulk / grain boundary / Li interface のどこが詰まりやすいか が条件ごとにずれることです。

このページでは、その比較を 同一 schema で並べるために、

  1. baseline 環境の健全性確認
  2. drift root cause の切り分け
  3. wrapper 経由 fixed stack の固定
  4. fixed stack 上での verify と minimal native-only bench
  5. bulk / GB / interface の共通指標テーブル化

までをひとつの流れとしてまとめています。

1ページで見る全体像

項目 今回の扱い いま言えること
baseline 環境 doctor / verify(short) PASS 出発点の runbook baseline 自体は成立
drift root cause 原因を切り分け済み 25.7 fallback と親シェルの PATH / LD_LIBRARY_PATH が主因
canonical 実行条件 wrapper 経由 fixed stack 既存 QE 7.5 prefix を維持しつつ、NVHPC 26.1 / CUDA 13.1 / HPC-X 2.25.1 を pin
fixed stack verify PASS fixed stack 上でも runbook 系の verify は崩れていない
minimal native-only bench PASS np1/nk1 の PWSCF WALL は 28.28s
public baseline との差 大きな後退なし 公開基準 30.84s と比べて異常な後退は見えていない
比較対象 bulk / GB / interface common schema で横比較できる状態まで整理済み
未抽出指標 status 管理 residence / crossing など未抽出分は空欄にせず status で保持

bulk / GB / interface 比較表

軸 今回このページで見せるもの 何を次に疑うか
bulk baseline を壊していないか、fixed stack で native-only bench が成立しているか bulk 自体が遅いのか、それとも bulk は基準値内か
grain boundary bulk では見えない局所的な詰まりやすさを別軸として切り出す 粒界近傍で律速候補が立つか
Li interface 界面条件でボトルネックがずれる可能性を切り出す 界面モデル側の条件が支配的か

ここでの比較は、full-cell のフル充電時間予測ではなく、
どこに次の解析コストを振るべきかを判断する比較です。

bottleneck map の見方

bulk

  • bulk は「まず基準が崩れていないか」を見るための入口です。
  • 今回は fixed stack 上で native-only bench が PASS し、np1/nk1 の PWSCF WALL が 28.28s でした。
  • これは既存の public baseline 30.84s と比べても、異常な後退がない範囲です。

grain boundary

Li interface

  • Li interface は、bulk / GB とは別に 界面条件でボトルネックがずれる可能性を見るための軸です。
  • 既存の Ep1: LLZO/Li interface（DFT + ML-IAP + Allegro） は界面モデルの入口で、今回の map はその比較先を増やす位置づけです。
  • ここでも重要なのは「full-cell 時間の予測」ではなく、次にどこを疑うべきかを切り分ける比較であることです。

なぜ fixed stack が必要だったか

今回の drift は、単に「runbook が壊れていた」というより、環境解決の揺れが原因でした。

観測した root cause

  1. runbook script 内に 25.7 fallback が残っていた
  2. 親シェルが PATH / LD_LIBRARY_PATH で 25.7 を先頭に持っていた

このため、同じつもりで回しても、実際には 期待していない 25.7 系に寄る余地が残っていました。

今回の canonical 条件

  • 既存 QE 7.5 prefix はそのまま使う
  • その上で wrapper により
  • NVHPC 26.1
  • CUDA 13.1
  • HPC-X 2.25.1 を pin

つまり、QE 本体の prefix は壊さず、実行面だけを非破壊で固定しています。
現時点の canonical な再現条件は、この wrapper 経由 fixed stack です。

共通指標テーブルの意味

今回の成果物では、bulk / GB / interface を common_metrics.csv で同一 schema に揃えています。
重要なのは、未抽出の指標を空欄にせず、status で残している点です。

この方針により、

  • 「まだ取れていない」のか
  • 「取ったが比較不能」なのか
  • 「今回の canonical 条件では未実装」なのか

を後から追い分けやすくなります。

fast-charge の議論では、residence / crossing のような値を後から足したくなるため、
欠測を黙って空欄にしないこと自体が再現性の一部です。

どこまで public に言えるか

  • 言えること
  • A100x4 上で、QE runbook 資産を再利用しつつ、bulk / GB / interface を比較する整理まで持っていけた
  • canonical 条件は wrapper 経由 fixed stack
  • baseline / fixed stack verify / minimal native-only bench は PASS

  • fixed stack 上の np1/nk1 WALL は 28.28s で、public baseline 30.84s に対して異常な後退は見えない

  • このページで言わないこと

  • full-cell のフル充電時間を予測した
  • bulk / GB / interface の絶対的な優劣が普遍的に決まった
  • 1つのベンチだけで実材料の充電特性を断定できる

関連ページ

次に見るべきポイント

  1. bulk が速いだけで議論を閉じない
  2. GB と interface を同一 schema に乗せて、どこで差が出るかを見る
  3. その前提として、runbook baseline と fixed stack の役割を分けて扱う

次のアクション（迷ったらここ）