CDO

Hi Eric,

you have used a special character instead of a real minus sign in the following line:

xfirst   = −179.916666667

Cheers,
Uwe

I think that was probably just something that happened in the HTML when I posted the message from my system. They are standard ascii characters.

I did find that if I moved the xfirst and yfirst coordinates to match the starting of the data file (even though the data is symmetric and should be re-mappable around 360 degrees) I can get it to work.

So this works for 1/12 degree spacing:

gridtype = lonlat
xsize    = 4320
ysize    = 2160
xfirst   = 74.916666667
xinc     = 0.083333333
yfirst   = -89.916666667
yinc     = 0.083333333

However it takes hours and sometimes segment faults doing something like this

cdo remapbil,lonlat latest.nc temp1.nc

I've also tried

cdo genbil,lonlat ifile remapweights.nc
cdo remap,lonlat,remapweights.nc ifile ofile

But the remapweights.nc file is massive and this technique takes hours too. Does anyone have any ideas how to handle remapping this data faster.

Hi,

this technique takes hours too. Does anyone have any ideas how to handle remapping this data faster.

try with openmp:

e.g.

cdo -P 8 remap,lonlat,remapweights.nc ifile ofile

for more info, see https://code.zmaw.de/projects/cdo/wiki/OpenMP_support

Cheers,
J

The weight generation is parallelized with OpenMP, i.e. genbil. The remap operator uses the pre-computed weights to apply them to the old data, which basically is a matrix-vector-multiplication (= no parallelism).

rempabil uses the genbil procedure internally, that's why the '-P' switch improves performance of genbil and remapbil, but if you call remap, it will not speed up the call.

If you plan multiple interpolations, it makes sense to use genbil and store the weights separately. You could speed it more, if your input file has multiple variables. In this case, you can split the input into files for each variable (_splitname_ operator) and perform the remapping for each variable in parallel. This requires a fast IO subsystem.

Hi Ralf,

The remap operator uses the pre-computed weights to apply them to the old data, which basically is a matrix-vector-multiplication (= no parallelism).
rempabil uses the genbil procedure internally, that's why the '-P' switch improves performance of genbil and remapbil, but if you call remap, it will not speed up the call.

(just to understand a little bit more bout CDO OpenMP): how about multi-level variables? i.e., suppose the input file contains only one variable but with, say 60 vertical levels; so my question is, if I do the remap with weights, with openMP:

cdo -P 8 remap,lonlat,remapweights.nc ifile ofile

will it speed-up the remap - compared to single thread/proc ?

Cheers,
J.

Jaison-Thomas Ambadan wrote:

Hi Ralf,

The remap operator uses the pre-computed weights to apply them to the old data, which basically is a matrix-vector-multiplication (= no parallelism).
rempabil uses the genbil procedure internally, that's why the '-P' switch improves performance of genbil and remapbil, but if you call remap, it will not speed up the call.

(just to understand a little bit more bout CDO OpenMP): how about multi-level variables? i.e., suppose the input file contains only one variable but with, say 60 vertical levels; so my question is, if I do the remap with weights, with openMP:

cdo -P 8 remap,lonlat,remapweights.nc ifile ofile

will it speed-up the remap - compared to single thread/proc ?

No.

The main entity in CDO (actually CDI) is a record, which represents a single horizontal field. Theses records are read by an operator, processed and written to an output stream (a file or internal memory, which will be used as input for the next operator in the chain). In this way possibly all operators of an operator chain can run in parallel. This speeds up the whole process and limits the memory consumption (which is very important, because CDO should be able to process terrabytes of data). If OpenMP should be used to parallellize over levels, one process must read in the data for all levels and spread it over the openmp threads. For high resolution data with many levels, this could already fill your memory: Lets take a grid of 4000x2000 gridpoints with 200 levels. In double precision, this would accumulate more than 11GB, whereas a single recode (level) has only 61 MB

>> 4000*2000*200*8/(1024*1024*1024).to_f
=> 11.920928955078125
>> 4000*2000*8/(1024*1024).to_f
=> 61.03515625

If you have enough memory and a fast IO, you could split the file by level (splitlevel) and remap each level in parallel with its own CDO call ;-)

hth
ralf