核データニュース，No.113 (2016)

会議のトピックス(II)IAEA Consultants’ Meeting “The New Evaluated Nuclear Data
File Processing Capabilities”に関する会合報告

日本原子力研究開発機構
炉物理標準コード研究グループ
多田 健一
tada.kenichi@jaea.go.jp―――――――――――――――――――――――――――――――――――――――

1.

はじめに
国際原子力機関（IAE）が主催する Consultants Meeting（以下 CM）、
「The New EvaluatedNuclear Data File Processing Capabilities（新しい核データ処理システムの可能性）」が 2015
年 10 月 5 日から 9 日まで、ウィーンの IAEA 本部で開催された。なお、本 CM の発表資料及び報告書（INDC(NDS)-0695）は以下のホームページで公開されているので、興味のある方はそちらもご参照頂きたい。
また、IAEA の CM の参加者と、新しい XML 形式の核データフォーマット Generalized
Nuclear Data（GND）のフォーマット策定を行っている OECD/NEA/NSC/WPEC の SubGroup38（以下 SG38）のメンバーはほとんど重複していることから、CM の後半の 2 日間
（10 月 8 日と 9 日）については、SG38 の会合が行われた。
本報告では、2 章で IAEA の CM について、3 章で SG38 についての報告を行う。
本資料の説明では足りないと思われる方は、是非 IAEA の HP 上で公開されている発表
資料や報告書を読んで頂きたい。
参考 HP：Consultant’s Meeting on New Evaluated Data File Processing Capabilities
https://www-nds.iaea.org/index-meeting-crp/CM_Data_Processing_2015/－ 7 －図 1 IAEA などの国連機関の集まる VIC（Vienna International Centre）

図 2 IAEA のビルへの入口

－ 8 －

2.

各国の核データ処理及び核データ処理システム開発の現状

2.1 概要中性子輸送計算等に必要とされる断面積ライブラリーを作成する現在の核データ処理
は、
世界的に LANL が開発している核データ処理システム NJOY によって行われている。
我国でも JAEA で開発している MVP や PHITS、SRAC などの多くの中性子輸送計算コー
ドの断面積処理にも利用されている。NJOY が唯一の核データ処理システムとして利用されているため、その開発が中止されたり、重大なバグが発見されたりした場合には、非常に広範囲に影響が及ぶことが懸念されている。そこで、主催者である IAEA の Nuclear Data
Services（NDS）の Trkov 氏は、NJOY とは別の核データ処理システムが必要と考え、各機関の核データ処理と核データ処理システムの開発の状況を調査するため、本 CM の開催を提案した。
参加した機関は IAEA、LANL、ORNL、LLNL、BNL（以上米国）、IRSN（仏）、NRC（露）、ヨーゼフ・ステファン研究所（スロベニア）、CIAE（中国）、KAERI（韓国）、そして JAEA（日）の 11 機関であり、日本からの参加者は筆者のみであった。なお、OECD/NEA とCEA（仏）は、参加をとりやめた。また、今回の参加者の顔ぶれを見ると、米国の研究所
は御大＋若手、IRSN は若手のみといった感じであったが、全体として、各機関の核デー
タ処理システムの主開発者の年齢が一気に若返ったようである。これは各機関でも NJOY
のみに頼っている現状に対して懸念があり、そのため開発に携わる新しいスタッフを決めて各機関が独自に核データ処理システムの開発を進めていることをあらわしていると思われた。見た目からの推測では、開発者の多くが 30 代と見られることから、筆者が国産核データ処理システム FRENDY の開発に関わる限りは、今後も長く付き合っていくことになるものと思われ、今回の会合は名前と顔を売るいい機会になった。
また、詳細は後述するが、各機関の核データ処理の現状報告を聞く限り、ORNL のSCALE 以外についてはほとんどの中性子輸送計算コードで NJOY が利用されていることが分かった。
本 CM での発表から、各機関で核データ処理システム開発に着手し始めたという状況が分かったため、Trkov 氏より、各国で処理結果の比較といった Verification を実施してみてはどうかとの提案があった。会議中には実際にやるかどうかといった話は無かったが、今後 IAEA から何らかのアクションがあるかもしれない。
また今後の評価済み核データライブラリーのフォーマットは、過去 50 年に渡って使用されてきた ENDF フォーマットから、XML 形式の GND フォーマットへと変わっていくことが想定される。そのため、この GND フォーマットへの対応が各機関の核データ処理システムの重要な課題として認識されていることが分かった。

