CDO

Hi Christian,

If you could upload a sample of your data, that would be great; it may help the CDO guys here to identify the problem a bit faster! If the file size is > 50MB, you may select a very small geographical region (1 or 2 time & levels) using "cdo -sellonlatbox".

Cheers,
J.

Hi again,

just one doubt: are you able to reproduce the problem with some other data sets? say for example:

cdo -f nc -selindexbox,10,20,10,20 -random,r360x180 outfile.nc

Cheers,
J.

Dear Jason-Thomas,

thanks a lot for taking your time.

I have attached the global tsurf-field (2D, one time step) that has been used for the generation of the "buggy" lon-lat-selection as illustrated above. There is no magic about this file, it is just a common tsurf output of a coupled cosmos-aso simulation that has been retrieved via standard post-processing.

As a reply to your last answer: Yes, I have tried another model output file of a different simulation. The result on the solaris server is the same - the NaN-pattern persists, and this is true for all contained 2D- and 3D-variables (resulting netcdf attached as well). The selindexbox on a random field though does not lead to the NaN problem (netcdf attached as well).

I was just playing a little around with selecting different regions - and I can show that the occurrence of NaN cells also depends on the selected region:
selindexbox,81,92,2,8 -> NaN pattern
selindexbox,80,92,2,19 -> NaN pattern
selindexbox,80,92,5,34 -> no NaN pattern
selindexbox,1,90,2,8 -> no NaN pattern
selindexbox,1,48,2,34 -> no NaN pattern

That all looks very strange to me. If I can help with any additional information, please do not hesitate to ask.

Christian

Hi Christian,

Unfortunately I do not have a definite answer for this problem. Since you get the correct results with random numbers, my gut feeling says the problem has to do with the NetCDF attributes related to the _Fill/missing values of the variables (although it is not necessary that the data has missing values). But still the question remains why it gave correct result on the other platform (probably it has to do with NetCDF versions)

Nevertheless, I have few suggestions:

It seems that you have merged two original ECHAM GRIB data and then converted NetCDF.

1. First I would say try the same (selindexbox) without converting to NetCDF, on Solaris and convert the file in the other platform - if you get the correct result the definitely it is the NetCDF library on Solaris

2. On Solaris, before merging the files, it might be better if you set the missing value attribute, and then convert to netcdf, i.e.

cdo -f nc -merge -setmissval,-9999.9 file01.nc -setmissval,-9999.9 file02.nc outfile.nc

then do the next step "selindexbox"

3. OR you may try the "setmissval" before "selindexbox" on your existing merged input file.

I'm nor sure if this helps, may be Uwe or Ralf can give you more info/help.

Cheers,
J.

Hi Jaison-Thomas,

I will try those procedures - thank you very very much for your help. In case the procedures don't work, I will get back to you, Uwe or Ralf.

Cheers,
Christian