[次] [性急過ぎる ] [トップ ] [内容 ] [インデックス ] [ netCDFホームページ ] [ユニ‐データホームページ]
FortranのためのNetCDFユーザーのガイド
Network Common Data Form、または、netCDFは、配列形でデータを格納して、検索するためのデータアクセス機能のライブラリへのインタフェースである。配列とは、全ておなじデータ型 data types (例: 8ビットキャラクタ、32ビット整数 ) の要素から構成される n次元の (n は0、1、2、... ) 矩形の構造である。スカラ ( シンプルな1つの値 ) は、0‐次元の配列である。
NetCDFは、データをシンプルなインタフェースによってアクセスできる自己記述的でポータブルなオブジェクトの集合とみなすことをサポートするための抽象化である。データの格納方法の詳細を知らないでも、配列値は、直接アクセスできる。データに関する補助的な情報（たとえばどんな単位が使われているか）は、データとともに格納できる。一般的な、ユーティリティ、そして、アプリケーションプログラムは、netCDF datasetsにアクセスし、そして、データの指定されたフィールドを変え得る、もしくは結合し得る、もしくは分析し得る、もしくは表示し得る。そのようなアプリケーションの開発は、データの改良されたアクセス可能性につながるかもしれず、そして、配列指向のデータ管理、分析、及び、ディスプレイのためにソフトウェアの再‐ユーザビリティを向上させた。
netCDFソフトウェアは、抽象的データタイプ を実装する。それはつまり netCDF datasetにおいてデータにアクセスして、操作するための全ての操作がインタフェースによって供給されたファンクションのセットのみを使わなければならないことを意味する。データの格納法が変更されても現存するプログラムに影響を及ぼさないように、データの表現は、インタフェースを使うアプリケーションから隠されている。netCDFデータの物理的表現は、データが書かれたコンピュータから独立しているように設計されている。
ユニ‐データはC、FORTRAN、C++、及び、Perlのための、そして、様々なUNIXオペレーティングシステムのためのnetCDFインタフェースをサポートしている。そのソフトウェアは、2、3の他のオペレーティングシステムに移植され、テストされている ( アクセスを持つユーザーから各メジャーなリリースの前のこれらのシステムまでの支援に関して ) 。ユニ‐データのnetCDFソフトウェアは、その広範囲にわたる使用を奨励するために、FTPによって自由に利用可能である。
なぜ、配列指向のデータを格納するために現存するデータベース管理システムを使わないのか? リレーショナルデータベースソフトウェアは、netCDFインタフェースによってサポートされたデータアクセスの種類に適当ではない。
第1、関係があるモデルを支える現存するデータベースシステムは、データアクセスの基本単位としてマルチ‐寸法のオブジェクト ( 配列 ) をサポートしない。関係として配列を表すことは、いくらかの有益な種類のデータアクセスを厄介にし、そして、マルチ‐寸法のデータ、及び、座標系の抽象のためにサポートをほとんど与えない。全く異なるデータモデルは、配列指向のデータがその検索、修正、数学的操作、及び、具象化を容易にするために、必要とされる。
これに関係するのが、これが多目的のデータベースシステムに関する第2の問題である:大きい配列上のそれらの貧しいパフォーマンス。衛星イメージ、科学のモデル出力、及び、長期のグローバルな気象観測の収集は、組織化するための大部分のデータベースシステムの能力、及び、効率的検索のためのインデックスを越えている。
最終的に、多目的のデータベースシステムは、資源と、アクセスパフォーマンスの両方に関する有意のコストで分析、管理、及び、配列指向のデータのディスプレイにおいて必要とされない多くの設備を提供する。例えば、精巧な最新情報機能、監査跡は、フォーマットすると報告し、そして、取引‐処理のために設計されたメカニズムは、最も科学的なアプリケーションにとって不必要である。
ネットワーク‐透過 (機械に独立)
という目標のために、netCDFは XDR (eXternal Data
Representation, ftp://ds.internic.net/rfc/rfc1832.txt
を参照) によく類似した外部表現によって実装されている。この表現は、データを機種非依存のビット列に符号化できる。唯一仮定したのは、1バイトが8ビットからなり、それらが一貫して符号化・復号化されるということである。そして実装はそのような多種多様なコンピュータ上で行われている。IEEE
754浮動少数点標準は、浮動少数点データ表現のために使われる。
netCDFファイルの全体の構造は、 第9 章で述べられる、「 NetCDF File Structure、及び、Performance」、95 ページ。
フォーマットの詳細は、 Appendix BファイルFormat Specification、115 ページにおいて述べられる。しかしながら、ユーザーには、フォーマット仕様を使って netCDFファイルを読み書きするために独立した低レベルのソフトウェアを開発ないことをお勧めする。なぜなら、いつかそのフォーマットが修正されるならば、これが互換性の問題につながるであろうからだ。
netCDFのゴールのうちの1つは、大きいdatasetsの小さいサブセットへの効率的なアクセスをサポートすることである。このゴールをサポートするために、netCDFは、シーケンシャルアクセスよりむしろランダムアクセスを使う。データが読まれるオーダがそれが書かれたオーダと異なるとき、もしくは、それが異なるアプリケーションの異なるオーダにおいて読まれなければならないとき、これは、更に効率的であるかもしれない。
ポータブルの外部の表現のためのオーバーヘッドの量は、多くのファクタによって変わり ( データタイプ、コンピュータのタイプ、データアクセスの粒状を含んで ) 、そして、そのインプリメントがいかによくあったかは、それが実行されるコンピュータにチューニングした。このオーバーヘッドは、アプリケーションによって使われる全体の資源との比較において典型的に小さい。いずれにせよ、外部の表現層のオーバーヘッドは、ポータブルデータアクセスの支払いをするために、通常適正価格である。
データアクセスの効率がnetCDFを設計して、実行するとの重要な関係であったが、非能率的道でデータにアクセスするためにnetCDFインタフェースを使うことは、まだ可能である:例えば、1つの値を各々に要求する一切れのデータを要求することによって、記録しなさい。いかに能率的にインタフェースを使うかに関するアドバイスが 第9 章において行われる、「 NetCDF File Structure、及び、Performance」、95 ページ。
NetCDF配列を格納するための多目的のアーカイブフォーマットとして使われ得る。データの圧縮は、netCDF ( <例>、32ビット番号の配置の代わりに低い‐解像度浮動少数点数をコード化するために8ビット、または、16ビット整数の配置を使う ) と共に可能である。しかし、netCDFの現在のバージョンは、データの最高の圧縮を達成するように設計されていなかった。従って、netCDFを使うことは、専用アーカイブフォーマット ( 特定のdatasetsの特別な特性の知識を開発する ) より更に多くのスペースを必要とするかもしれない。
単に netCDF を使うだけでは、人間と機械のどちらにとってもデータが「自己記述的」にも有意義にもなるわけではない。変数、及び、次元の名前は、有意義であるべきで、そして、あらゆる適切な規約に適合するべきである。sensible である所で、次元には対応する座標変数があるべきである。
属性は、付属の情報を提供する際極めて重要な役割を果たす。適切な規定を使う全ての適切な標準の属性を使うことは、重要である。 セクション8.1「属性のConventions」、81 ページは、一般的なアプリケーションソフトウェアのために予約される属性 ( netCDFライブラリによって使われる ) 、及び、属性の規約を示す。
数多くのグループは、netCDFデータのためにそれら自身の追加の規定、及び、スタイルを定義した。それらを組み込む例と同様に、これらの規定の記述は、netCDF
Conventionsサイト、 http://www.unidata.ucar.edu/packages/netcdf/conventions.htmlからアクセスされ得る。
適当である所で、これらの規定は、使われるべきである。追加の規定は、ローカルな使用のためにしばしば必要とされる。同様のエリアについて他のユーザーに関心を持たせる可能性があるならば、これらは、前述のnetCDF規定サイトに提供されるべきである。
netCDFインタフェースの開発は、Unidataのニーズに関係した僅かなゴールで始まった:Unidataアプリケーション、及び、リアルタイムの気象学のデータの間の一般のインターフェースを与えるために。UnidataソフトウェアがCと、FORTRANの両方からのアクセスを持つ多重ハードウェアプラットホームで走ることを意図していたので、Unidataのゴールを達成することは、更に広い文脈において有益であったパッケージを供給する可能性を持っていた。パッケージを広く利用可能にし、そして、同様のニーズを持つ他の組織と共同で働くことによって、我々は、どちらの科学のデータアクセスのためのソフトウェアが同じ規律における他のものによってほんのめったに再使用されず、そして、規律 ( Fulker、1988年 ) の間でほとんど再使用されないことにおいてその時の現在の状況を改良することを望んだ。
重要なnetCDFソフトウェアのために使われる概念は、NASA Goddard National Space Science Data Center ( NSSDC ) で開発されたデータ‐アクセスソフトウェアについて述べた紙 ( Treinish、及び、Gough、1987年 ) で発した。このソフトウェアによって供給されたインタフェースは、Common Data Format ( CDF ) と呼ばれた。NASA CDFは、配列を格納するために抽象をサポートするために、元来プラットホーム‐特定のFORTRANライブラリとして開発された。
NASA CDFパッケージは、多くの異なる種類のアプリケーションの広い収集におけるデータのために使われた。それには、簡素性 ( わずか13のサブルーチン ) の長所、記憶フォーマット、一般性、データの論理的ユーザー見解を支持する能力、及び、一般的アプリケーションへのサポートからの独立があった。
ユニ‐データBoulderにおけるCDFでのセミナーを1987年8月に抑制した。我々は、現存するNASAインタフェースによって互換性を保っている間に、CDF FORTRANインタフェースを拡張し、Cインタフェースを定義し、そして、1つのコールと共にデータ集合体のアクセスを可能にするために、NASAと共同で働くことの可能性を探究することを提案した。
独立して、Mining、及び、TechnologyのニューメキシコInstituteのデーブ・レイモンドは、配列指向のデータ、及び、データを処理して、分析して、表示することへの「pipes and filters ( or data flow ) 」アプローチを自己‐示すことへのシーケンシャルアクセスをサポートしたUNIXのためのCソフトウェアのパッケージを開発した。C-Based Analysis、及び、Display System ( CANDIS ) に後で変えられて、同じくこのパッケージは、「Common Data Format」名前を使った。レイモンドのもののうちで学問的なユニ‐データは、機能する ( レイモンド、1988年 ) 、そして、指定された次元の使用のようないくらかの彼のアイデア、及び、1つのデータオブジェクトにおける様々な形を持つ変数を組み込んだ ( Unidata netCDFインタフェースに ) 。
1988年初頭に、UnidataのGlenn Davisは、階層オンXDRであったCでプロトタイプnetCDFパッケージを開発した。このプロトタイプは、一列縦隊、CDFインタフェースのXDR‐ベースのインプリメントが受け入れられるコストで達成されるであろうということ、そして、その結果生じるプログラムがUNIXと、VMSシステムの両方上で実行されるであろうということを証明した。しかしながら、同じくそれは、所望の一般性との小さく、ポータブル、そして、NASAのCDF‐互換性があるFORTRANインターフェースを与えることが実用的ではないことを論証した。NASAのCDF、及び、UnidataのnetCDFは、別々にその後発展した。しかし、最近のCDFバージョンは、多くの特性をnetCDFと共有する。
1988年初頭、SeaSpace社のJoe Fahle。( サンディエゴ、カリフォルニアの商業ソフトウェア開発会社 ) 、1987年Unidata CDF作業場への参加者は、NASA CDFインタフェースをいくらかの重要な方法 ( Fahle、1989年 ) へ拡張したCでCDFパッケージを独立して開発した。レイモンドのパッケージのように、SeaSpace CDFソフトウェアによって、無関係の形を持つ変数は同じデータオブジェクトに含まれることが可能になり、そして、一般的な形のマルチ‐寸法の配列へのアクセスを可能にした。Fahleのインプリメントは、中間の形のそれらのイメージ‐処理システムにおける様々なステップのための記憶装置としてSeaSpaceに使われた。このインタフェース、及び、フォーマットは、Terascanデータフォーマットに続いて発展した。
Fahleのインタフェースを研究した後で、我々は、それが多数の問題 ( 我々がNASAインターフェースを我々の目的に拡大解釈しようとする際確認した ) を解決すると結論を下した。1988年8月に、我々は、Unidata netCDFインターフェースについて同意し、そして、残っているオープン問題を解決するために、小さいセミナーを召集した。出席する、SeaSpaceのJoe Fahle、アップル ( NASA CDFソフトウェアの著者 ) のMichael Gough、マイアミ ( VMSで我々のプロトタイプnetCDFソフトウェアを実行し、そして、潜在的なユーザーであった人 ) 大学のエンジェルLi、及び、Unidataシステム開発スタッフであった。いくらかの更なる単純化が発見された後で、合意は、作業場でされた。Glenn Davis、及び、Russ Rewがソフトウェアの最初のバージョンを実行する前に、作業場の結果を提案されたUnidata netCDFインタフェース仕様に組み込むドキュメントは、大いにコメントのために分散された。他のデータ‐アクセスインタフェースとの比較、及び、netCDFを使う経験について、Rew、及び、デービス ( 1990a ) 、Rew、及び、デービス ( 1990b ) 、Jenter、及び、Signell ( 1992年 ) 、及び、ブラウン、Folk、Goucher、及び、Rew ( 1993年 ) において論じられる。
1991年10月に、我々は、netCDFソフトウェアディストリビューションのバージョン2.0を発表した。Cインタフェース
( 次元の長さをintよりむしろ長いと宣言すること
) へのわずかな修正は、MS-DOSコンピュータのような安いプラットホームでnetCDFのユーザビリティを向上させた
( 他のプラットホームで再‐コンパイルを必要とせずに
) 。インタフェースへのこの変更は、関連するファイルフォーマットに変更を必要としなかった。
netCDFバージョンからレコードへの1993年6月に守られた同じファイルフォーマット、しかし、加えられた1つのコールアクセス、非接触しているデータ、非接触しているデータ ( 使用することが、配列セクションをマップした ) にアクセスする指定された次元 ( ストライドを使うこと ) に沿った二段抽出、ncdumpへの改善を包含する断面にアクセスするための最適化における2.3を解放し、そして、ユーティリティ、及び、実験的C++インタフェースをncgenしなさい。
1996年2月にリリースされるバージョン2.4において、サポートは、新しいプラットフォームのために、そして、C++インタフェースのために加えられ、そして、有意の最適化は、スーパーコンピュータアーキテクチャのために実行された。
ファン ( File Array Notation )
、高水準のインターフェースをnetCDFデータに与えるソフトウェアは、1996年5月に利用可能にされた。netCDF配列から選択されたデータをプリントして、FANユーティリティの能力は、netCDF
datasetsから配列データを抽出して、操作することを含む。ASCIIデータをnetCDF配列にコピーしている、そして、netCDF配列に対する様々な手術
( 和、平均、max、min、製品、... ) を行っている。FANに関する更に多くの情報は、FAN
Utilitiesドキュメント、 http://www.unidata.ucar.edu/packages/netcdf/fan_utils.htmlから利用可能である。
このユーザーズガイドは netCDF 3 の 1997年1月のリリースについて説明する 。それは、初期のバージョンと同じファイルフォーマットを守る、しかし、バージョン2.4からいくらかのメジャーな変更を含む:
netCDFデータモデルは、指定された属性を持つ指定された配列変数の収集に組織されていることができるような幅広いデータに適用できる。しかし、ソフトウェアにいくらかの重要な制限がモデル、及び、そのインプリメントにある。いくらかのこれらの制限は、netCDFが具体化する矛盾する要求の間でトレード・オフにおいて生まれつきである。しかし、我々は、ソフトウェアの次のバージョンにおける他の制限を扱うつもりである。
現在、netCDFは、限られた数の外部の数値データタイプを提示する:8、16、32ビット整数、または、32ビット、または、64ビット浮動少数点番号。サイズのこの限られたセットは、データをビットフィールドにパックすると比べると無能にファイルスペースを使うかもしれない。例えば、9ビット値の配置は、16ビットの短い整数に格納されなければならない。1ビット、または、2ビット値の配置を8ビット値に格納することは、本当にあまり最高ではない。
に関して、わずかデータの2ギガバイトの現在のnetCDFファイルフォーマットは、1つのnetCDF datasetに格納され得る。この制限は、現在ファイルの中にポジションを格納するために使われる32ビットオフセットの結果である。
別のもの現在のモデルの制限は、わずか1つの無制限の ( 可変性の ) 次元が各netCDFデータセットのために可能にされることである。多重変数は、無制限の次元を共有し得る。しかし、それから、それらは、全て共に成長しなければならない。従って、netCDFモデルは、いくらかの無制限の寸法、及び、同じdatasetの中の異なる変数における多重の無制限の次元の使用と共に変数を可能にしない。従って、非矩形の形 ( 例えば、ぼろぼろの配列 ) を持つ変数は、都合よく表されることができない。
データが完全に自己‐述べ得るエクステントは、制限される:常にシェアリング、及び、アーカイビングデータが実用的でないであろういくらかの仮定した文脈がある。NetCDFは、変数、次元、及び、属性のために蓄えている有意義な名前を可能にする;計算に使われ得るフォームにおける施策のユニット;全体のデータセットに適用される属性の値のためのテキストストリング;そして、シンプルな種類の座標系情報。更に複合的な種類のmetadata ( 例えば、異常なグリッド上で、もしくは、衛星イメージからデータの正確なgeoreferencingを供給するために必要な情報 ) がなければ、会議を発展させることは、しばしば必要である。
netCDFデータモデルへの特定の追加は、いくらかのこれらの規定を不必要にする、もしくは、いくらかの形のmetadataが一定の、そしてコンパクトな方法の代表を務めることを可能にするであろう。例えば、明白なgeoreferencingをnetCDFデータモデルに加えることは、モデルを複雑にすることを犠牲にして精巧なgeoreferencingしている規定を単純化するであろう。その問題は、モデルの豊富、及び、その一般性 ( すなわち、多くの種類のデータを包囲するその能力 ) の間で適切なトレード・オフを見い出している。1つの規律の中で研究者の間の共有された文脈を獲得するために、作成されたデータモデルは、多重規律からデータを共有する、及び結合することに適していないかもしれない。
netCDFデータモデルは、木のようなネストしたデータ構造をサポートせず、主として、現在のFORTRANインタフェースが読むことができなければならないので、配列、または、他の再帰的構造をネストさせ、そして、あらゆるnetCDFデータセットを書いた。不正、及び、規定の使用によって、いくらかの種類のネストした構造を表すことは、可能である。しかし、その結果は、データを自己‐示すことのnetCDFゴールに達しないかもしれない。
最終的に、現在のインプリメントは、同時に起こるアクセスをnetCDF datasetに制限する。1つのライタ、そして、多重リーダは、1つのdatasetにおいてデータに同時にアクセスするかもしれない。しかし、多重の同時に起こるライタへのサポートがない。
計画は、透過データパッキング、改良された共同‐通貨サポート、及び、2 Gigabytesより大きいdatasetsにアクセスする能力を加えることである。加えられるかもしれない ( 実用的であるならば ) 他の望ましい拡張は、キー、または、対等の値、効率的な構造変更 ( <例>、新しい変数、及び、属性 ) へのサポート、他のdatasetsにおけるデータ断面へのポインタへのサポート、ネストした配列 ( ぼろぼろの配列、木、及び、他の再帰的データ構造の許している表現 ) 、及び、多重の無制限の次元によってデータへのアクセスを含む。
[次] [性急過ぎる ] [トップ ] [内容 ] [インデックス ] [ netCDFホームページ ] [ユニ‐データホームページ]