－ 9 －

2.2

ENDF 公開時のチェックやバージョンコントロールについて

現在、BNL では ENDF 公開時のチェックやバージョンコントロールの自動化を進めている。一部については ENDF/B-VII.0 から EMPIRE と呼ばれるツールによって自動化していたが、以降で示すそれ以外の部分について開発を進めている。また、評価済み核データ
ライブラリーのバージョンはソフトウェア開発用のバージョン管理システムの一つである Git をベースとした GFORGE で管理し始め、そのためのサーバー等を近年購入したそうである。
現在、評価済み核データライブラリーから自動的に NJOY、PREPRO、Fudge 等で断面積ライブラリーを作成し、個々の断面積処理結果や積分実験（固有値や中性子束分布）の比較を行い、HTML や PDF 形式のレポートを作成するシステムを開発している。今後は
動的プロットやより多くのデータプロットの追加、対応する核データ処理システムとして AMPX を追加する事などを進めていきたいと考えているが、システム開発に必要な予算が認められているのは今年までなので、これ以上の開発は厳しいとのことであった。
今後は本来あるべき共鳴データの入れ忘れや、分離共鳴と非分離共鳴の境界の平均断面積を合わせるようなチェックを行いたいと考えているとのことである。また、評価済み
核データライブラリーのバグの分類、フォーマット、表記などの統一についても検討しているとの発表があった。

2.3

中国の CIAE-CNDC での核データ処理の原状について

中国では、中国が作成している評価済み核データライブラリーCENDL の V&V のため、核データ処理システムとして NJOY99.396 や PREPRO2015 を使用して ACE、WIMS-D、
MATXS 等の断面積ライブラリーを作成している。また、SCALE 用の断面積についても、
NJOY に処理プログラムを追加することで作成している。
また、多群の WIMS-D フォーマットを作成することを目的とした CIAE 独自の核デー
タ処理システムとして、Ruler を開発している。Ruler の各ルーチンは NJOY と同じである。Ruler は API-Centric で、Fortran90 で作成している。また、GND への対応を考慮し、I/O は ENDF フォーマットと独立した形になっている。R-matrix Limited についても処理可能で、計算時間は PENDF などの中間ファイルを作らないため、NJOY よりも高速であるとの説明があった。
Ruler では吸収断面積の KERMA の計算手法が NJOY の HEATR とは異なっている。両者の計算結果を比較したところ、物理モデルの違いにより、NJOY では低エネルギーでKERMA が上がるのに対し、Ruler では下がっていくという大きな違いが見られた。この違いについて Ruler の用いている物理モデルや理論式が間違っているのではとの意見が－ 10 －

あった。 1

2.4

The GRUCON code package: status and projects

GRUCON は、西側諸国で使用されている ENDF フォーマットと異なる核データのフォーマットを採用していた旧ソ連時代から、ENDF フォーマットを含む全てのフォー
マットを取り扱えることを目標に、ロシアで開発されてきた核データ処理システムである。また、今後は GND にも対応するため、開発を進めていくとのことであった。
GRUCON は 1970 年代から発表者の Sinitsa 氏が開発を継続的に進めており、現在はKarlsruhe Institute of Technology（KIT）と共同で GRUCON-D を開発中である。また、2015
年の 7 月までは GRUCON の V&V に IAEA が協力していたそうである。ただし、IAEA がPREPRO の開発を止めて GRUCON に合流するといった考えはなく、あくまで協力だけとのことである。
なお、GRUCON については、IAEA の NDS の以下の Web ページ上で使用することが出来る。
参考 HP：MyENDF
http://www-nds.iaea.org/exfor/myendf.htm※myENDF を使うためには、ログインアドレス・パスワードを IAEA の Viktor Zerkin 氏からもらう必要がある。

2.5

NJOY2012 Current Status and Future Plans, LANLNJOY の歴史について Kahler 氏より説明があった。また、NJOY2012 の現状についても説明があり、現在の最新パッチは NJOY2012.50 だが、今後数か月の間に NJOY2012 の最新パッチを公開する予定とのことであった。
なお、NJOY2012 の更新は今回のパッチで終了し、来年は新たに NJOY2016 を公開する
予定とのことである。なお、NJOY2016 の入手に際して新たに費用が必要かどうか確認したところ、まだ確定してはいないものの、NJOY2016 はオープンソースとする予定であるとのことであった。
また、Kahler 氏はもうすぐ退職するため、今後は次節で説明する NJOY21 の開発者である Conlin 氏がメインの NJOY 開発者になるとのことである。なお、Kahler 氏ご本人に確認したところ、MacFarlane 氏と同様に退職しても NJOY の開発に携わるつもりとのことであった。ただし、あくまで Conlin 氏のサポートで、メインは Conlin 氏に対応させるつもりとのことなので、今後は Conlin 氏が NJOY 担当として活躍するものと思われる。
1

