NOTE: The bufrtables mailing list is no longer active. The list archives are made available for historical reasons.
Dear Jeff,I am not sure, but I think we discussed this during our last meeting when Eva end people doing radiation find the problem.
I checked bufr regulations and there is nothing which state that we can not have different content in the different tables (different master table version number). What we always kept firm is that once the entry is in the particular version it can not be changed which is logical. In the Bufr Manual we have under Note 5 list of different tables and dates of implementation.
What happens in practice is even more complicated. The data are coming in many different master table version numbers from 2 to 13 and usuallythe local version number is used although there is no local entries. So data processing centres must have many tables to be able to process data although WMO maintains and keep the latest. Data producers should pay more attention on this issue.
In the past we had the case when the content of the tables was changed. That was from version 0 or 1 to 2 for class 13 elements where units were changed to SI units and consequently scales and in one case data width.
I propose that we discuss this issue again at the next Meeting. Best regards Milan Milan Dragosavac ECMWF Shinfield Park, Reading, Berkshire, RG2 9AX, UK Tel: (+44 118) 949 9403 Fax: (+44 118) 986 9450 Telex: 847908 ECMWF G E-mail: milan.dragosavac@xxxxxxxxx Jeff.Ator@xxxxxxxx wrote:
Dear Eva and Milan, I must admit I'm confused now. While I certainly agree that it's possible, and perhaps even preferable, to be able to change the characteristics of an existing descriptor when a table version number is incremented, I don't recall that we ever formally agreed to adopt this as the new practice. Eva, I have read your 3.1.1(1) document, and I do recall when we previously discussed the problems of these particular radiation descriptors; however, I don't recall (nor do I see any mention in the final reports from any of our previous meetings?) where we agreed to this change in practice. As you mentioned, in the past we've always kept existing descriptors frozen and just deprecated and replaced them with new descriptors whenever subsequent problems were discovered. And while I certainly remember past instances where we've discussed the shortcomings (e.g. Table B classes rapidly filling up) of this type of approach, I just don't remember where we ever formally agreed to change it. I apologize if my memory on this point is faulty, and if that is the case could you please point me (and the rest of this mailing list as well!) to any relevant documentation? Personally, I have no problem with allowing descriptor characteristics to change between table versions. I do think it is workable and has several benefits, which is probably why I didn't object if/when we did previously agree to this as a group. In my below email I was only trying to describe the current policy (at least as I understood it) to my colleagues on the mailing list. As you mentioned, the big issue involved with changing this would be that the Secretariat would now have to maintain all of the old versions of the tables (and in a machine-readable format! :-) somewhere on the WMO web server. Assuming Joel is agreeable to that, then I believe the majority of my colleagues here in the U.S. would agree to it as well. Thanks and best regards, -Jeff
bufrtables archives: