Table D sequence for reporting scatterometer data from CFOSAT

[erget]

Branch

https://github.com/wmo-im/BUFR4/tree/issue-12

Summary and purpose

New Table D sequence for the reporting of scatterometer data from CFOSAT

Action proposed

The meeting is requested to review and approve the contents of this proposal for implementation within the second 2020 fast-track (FT2020-2) update to the WMO Manual on Codes.

Discussions

Developed jointly by Centre national d'études spatiales (CNES) and the China National Space Administration (CNSA), the CFOSAT satellite carries two radar instruments: SWIM (Surface Waves Investigation and Monitoring), a wave scatterometer supplied by CNES for measurements of wave properties (direction, wavelength, etc.) and SCAT, a wind-field scatterometer supplied by CNSA for measurements of ocean surface wind vectors. The CFOSAT satellite was successfully launched on 29 October 2018 to a sun-synchronous orbit, with descending node crossing time at 07:00 and an altitude of 519 km.

The CFOSAT mission allows more accurate ocean forecasts and earlier warnings of severe weather events like storms and cyclones. CFOSAT also helps climatologists to learn more about air sea interactions which play a key role in climate.

The wave scaterometer, SCAT, is a Ku-Band (13.256 GHz), rotating fan beam scatterometer, with dual polarisation, HH and VV and a swath of 1000 km. For the rotating fan beam scatterometer there can be up to 18 sigma0 views per wind vector cell, as opposed to a maximum of 4 for pencil beam instruments. In order to standardize the BUFR encoding of these data, a new Table D sequence is proposed (3-12-034). The new sequence is essentially the same as the entry used for SeaWinds BUFR data (3-12-028) as far as the first parts containing general information, location/time information, wind information and brightness temperature information. The only difference is that in the last part the SeaWinds entry contains only 4 place holders for sigma0 views, whereas the CFOSAT entry contains 18 place holders.

Detailed proposal

Add new entry 3-12-034 "CFOSAT scatterometer data" to BUFR Table D:

Table references	Element name
3-01-046	Satellite identifier, direction of motion, sensor, model function, software, resolution
3-01-011	Year, month, day
3-01-013	Hour, minute, second
3-01-023	Latitude/longitude (coarse accuracy)
0-08-025	Time difference qualifier
2-01-136	Change data width
0-04-006	Second
2-01-000	Change data width
3-12-031	Scatterometer wind
3-12-032	Scatterometer precipitation
1-01-004	Replicate 1 descriptor 4 times
3-12-030	Wind, formal uncertainty, likelihood
1-01-002	Replicate 1 descriptor 2 times
3-12-033	Antenna polarization, brightness temperature
1-03-018	Replicate 3 descriptor 18 times
0-21-110	Number of inner-beam sigma-0 (forward of satellite)
3-01-023	Latitude/longitude (coarse accuracy)
3-21-028	Radar specification, normalized radar cross-section, Kp variance coefficient

The meeting is requested to review and approve the contents of this proposal for implementation within the second 2020 fast-track (FT2020-2) update to the WMO Manual on Codes.

[chenxiaoxia2019]

@erget Hi, Daniel, I have created a branch for this issue. Could you please check it? Many thanks.

[SimonElliottEUM]

@chenxiaoxia2019 @erget Here are the sample data.

rfsca_20200603_011216_cfosat_08832_o_500_ovw_l2.zip

[SimonElliottEUM]

@chenxiaoxia2019 @erget Please note that the sample data were created by KNMI with ECMWF software bufrdc_000405. This means that any other software can be used for the validation

[efucile]

@SimonElliottEUM @erget the Secretariat is not performing validation. You have to ask someone else. @marijanacrepulja or @marianmajan-ibl are you available to validate these data?
Validation should be performed using the tables in txt or xml format from the branch https://github.com/wmo-im/BUFR4/tree/issue-12

[marijanacrepulja]

@efucile @SimonElliottEUM @erget
Yes, I am happy to validate the sample data.
Would it be OK to attach the validation output file here? I will use the tables in txt from the branch issue-12.

[SimonElliottEUM]

@marijanacrepulja Many thanks - I'm sure you can dump the output here. @efucile I wasn't expecting the Secretariat to do the validation. Sorry you got that impression. I was trying to explain that any validation partner would have to avoid using bufrdc_000405. @erget I will let you do the typing next time

[david-i-berry]

First message from example file decoded, two versions attached. One with flags as ints, the second as bit strings. Comma separated values, one element per line working through subsets (subset 1 then subset 2 etc).

Table D from branch used in decoding with custom python code.

cfosat_dump_flags_as_bin.txt
cfosat_dump_flags_as_int.txt

[SimonElliottEUM]

@erget KNMI confirm that what @DavidBerryNOC has decoded corresponds exactly to what they encoded. We (ie you!) should formalise that validation result. Or you can explain to me how to do it.

[erget]

As far as I know we have no formal process for producing validation reports - changing the tag as you have done is probably the right thing.

[erget]

I have checked the associated branch and it looks fine for me.

[marijanacrepulja]

Table D from branch used in decoding with ecCodes. The dump of the first 5 messages attached.
cfosat.bufr.txt

[SimonElliottEUM]

@erget @efucile With the successful decoding by @marijanacrepulja and the previous validation by @DavidBerryNOC we can consider the validation complete. Our thanks to @marijanacrepulja and @DavidBerryNOC for their support

[amilan17]

Approved by FT 2020-2.