筆者が帰国後、機構内の関係者に報告したところ、「Ruler では捕獲反応の反跳核のエネルギーが入っていないためだと思われる」との指摘を頂いた。

－ 11 －

2.6

Opening NJOY for the 21st Century, LANLNJOY21 の開発の背景について、Conlin 氏より説明があった。NJOY99 や NJOY2012 は信頼性が高く、世界中で広く使われているが、ENDF-6 フォーマットに縛られており、GNDなどの新しい核データフォーマットに対応することは困難であるとのことであった。そこで、NJOY2012 に比べてコンパイルや V&V、処理などを簡易化、高速化、フレキシブ
ル化し、更にはメンテナンス性の向上などを実現するため、21 世紀版 NJOY として、
NJOY21 の開発を昨年より開始したとのことであった。
NJOY21 は各モジュールを C++11 で、API 部分を Python でそれぞれ作成しており、Git
によるバージョン管理を実施している。また、品質保証として、Tracker やユニットテス
ト、結合テストといった現在のコード開発システムを採用している。また、古い（Legacy
な）NJOY モジュールについては、従来の NJOY モジュールを C++でラッピングして使用し、それらのモジュールが C++で新規に開発が終了し次第、順次置き換えていくことを検討している。
NJOY21 の開発はオープンソースで実施し、Git hub を使って LANL 以外とも協力して開発していくことを考えているとのことであった。現在は Conlin 氏と博士課程の学生の2 名で開発をしており、人員が足りないので開発を手伝って欲しいとのことである。なお、
NJOY21 の開発者に何か意見などがある場合は、njoy21@lanl.gov へ連絡して欲しいとのことであった。
また、NJOY21 の現在の開発状況は、Python による API 部分を開発している段階で、
NJOY2012 の各モジュールの開発は行っておらず、NJOY2012 の全モジュールをラッピングして使用している。また、併せて ENDF-6 フォーマットの読み取りプログラムを作成しており、今後は GND や ACE を始め、他の断面積ライブラリーフォーマットの読み書きについても対応する予定である。ただし、発表を聞く限り、開発を始めたばかりで様々な事項が検討段階と思われる。
NJOY21 の完全版の公開予定時期は 2021 年頃になりそうとのことであったが、完成した各モジュールを徐々に公開していくことを検討しているとのことである。

2.7

Random sampling of resonance parameters

IAEA で公開中の ENDSAM コードを用いた JENDL-4.0、ENDF/B-VII.0、JEFF-3.2 の比較についての紹介があった。詳細は IAEA の HP 上に公開されている発表資料を参照して
53Cr、
欲しいが、
JENDL-4.0 では 238Np で Positive Semi-Definite Correlation Matrix を持たず、55Mn、236Np で Correlation Matrices Compatible with Lognormal Distribution を持たないとのことであった。
JENDL-4.0 は ENDF/B-VII.1 や JEFF-3.2 に比べて指摘を受けた核種の数は極めて少ないが、指摘を受けた核種については今後確認していく必要があると思われる。

－ 12 －

2.8

LLNL’s philosophy on its open source nuclear data infrastructure

LLNL が開発中の核データ処理システム Fudge（For Updating Data and Generating ENDL）
についての説明があった。NJOY21 と同様に Fudge は API 部分を Python とし、C++のモ
ジュールを動かすシステムとのことである。ただし、Fortran で書かれた古いモジュールについては公開バージョンでは含まれておらず、C++で新規に書かれたもののみの公開となっている。
Fudge は主に ENDF-6 フォーマットと GND フォーマットの変換コードとして認識されているが、フォーマット変換だけでなく、核データライブラリーの検証や修正なども目的に開発されている。また、現在のバージョンでは、コードの組み込みなどに非常に強い制約を持つ GPL（GNU General Public License）に準拠しており、安易な利用は危険である。
しかし、次のバージョンでは、Acknowledgement に明記すれば自由な組み込みが可能とな
る BSD ライセンスに移行するとのことなので、ライセンスの問題は次のバージョンで解決されると思われる。
また、開発者の人数について聞いたところ、主な開発者は今回会議に来ていた Beck 氏と Mattoon 氏の 2 名で、他に退職した 80 代の方が週に 8 時間サポートしているとのことである。しかし、Beck 氏自身も核データ評価の割合が多く、実質的には 1.5 人くらいとのことである。

