Processing of MetOp level1b dataset

[Salvatore Larosa]

Hello,

I successfully built an instance of AAPP (8.4) using a Singularity container (4.1.0) on CentOS 7. Everything was installed properly, and the test case reported here worked perfectly—great!

Now, I would like to process the MetOp level 1b data that I downloaded from the EUMETSAT Datastore. The datasets I downloaded are:

AMSA_xxx_1B_M03_20231001120122Z_20231001134026Z_N_O_20231001133657Z.bin
IASI_xxx_1C_M03_20231001115954Z_20231001133858Z_N_O_20231001133835Z.nat
MHSx_xxx_1B_M03_20231001120050Z_20231001133949Z_N_O_20231001133613Z.bin
AVHR_xxx_1B_M03_20231001120103Z_20231001134003Z_N_O_20231001133739Z.nat

The .bin files are in BUFR format, while the .nat files are in EPS Native format.

Following the instructions in the User Guide (paragraph on EPS level 1b/1c), I downloaded the AMSU and MHS files in BUFR format, while the IASI file is in EPS Native format. I understand that these files need to be converted into .l1c format.

My task is to collocate the radiance data from AMSU-A, MHS, and IASI onto the IASI grid to get a level 1d dataset. However, when I run the command:

AAPP_RUN_METOP -b -d <dir_level1c> -o <work_dir> -i "AMSU-A MHS IASI AVHRR" -g "IASI"

I get the following error message:

> 2025/01/10 16:03:51 localhost.localdomain 67721 AAPP_RUN_METOP INFO      : Working directory is /mnt/work
> 2025/01/10 16:03:51 localhost.localdomain 67721 AAPP_RUN_METOP INFO      : Input directory is /mnt/level1b
> 2025/01/10 16:03:51 localhost.localdomain 67721 AAPP_RUN_METOP 
> 2025/01/10 16:03:51 localhost.localdomain 67721 AAPP_RUN_METOP ERROR     : aman.l1b missing or empty
> 2025/01/10 16:03:51 localhost.localdomain 67721 AAPP_RUN_METOP 
AAPP_RUN_METOP ended: output in /mnt/level1

Am I missing any steps? Could you please provide some guidance?

Thank you!

Salvatore

• This topic was modified 1 month, 1 week ago by Salvatore Larosa.

[Nigel Atkinson]

Sorry, I didn’t see this message originally. The AAPP_RUN_METOP script is strictly for level 0 input. Instead you need to decode the BUFR files:

eccodes_decodebufr_1c -i AMSA_xxx_1B_M03_20231001120122Z_20231001134026Z_N_O_20231001133657Z.bin
eccodes_decodebufr_1c -i MHSx_xxx_1B_M03_20231001120050Z_20231001133949Z_N_O_20231001133613Z.bin

For IASI, you could have obtained BUFR files too, but we can work with the “.nat” files:

convert_iasi1c IASI_xxx_1C_M03_20231001115954Z_20231001133858Z_N_O_20231001133835Z.nat

Create links:

ln -s AMSA_xxx_1B_M03_20231001120122Z_20231001134026Z_N_O_20231001133657Z.l1c aman.l1c
ln -s MHSx_xxx_1B_M03_20231001120050Z_20231001133949Z_N_O_20231001133613Z.l1c ambn.l1c
ln -s IASI_xxx_1C_M03_20231001115954Z_20231001133858Z_N_O_20231001133835Z.nat.l1c iasi.l1c

Then it should be possible to run atovpp:

atovpp -i “AMSU-A MHS IASI” -g IASI

At least, I think it should work. These are full-orbit files; most near-real-time applications use direct broadcast data or 3-minute granules.

Nigel

[Salvatore Larosa]

Hi,

Thank you for your response.

I created the symbolic link for the *.l1c files after converting the BUFR and native files, and I ran the following command:

atovpp -g "IASI" -i "AMSU-A MHS IASI"

This process created an “iasi.l1d” file; however, I noticed some errors in the atovpp.log, and I’m uncertain if the process completed successfully.

It appears that some blocks of the input file were not processed. You can view the plot of the iasi.l1d output here and the input file used in atovpp at this link. The *.l1d product seems to be only partially processed.

I would greatly appreciate any insights or suggestions you may have to solve this issue.

Thank you!
Salvatore

[Author]

Posts