0

私はこれを理解するのに苦労しています。

次の次元と変数を使用して netcdf4 ファイルを作成します (特に無制限のpoint次元に注意してください)。

dimensions:
    point = UNLIMITED ; // (275935 currently)
    realization = 24 ;
variables:
    short mod_hs(realization, point) ;
        mod_hs:scale_factor = 0.01 ;
    short mod_ws(realization, point) ;
        mod_ws:scale_factor = 0.01 ;
    short obs_hs(point) ;
        obs_hs:scale_factor = 0.01 ;
    short obs_ws(point) ;
        obs_ws:scale_factor = 0.01 ;
    short fchr(point) ;
    float obs_lat(point) ;
    float obs_lon(point) ;
    double obs_datetime(point) ;
}

このファイルにループ内のデータを入力するPythonプログラムがあります（したがって、無制限のレコード次元-ファイルの大きさはアプリオリにわかりません）。

ファイルに入力すると、サイズは 103MB になります。

私の問題は、このファイルからのデータの読み取りが非常に遅いことです。これは、チャンキングと無制限のpoint次元に関係していると思いますか?

私はncks --fix_rec_dmnファイルを実行し、(多くの攪拌の後) サイズがわずか 32MB の新しい netCDF ファイルを生成しました (これは、含まれるデータにほぼ適したサイズです)。

これはサイズの大きな違いです。なぜ元のファイルはこれほど肥大化しているのでしょうか? また、このファイル内のデータへのアクセスは桁違いに高速です。たとえば、Python では、hs変数の内容を読み取るのに、元のファイルでは 2 秒、固定レコード次元ファイルでは 40 ミリ秒かかります。

私が抱えている問題は、いくつかのファイルに多くのポイントが含まれており、大きすぎて実行できないように見えることですncks(私のマシンはメモリが不足していて、8GB あります)。そのため、すべてのデータを固定レコード次元に変換できません。 .

なぜファイル サイズが大きく異なるのか、元のファイルを小さくして読みやすくする方法を説明できる人はいますか?

ところで、私は zlib 圧縮を使用していません (浮動小数点値を整数 short にスケーリングすることを選択しました)。

クリス

編集 私のPythonコードは、基本的に、3か月にわたる複数の個々のモデル予測ファイルから、配置されたモデルと観測データの1つの時系列ファイルを構築しています。私の予測モデルは 1 日に 4 回実行され、3 か月分のデータを集計しているため、約 120 ファイルになります。

プログラムは、各ファイルから予測期間のサブセットを抽出するため (et T+24h -> T+48h)、ファイルを連結するのは簡単なことではありません。

これは私のコードが行っていることの大まかな概算です (実際にはより多くの変数を読み書きしますが、わかりやすくするためにここでは 2 つだけ示しています)。

# Create output file:
dout = nc.Dataset(fn, mode='w', clobber=True, format="NETCDF4")

dout.createDimension('point', size=None)
dout.createDimension('realization', size=24)

for varname in ['mod_hs','mod_ws']:
    v = ncd.createVariable(varname, np.short, 
            dimensions=('point', 'realization'), zlib=False)
    v.scale_factor = 0.01

# Cycle over dates
date = <some start start>
end_dat = <some end date>

# Keeo track if record dimension ('point') size:
n = 0

while date < end_date: 
    din = nc.Dataset("<path to input file>", mode='r')
    fchr = din.variables['fchr'][:]

    # get mask for specific forecast hour range
    m = np.logical_and(fchr >= 24, fchr < 48)
    sz = np.count_nonzero(m)

    if sz == 0:
        continue

    dout.variables['mod_hs'][n:n+sz,:] = din.variables['mod_hs'][:][m,:]
    dout.variables['mod_ws'][n:n+sz,:] = din.variables['mod_wspd'][:][m,:]

    # Increment record dimension count:
    n += sz

    din.close()

    # Goto next file
    date += dt.timedelta(hours=6)

dout.close()

興味深いことに、出力サイズを期待どおりのサイズにするのNETCDF3_CLASSICではなく、出力ファイル形式を作成した場合。NETCDF4NETCDF4 の出力が肥大化しているようです。

4

3 に答える 3

1

私の経験では、レコード ディメンションのデフォルトのチャンクサイズは、その下にある netCDF ライブラリのバージョンによって異なります。4.3.3.1 の場合、524288 です。275935 レコードは、レコード チャンクの約半分です。ncks は、netCDF のデフォルトよりも適切なチャンクサイズを自動的に (ユーザーに通知せずに) 選択するため、出力はより最適化されます。これが起こっていることだと思います。http://nco.sf.net/nco.html#cnkを参照

于 2015-11-07T20:27:14.153 に答える
0

あなたの問題は、無制限の次元のデフォルトのチャンク サイズが 1 であり、膨大な数の内部 HDF5 構造が作成されることだと思います。チャンクサイズを明示的に設定することで (明らかに、無制限のディメンションでも問題ありません)、2 番目の例は空間と時間の点ではるかに優れています。

無制限の次元には HDF5/netCDF4 のチャンクが必要です。そのため、無制限の次元が必要な場合は、発見したようにチャンクのパフォーマンスについて考える必要があります。

詳細はこちら：

https://www.unidata.ucar.edu/software/netcdf/docs/netcdf_perf_chunking.html

于 2015-11-06T03:20:13.627 に答える