2.9

Nuclear data processing with Fudge and GND

Fudge での ENDF-6 フォーマットと GND フォーマットの変換機能の対応状況について説明があった。現在は、ENDF-6 フォーマットと GND フォーマットの変換は中性子、ガ
ンマ線、荷電粒子に対応しているが、Decay サブライブラリーについてはまだ対応していないとのことであった。
なお、Fudge で対応している GND フォーマットと、SG38 で策定している GND フォー
マットは同一のものではないことに注意が必要である。すなわち、Fudge で対応している
GND フォーマットはあくまで LLNL で策定したものであり、SG38 で合意されたものではない。今後の議論の結果は Fudge にも反映されていく予定なので、最終的には両者のGND フォーマットは同一のものになると思われるものの、SG38 で策定している GND
フォーマットは、現在の LLNL 版 GND のフォーマットとは異なる可能性がある。
また、Fudge のマニュアルには、添付資料として ENDF-6 フォーマットと GND フォー
マットの対応表を作成する予定であるとのことであった。GND のフォーマットが確定していない現状では、
JENDL や FRENDY で GND への対応を検討するのは時期尚早であり、この対応表が公開されてからの検討で十分だと考えられる。
Fudge の断面積処理結果と、PREPRO、NJOY2012 の比較が示された。線形化についてはほぼ一致することが確認されている。しかし、ENDF/B-VII.0 の 105Rh のデータを比較す－ 13 －

ると、非分離共鳴領域で差異がみられることが示された。これは、分離共鳴領域でスピンを 1/2 に、非分離共鳴領域でスピンを 7/2 にするようにと、領域によってターゲットとなる原子核の基底準位のスピンが変わっていることが要因である。この共鳴領域によって基底準位のスピンが変わっているという問題点は、JENDL でもみられ、105Rh を処理する際には注意が必要である。
また、Doppler Broadening について比較すると、非分離共鳴領域で差異がみられるとの報告があった。この差異は、NJOY では分離共鳴領域の上端で Doppler Broadening の処理を終えるのに対し、Fudge では、非分離共鳴領域でも Doppler Broadening の処理を実施していることが要因とみられる。このように各コードによって Doppler Broadening の処理の上限が違っているのは好ましくないことから、どこまで Doppler Broadening を考慮するべ
きかについては今後議論されることになるかもしれない。
前節で述べたように、Fudge には、評価済み核データライブラリーの検証機能も用意されている。主な検証項目は、全断面積と各断面積の和が等しいかどうか、Q 値が妥当かど
うか、また確率分布が負になっているかどうか、分布が規格化されているかどうか、各反応のエネルギーバランスが正しいかどうかなどである。また、可視化機能として、断面積の比較機能などが用意されており、現在はガンマスペクトルの可視化機能について開発しているとのことである。

2.10

DAPI： an API for Deterministic transport processing

LLNL の Beck 氏が、決定論コード用の核データ処理システムのクラスやメソッド名、入力の共通化を提案した。これらを共通化することで、一つの API、一つの入力で全ての核データ処理システムを実行・比較したり、それぞれの核データ処理システムのいいとこ取りが出来たりするようになるとのことである。
API については Fudge 側が作るので、クラス/メソッド名や入力を共通化して欲しいとのことであったが、断面積フォーマット毎に使っている概念(計算コードの解析対象や群構造のノウハウ、断面積の配置の仕方)が違うし、各コードで処理の仕方やメソッドの名
前、引数名、引数の数も違うので、統一するのは困難ではとのコメントがあった。
また、発表者の LLNL 以外からは反対意見が相次ぎ、インターフェースを一致させな
くても、GENDF などの同じフォーマットを作成した上で、各コードの処理結果を比較してもいいのでは？などといったコメントがあった。なお、特に強く反対していたのが、LANL、ORNL、BNL という米国内の他研究所であったのがとても印象的だった。
発表者の Beck 氏によると、今後も同様の主張を続けるようなので、FRENDY もこの議論に巻き込まれる可能性がある。全てのクラスやメソッド名を共通化するのは困難だが、API に対応するだけであれば、API 用のクラスを用意すればよいので、それほど大きな手間がかかるとは思えない。そのため、他のコードの対応状況などを見ながら、FRENDY も－ 14 －

