Beta feedback - Torsten Schmidt

[Dave Offiler]

Beta feedbcak from Torsten Schmidt at GFZ. Torsten is implementing the BUFR encoder to provide BUFR files of CHAMP & GRACE-A RO data to DWD for injection onto the GTS.

The problems reported are all known issues. There is nothing here that requires action on the part of the Team other than to provide him with the latest packages.

{{{Torsten,

it's just to inform you that I make progress in generating bufr files, but there are still some questions.

I've now a Linux maschine (Suse Linux 10.1, X86-64bit) and I use the appropriate g95 compiler.

We've only recently got g95 to work here with the latest version (ie 2007). Previous version sof g95 compiled, but gave run time memory-related errors. These seem to have been fixed now.

Compiling the bufr library is no problem as well as the ropp_tools and ropp_io vers. 0.8 with the compiler options you suggest on your website.

V0.8 is now obsolete. Please use v0.9 from the website. In fact, you'll need ropp_tools v0.90-1 which has a profile thinner which meets Sean's requirement for interpolating BAs onto a fixed set of height levels. (Tar file attached).

Running "ropp2bufr file.dat -o file.bufr -d" goes also fine but the other direction "bufr2ropp file.bufr -o orig.dat -t -d" gives not the same results than the original data set.

BUFR does not support the same precision (decimal places) available in the original file, so the decoded file will be different in that 'diff' will find differences. This is to be expected. What matters is that the decoded values are the same as the originals _allowing for the rounding errors_.

The 'process date/time' field will also be different (the decoded value will be the time of decoding), and only a code value for the processing centre is transmitted, so the decoded processing centre will just be 'GFZ'

Attached you find the examples, whereas both dat files should have the same content, but the level 2b data are missing in the orig.dat file (and already in the bufr file) and the geopotential heights are different.

There was also a bug in encoding the POD values, which is corrected in v0.9-1.

What are the reasons?

see above! Please use only v0.9 ropp_tools and v0.9-1 ropp_io

Using the ropp vers. 0.9 causes an error by generation ropp_io:

..... g95 -I../build -Wall -O2 -I/dsk/cha64d/SOURCE/LINUX/include -c -o ropp2ropp.o ropp2ropp.f90 g95 -I../build -Wall -O2 -I/dsk/cha64d/SOURCE/LINUX/include -Ldsk/cha64d/SOURCE/LINUX/lib -o ropp2ropp ropp2ropp.o ../build/libropp_io.a -lbufr -lropp_tools -lnetcdf -ludunits g95 -I../build -Wall -O2 -I/dsk/cha64d/SOURCE/LINUX/include -c -o ropp2bufr.o ropp2bufr.f90 In file ropp2bufr.f90:162

USE CodeTables, ONLY: CT001033

1

Fatal Error: Can't open module file 'codetables.mod' at (1) for reading: Datei oder Verzeichnis nicht gefunden make[1]: * [ropp2bufr.o] Fehler 1 make[1]: Leaving directory `/dsk/cha64d/SOURCE/LINUX/download/ropp_io-0.9/tools' make: * [all-recursive] Fehler 1

How can I generate the codetables.mod? It would be great if you could give me some hints.

Someone else had the same problem last year, which I recall was a fault in a particular release of the BUFR package not generating this mod file. Could you try re-building the BUFR again using the attached zipfile?

We've also found that one of the reference files in ropp_io/data didn't get re-generated and are incompatible with the other files, so a 'make test' in that directory will show errors. Though I think running the t_roppbufr shell script will probbaly work. This does an encode + decode, and compares the output against a reference BUFR output file, _not_ the original input. Obviously this doesn't test the end-to-end correctness of code, just that the code runs without error. The values have to be checked manually.

Dave

}}}

[Dave Offiler]

All items fixed in ROPP-1 v1.10 as released.

[(none)]

Milestone 1.1 deleted