FortranのためのNetCDFユーザーのガイド
NetCDFは、その抽象をサポートするインタフェースの具体的インプリメントを行うアレイ指向のデータアクセス、及び、ソフトウェアライブラリのためのデータ抽象である。そのインプリメントは、アレイを表すためにマシン‐非依存のフォーマットを提供する。netCDFファイルフォーマットがインターフェース以下で隠されているが、現在のインプリメント、及び、関連するファイル構造のいくらかの理解は、なぜnetCDFオペレーションが他のものより高価であるかを明らかにするのに役立つかもしれない。
netCDFフォーマットの詳細な記述のために、 Appendix BファイルFormat Specification、115 ページを見なさい。フォーマットの知識は、netCDFデータ、または、理解を読んで、書くために必要とされない大部分の効率問題。あらゆるそのような変更が実証されたインターフェース以下で行われるであろう、そして、netCDFファイルフォーマットの初期のバージョンをサポートするであろうので、使用のみ ( 実証されたインタフェース、及び、それがフォーマットについて仮定にしない ) が将来netCDFフォーマットが変えられるとしても、働かせ続けるであろうプログラム。
それらの名前、タイプ、及び、他の特性を含んで、ファイルの初めのヘッダは、ファイルに次元、変数、及び、属性に関する情報を含む。約各変数が含む情報、固定した‐サイズ変数のための変数のデータの初め、または、レコードの中の他の変数の相対的なオフセットに相殺しなさい。同じくヘッダは、適切なオフセットに各変数のためのマルチ‐寸法のインデックスをマップするのに必要とされる次元の長さ、及び、情報を含む。
このヘッダには、使用できる余分のスペースがない;次元、変数、及び、netCDF datasetにおける属性 ( 全ての属性の値を含むこと )
のためのものであることは、ただそれが必要とするのと同じくらい大きい。これには、netCDFファイルがそうである利点があるdatasets自己‐記述を行う付属のデータを格納するのにオーバーヘッドをほとんど必要としないで、契約しなさい。この編成の欠点は、成長する
( 〜もしくは、あまり可能性がある、収縮するために ) のにヘッダを必要とするnetCDF
datasetへのあらゆる作用、例えば加えている新しい次元、または、新しい変数がそれをコピーすることによってデータを動かすことを必要とすることである。この費用は、負われる、前のコールの後では、NF_ENDDEFは、呼ばれる、に、NF_REDEF
.あなたがデータを書く前に全ての必要な次元、変数、及び、属性を作成し、そして、netCDFコンポーネント (
ファイルのヘッダ部分において更に多くのスペースを必要とする )
の後の追加、及び、renamingsを回避するならば、あなたは、後でヘッダを変えることと関連していたコストを回避する。
ヘッダのサイズが変えられるとき、ファイルにおけるデータは、動かされ、そして、ファイルにおけるデータ値のロケーションは、変わる。他のプログラムが再定義の間にnetCDF
datasetを読んでいるならば、ファイルのそのビューは、古いおそらく誤ったインデックスに基づいているであろう。netCDF
datasetsが再定義を横断して共有されるならば、netCDFライブラリに外部のあるメカニズムは、それを供給されなければならない、再定義の間のリーダ、及び、原因によってアクセスを妨げる、呼ぶためのリーダ、あらゆる次のアクセスの前のNF_SYNC。
ヘッダの後に続く固定した‐サイズデータ部分は、無制限の次元を使わない変数のために変数データ全てを含む。各変数のためのデータは、接触している‐にファイルのこの部分に格納される。無制限の次元がないならば、これは、netCDFファイルの最後の部分である。
固定した‐サイズデータの後に続くレコード‐データ部分は、固定した‐サイズレコードの変数数から成る ( それらの各々が全てのレコード変数のためにデータを含む ) 。各変数のためのレコードデータは、接触している‐に各レコードに格納される。
netCDF変数IDによって番号順を増加する際、変数データが各データセクションに現れるオーダは、それらの変数が定義されたオーダと同じである。この知識は、最も良いデータアクセスが現在シーケンシャル順番にデータを読む、もしくは書くことによって達成されるので、データアクセスパフォーマンスを拡張するために時折使われ得る。
データのためにカノニカルな外部の表現を用いるためのコストは、データのタイプに従って変動し、そして、外部のフォームが機械と同じであるかどうかは、そのタイプのための生来のフォームである。
いくらかのデータのために、いくらかの機械上のタイプ、外部のフォームへ或いはそこからデータを変換するのに必要とされる時間は、有意であり得る。最も悪いケースは、読んでいる、もしくは、大きく書いている、アレイ、の、IEEE浮動少数点をその生来の表現として使わない機械上の浮動少数点データ。
fread ( )
、及び、fwrite ( ) に原子力によらない。書いて、NF_SYNCコールがCの標準のI/O図書館でfflushコールに類似している、成文化していない、非常に他のプロセスがそれのために読むことができるバッファされたデータ;同じくNF_SYNCは、ヘッダ変更を最新のものにする ( 例えば、属性の値に変わる )
。NF_SHAREは、stdioストリームをsetvbufに_IONBFフラグによってバッファされないようにセットすることに類似している。
stdioライブラリと同様に、「シーク」がファイルの異なるエリアに発生するとき、紅潮は、同じく行われる。従って、読まれた、そして、書込みオペレーションのオーダは、著しくI/Oパフォーマンスに影響し得る。同じ順番 ( それが各レコードの中で書かれた ) にデータを読むことは、バッファ紅潮を最小限にするであろう。
あなたは、netCDFデータアクセスが同時に書くために同じファイルを開いた状態にする多重ライタを使って作業をすると予測するべきでない。
I/O層を異なるプラットホーム‐特定のI/O層と交換することによっていくらかのプラットフォームのためにnetCDFのインプリメントを調整することは、可能である。これは、netCDF、及び、標準のI/Oの間で類似を変えるかもしれず、従って、特性は、データシェアリング、バッファリング、及び、I/Oオペレーションのコストに関係した。
分散されたnetCDFインプリメントは、携帯用であることを意味する。更に更に良いI/Oパフォーマンスのためにインプリメントを最適化するプラットホーム‐特定のポートは、いくらかの場合に実用的である。
その上、それは、更に大きいI/O効率を獲得するためのユーザーにとって可能である、適切な設定、の、NETCDF_FFIOSPEC環境変数。この変数、指定する、netCDF
I/Oのための柔軟なFile I/Oバッファ、UNICOSオペレーティングシステムの下で実行中であるとき (
その変数が他のオペレーティングシステム上で無視される ) 。適切な仕様は、netCDF
I/Oの効率を非常に増加し得る--それが越え得る程度までFORTRANバイナリI/Oを履行しない。可能な仕様は、下記を含む:
bufa:336:2
| 2、336の非同期I/Oバッファ、各 ( すなわち、バッファリングを2倍にする ) を妨害する。これは、デフォルト仕様であり、そして、シーケンシャルI/Oを支持する。 |
cache:256:8
| 8、同期256‐ブロックバッファ。これは、更に大きいランダムアクセスを支持する。 |
cachea:256:8:2
| 8 2ブロックread-ahead/write-behindを持つ非同期256‐ブロックバッファは、債券を買い取る。同じくこれは、更に大きいランダムアクセスを支持する。 |
cachea:8:256:0
| 256、read-ahead/write-behindなしの非同期8‐ブロックバッファ。これは、netCDFアレイをスライスすることに象徴されている更に多くのランダムアクセスのための先に読むことなしで多くの更に小さいページを支持する。 |
cache:8:256、cachea.sds:1024:4:1
| これは、2つの層キャッシュである。最初の ( 同期 ) 層は、メモリにおける256の8‐ブロックバッファ、層がSSD上の4つの1024‐ブロックバッファから成る第2 ( 非同期 ) から成る。アクセスが粗く任意の波におけるdatasetを経て続くとき、この計画は、よく機能する、広く2x1024‐ブロックする。 |
CRIのものにおいてサポートされたオプション/構成の全てFFIOライブラリ、このメカニズムを経て利用可能である。我々は、あなたがFFIOをそれに使うことに関する情報のためのCRIのI/O最適化ガイドを見ることが最も完全であることを勧める。このメカニズムは、同じくCRIのEIE I/Oライブラリと互換性がある。
NETCDF_FFIOSPEC変数をプログラムのI/Oパターンに合わせることは、パフォーマンスを非常に向上させ得る。2桁のスピードアップは、見られた。