この共通 API への対応をするかどうか決めたいと考えている。

2.11

AMPX Overview and Modernization Status

AMPX は SCALE と同じ ORNL の Reactor and Nuclear Systems Division で開発している。
ORNL では、評価済み核データライブラリーの作成に SAMMY を 2、核データ処理には
AMPX を使用している。AMPX は ORNL で 40 年間に渡り開発しており、NJOY を初めとした他のどの核データ処理システムとも独立している。AMPX の主な機能としては、温度依存の連続エネルギーモンテカルロコード用の断面積ライブラリー、共鳴の自己遮蔽、
非分離共鳴の確率テーブルなどの作成が挙げられる。
現行の AMPX は 2002 年に完成し、2012 年には品質保証（Quality Assurance：QA）などの近代的なソフトウェアデザインや開発方針を導入している。例えば、SCALE の開発には ISO9001 等の国際標準に対応した SCALE QA Program の元で開発しており、バグ対応などではトヨタ自動車の看板方式を採用している。また、FogBugz システムを用いて日々
70,000～130,000 ケースのテストの実施や、V&V として、400 ケースの臨界・遮蔽実験ベンチマークや 7,000 ケースの固定源中性子・ガンマ線計算、5,000 ケースの無限増倍率テストなどを自動的に実行・検証を行っている。さらに、ソフトウェアの検証性を向上させるため、現在、既存モジュールのソースコードの内部構造を整理するリファクタリングを進めているとのことであった。
また、現在のバージョンの AMPX は SCLE6.2 の Beta4 パッケージに含まれ、SCALE6.2のリリースと同時に公開する予定とのことである。また、SCALE6.2 の公開は今秋の予定とのことであった。ただし、AMPX は輸出規制対象となっており、SCALE6.2 が公開されたとしても、AMPX が日本で使えるかどうかは分からない。また、SCALE6.2 の β 版が欲しい場合は scalehelp@ornl.gov にメールして欲しいとのことである。 3
今後の開発内容としては、
SCALE との I/O の共通化やドキュメントの改良、
Public releaseなどを検討している。
AMPX の手法についての資料がないか確認したところ、線形化や非分離共鳴の確率テーブルなどについては個々に資料を作成しているが、まとまったものは今のところな
いとのことであった。現在、来年公開を目標に AMPX の手法をまとめたレポートを作成
中とのことである。
また、開発者についても聞いたところ、NJOY21 や Fudge と同じく、実質的には 1.5 人
程度とのことである。発表資料には多くの関係者が名を連ねていたが、SCALE の開発と2

筆者の認識では、SAMMY は核データ処理（共鳴断面積の再構成）を行うシステムであり、核データを作成するコードではない。ここで言っているのは、核データの Verification 用に SAMMY を使っている、という意味だと思われる。
3
但し、前述の通り、SCALE は輸出規制の影響を受けていることから、β版が日本から入手出来るかど
うかは分からない。

－ 15 －

掛け持ちしているため、関係者は多いものの、実際の作業量が少なく、トータルで 1.5 人分とのことであった。

2.12

An alternative approach to creating ACE data files for use in Monte Carlo Codes

Trkov 氏より、PREPRO の新しい機能について紹介があった。PREPRO では multi-band
parameters 法で自己遮蔽を評価できるようになった。本発表では、PREPRO の開発者である Cullen 氏が実施した、PREPRO の手法と NJOY の確率テーブルで自己遮蔽を評価する
手法の比較結果について報告があった。
235U と 238U の吸収/核分裂断面積の感度、OECD/NEA の Cabellos 氏がまとめた 238U の10～20keV の吸収断面積の感度や MCNP の入力があるかどうかなどの観点から、最終的に ICSBEP から 32 個のベンチマークを両手法の比較のために選択した。
両者の固有値を比較すると、最大でも 100pcm 以下で、ほとんどのケースで 20pcm 以下であった。今回の MCNP の収束条件がそれぞれ 8pcm、3pcm としていることから、
PREPRO の手法でも十分な計算精度が得られることが分かった

2.13

GAIA: Nuclear data processing for transport and criticality safety calculation at
IRSN

現在 IRSN で開発中の核データ処理システム GAIA についての紹介があった。GAIA には GAIA1 と GAIA2 の 2 つのバージョンがあり、GAIA1 では NJOY99 及び NJOY2012 の各モジュールをラッピングし、API で動かすシステムであった。それに対し GAIA2 では全てを独自開発し、ENDF-6 フォーマットや GND フォーマット、ACE フォーマットなどの読み書きに対応している。
GAIA1 では RECONR、BROADR、HEATR、THERMR、UNRESR、PURR、GASPR、ACERの各モジュールを API で操作するシステムとなっている。GAIA2 は ACE ファイルとPENDF ファイルを作るツールとして開発しており、断面積の線形化と Doppler broadening
を一つの処理としている点に特徴があるとのことである。これは、GAIA では各処理毎に処理結果の妥当性検証を行っており、検証作業量を減らすためとのことである。
GAIA2 の基本的なコンセプトは FRENDY と同様で、Nuclear data object というオブジェ
クトを各モジュール間でやり取りし、最終的に必要なフォーマットに変換して出力するようになっている。また、メインの開発者は博士課程の Ferran 氏と今回の発表者の Haeck
氏の 2 人で、他に非分離共鳴の取り扱いと熱中性子散乱則の取り扱いについては博士課
程の学生が開発中とのことである。

2.14

Current nuclear data processing status of JAEA

本発表は筆者の発表であり、JAEA での核データ処理の現状と、核データ処理システム－ 16 －

についてのニーズ、そして JAEA で開発している FRENDY についての紹介を行った。
今後の核データ処理システムについて、いくつかの希望をしたところ、以下のような指摘を受けた。本指摘は NJOY99 や NJOY2012 を使うユーザーにとっても重要な知見だと思われる。
Doppler Broadening の処理で、235U などの一部の JENDL の核種について、非分離共鳴との境界よりも非常に低いエネルギーでドップラー拡がりの処理を止めていることについて言及したところ、NJOY の開発者である Kahler 氏より、NJOY はその点を理解した上で非分離共鳴の境界より低いエネルギーで止めており、また止めていることが分かるよ
うに warning も出しているとの指摘があった。
また、熱中性子散乱則で評価済み核データライブラリーに記載された内挿式を無視している件についても、Kahler 氏より ENDF フォーマットには内挿は推奨しないと書いてあるので無視しており、ENDF6 フォーマットに準拠しているとの指摘があった。
断面積データ等のテキスト化については、Kahler 氏より VIEWR は入力自体がテキストデータであるとの指摘があった。また、Trkov 氏より、IAEA の ENDVER パッケージやOECD/NEA の JANIS を使っても VIEWR と同様にテキストデータを取り出せるとの指摘があった。
断面積フォーマットの標準化について、Kahler 氏より GENDF フォーマットはマニュア
ル中に記載があるし、標準的なフォーマットだとの指摘あった。また、Trkov 氏より、
PREPRO での ACER/MATXS と ENDF フォーマットとの比較は FENDL などで行うことができ、比較結果については IAEA の HP で見ることが出来るとの指摘があった。
また、今回、FRENDY の開発について海外向けに初めて公表したところ、多くの研究者に興味を持ってもらうことが出来た。質問としては、特に FRENDY のライセンスについての質問が多かった。

2.15

Current Status of Nuclear Data Processing Activities at KAERIKAERI では断面積ライブラリーとして、MCNP/MCNPX 用の ACE ファイルと、
DANTSYS 、 DOORS 、 WIMS-D 、 ORIGEN 用 の 断 面 積 を 作 成 し 、 ウ ェ ブ ペ ー ジ（http://atom.kaeri.re.kr）にて公開している 4。
核データの処理には NJOY99.161 や NJOY2012、PREPRO などを使用している。また、断面積処理の主な部分は NJOY を使っているが、多群断面積の作成には KAERI の独自処
理ツールを使っているとのことである。

4

発表資料も同様に公開しているという説明になっているが、筆者が当該 HP にアクセスしたところ、断面積ライブラリーは公開されていなかった。Kim 氏に問い合わせたところ、現在 KAERI の HP を改定しており、一ヶ月程度で公開するとのことであったので、本資料が掲載される頃には公開されているものと思われる。

－ 17 －

2.16

MyENDF web tool for ENDF evaluators

IAEA の NDS のサーバーアプリケーション MyENDF についての説明があった。
MyENDF は、PREPRO、ENDVER、Endf2GND、GRUCON-D などのコードで構成され、主に核データライブラリーの変換・検証をすることが目的である。IAEA では、ここ 2010
年以降に様々なアプリケーションを MyENDF に追加してきた。
現在では、Web 上で FUDGE や GRUCON、PREPRO などを動かして核データライブラ
リーの処理をしたり、グラフ化したりすることが可能となっており、これらの機能を用いて核データライブラリーの検証を行っている。
なお、MyENDF の HP へのアクセス方法については 2.4 節の GRUCON の説明で記載し
ている。

2.17

Round Table Discussion

GND の導入が転機になり、現在各機関で核データ処理システムの開発が進んでいる。
そこで、各機関の核データ処理システムのリスト化や、各核データ処理システムのモ
ジュールを相互比較するなどの検討をしてみてはとの意見があった。ただし、実際に各核データ処理システムで比較する場合は、散乱マトリックスなど、線形化しにくいデータの検証は難しく、どのように比較するかをよく検討する必要がある。
また、核データ処理システムに評価済み核データライブラリーのチェック機能を付けるべきではとの意見があった。しかし、一部のフォーマットを確認する機能はあってもいいが、核データ処理システムはあくまで評価済み核データライブラリーを処理することを目的とすべきとの反対意見があり、結論はまとまらなかった。
2.18 その他（米国の輸出規制について）
米国からの参加者の多くがコードの配布などの話題の際に、輸出規制についてしきりに気にする発言をしていたため、コードの輸出規制について質問した。MCNP6 や
NJOY2012 などに既に輸出規制の影響が見られるように、米国の輸出規制の問題は日本にとっても関心の高い内容であることから、以下にその回答についてまとめる。
米国の輸出規制には
1) 日本と同じく兵器になりうる技術の輸出規制
2) 経済的な輸出規制の 2 つがある。
この内、お金になるもの（公開することで相手国にとって経済的な利益に繋がるもの）
については、キューバ等の国に対して(2)の経済的な輸出規制が発生する。ただし、(2)の輸出規制についてはオープンソース化すれば回避できるとのことである。
また、2011 年に輸出規制が変化し、輸出規制の範囲が広がったとのことである。今ま－ 18 －

ではコードの一部が輸出規制に引っかかった場合、そこの部分を除くだけでよかったが、コード群の一部でも輸出規制に引っかかった場合、全てのコードが輸出規制に引っかかるように方針が変わったとのことである。このことから、米国の輸出規制が以前に比べてかなり厳しくなっているものと推測される。
更に、米国では輸出規制を行う機関が 3 つあり、三者三様の考えを持っており、かつ横のつながりがない。そのため、輸出規制をクリアするためには、三者三様の説明をする必要があり、輸出規制をクリアすることが非常に難しいとのことであった。
輸出規制についての説明や、発表を聞く限り、今回来ていた米国の 4 つの研究所の内、ORNL がこの輸出規制の変化について最も深刻に受け止めている印象を受けた。おそら
く、SCALE がこの輸出規制に抵触して苦労しているものと思われる。
前述の通り、既に MCNP6 や NJOY2012 などで輸出規制の影響が見られるが、今後もSCALE を始め、様々なコードが輸出規制の影響を受けることが予想される。
そのため、核データ処理システムだけでなく、他のコードについても国内で賄える体制を整えることが重要だと思われる。

図 3 ホテルザッハーのザッハートルテ－ 19 －

図 4 ウィーンの代表的な料理の一つ、グヤーシュ

SG38 会議報告

3.

LLNL の McNabb 氏を始め、SG38 の会合のみ参加の人も多かった。また、SG38 の会合には CM の参加を取りやめた OECD/NEA や CEA の関係者も参加した。
主な会合の内容や会合時に得た情報は以下の通りである。

3.1

SG38 で現在策定中の GND フォーマットについて

今回の会合では、ENDF-6 フォーマットに含まれている部分はもちろんのこと、断面積の二重微分成分など、GND フォーマットオリジナルの部分のフォーマットの策定をメインに議論していた。
核データ評価者の立場からは現在の ENDF-6 フォーマットでは物足りない部分が多くあるようで、どのようなデータを入れるべきか、またどのような形式で入れるべきかについて、各機関（特に米国の各研究所）で議論が交わされていた。

3.2

Fortran での GND フォーマットの読み取り機能について

新しいコードについては Python や C++で書かれており、XML パーサーが用意されているが、Fortran についてどうするか議論があった。その議論の中で、API を使えば解決するのではとの指摘があった。中国の Ruler は Fortran90 で書かれているそうなので、も－ 20 －

しかしたら中国の Ruler では独自の XML パーサーが準備されているのかもしれないが、その辺りについての説明はなかった。

3.3

GND フォーマットの表記方法

Google XML Document Format Style Guide をベースにフォーマットを策定した方がいいのではないかという提案があった。具体的には、一貫性、読みやすさ、コンピュータの可
読性向上の観点から、ISO8601 と XML の部分集合である RFC3339 フォーマットを用いるべきという意見があった。しかし、必ずしも Google に従う必要はないのではとの指摘あり、今後も議論がなされていくものと思われる。
また、変数の文字数についても、25 文字以下にまとめるべきとの提案があったが、ルジャンドルなど文字数が長くなる単語も多いため、あくまでも目標とすべきという結論
に至った。

3.4

次のバージョンの ENDF/B ライブラリーについて

次のバージョンの ENDF/B ライブラリーについて、関係者に聞いたところ、今後 2 年の間に出るのではないか、とのことであった。ただし、それが ENDF/B-VIII となるのか、
ENDF/B-VII.2 となるのかは現状では分からないとのことであった。
また、次のバージョンの ENDF/B ライブラリーでは、従来の ENDF-6 フォーマットに併せて、GND フォーマットについても公式版としてリリースする予定であるとのことであった。
SG38 は 2017 来年の 5 月の OECD/NEA の会合で最後となる予定とのことであったので、少なくとも ENDF-6 フォーマットに記載されている項目については近いうちにフォー
マットの策定が完了するものと思われる。

4.

終わりに
ちょうど筆者がウィーンを訪れた頃は、シリアからの難民問題が VW の不祥事で塗り潰された時であり、街中に難民が溢れているのでは、とかデモなどで大変なことになっているのではと一人で勝手に妄想を膨らませ、不安を抱えたまま当地へ向かいました。実
際、市議会議員選挙間近だったこともあり、右派の政党（自由党）がウィーンの中心地のシュテファン大聖堂前で大規模な集会を開いていたり、帰りの経由地のデュッセルドル
フでは空港内をバスで移動し、本来とは別のターミナルに移された上にパスポート
チェックを受けたりと難民の影響を感じることはありましたが、筆者の妄想に反して、日々の生活において危険を感じることはありませんでした。
むしろ小学生くらいの子が通学のため一人で地下鉄に乗っていたり、夜でも多くの観光客が街中を散策したりしているなど、他のヨーロッパの街に比べても治安がいい方だ－ 21 －

なと感じました。
現地在住の方に話を聞くと西駅やザルツブルグには難民の方々が滞在しているものの、ほとんど危険はなく、むしろデモなどの行為を行うと強制送還される口実になるため、皆さん大人しくしていると聞いて納得してしまいました。テレビではセンセーショナルな部分のみを報道するので、やはりテレビや新聞を通した印象と実際に感じた印象は大きく違うものだなと改めて感じました。
また、あいにく筆者のいる間の天気はあまり良くありませんでしたが、雨に降られることは少なかったため、夜のウィーンを満喫することができました。食事もどれも美味しくて食べ過ぎてしまい、帰国後原子力機構の人に会ったら開口一番「太った？」と言われる有様で、現在ダイエットの計画を立てているところです。
研究の面から今回の会合について鑑みますと、同年代の研究者が核データ処理システム開発に携わっていることを知ったことが、筆者にとって非常に大きな励みとなりました。今後も彼らに負けないように、また彼らに一目置かれるように、研究生活に励んでい
きたいと気持ちを新たにすることができました。
まずは ND-2016 での開発者の方々との再会と FRENDY の正式お披露目を目標に、今後の研究を精力的に進めていきたいと思います。
最後になりますが、IAEA の大塚直彦氏には IAEA での仕事についての興味深いお話を聞かせて頂いたり、美味しいホイリゲに連れて行って頂いたりとお世話になりっぱなしでした。この場を借りて厚く御礼申し上げます。

図 5 Schwedenplatz 駅付近からドナウ運河を望む－ 22 －

図 6 シュテファン大聖堂での右派の自由党の選挙演説の様子

図 7 大塚氏お勧めのホイリゲでの食事風景－ 23 －