Frequently Asked Questions

This page answers questions that are sometimes asked by AAPP users. They may be only indirectly related to AAPP, therefore are not appropriate for the main AAPP documents.

Questions for other users and developers can be posted on the AAPP Forum or you can contact the developers via the Helpdesk.

1. What are the requirements for running AAPP?

   • Supported platforms: UNIX or Linux platforms, 32-bit or 64-bit.
   • User knowledge: the user needs to have a basic knowledge of UNIX or Linux command-line operations and scripting, e.g. navigating directories, file handling, use of environment variables, setting up scripts to process data automatically. Administrator privilege is not normally needed.
   • Software requirements: KORN shell, FORTRAN 77 or FORTRAN 90 compiler, C compiler, make, gunzip, gzip, tar, perl5. The optional OPS-LRS (for IASI processing) also requires a C++ compiler and support for posix threads.
   • To make use of the full functionality of AAPP, you will need to install various external packages (e.g. ECMWF BUFR library and the HDF5 library). For details, please see the Installation Guide.
   • Disk space requirements: the AAPP/OPS-LRS software and data files occupy about 9GB of disk space (or 4GB if you don’t need to run MAIA4, the VIIRS cloud mask).
   • Memory requirements: there are no special requirements to run the core parts of AAPP (e.g. ATOVS/AVHRR processing). IASI processing requires at least 2GB of memory, but runs faster on systems with more memory, because more threads can be used. We recommend at least 6GB.
   • Distribution policy: distribution is free of charge to anyone who agrees to the licence conditions contained in the Licence Agreement.

2. Where can I find out about other level 1 processing packages?

   The ITWG Working Group on Products and Software maintains a list at http://cimss.ssec.wisc.edu/itwg/pswg/software_packages.html. This also provides some tips (in an appendix) about working with raw data in CADU format.

3. Is it possible to run AAPP in a Container?

   We are grateful to Liam Gumley for providing instructions on building AAPP in a Singularity container.

   Note that the workflow below is designed to be run by an ordinary (i.e., non-root) user. The only special requirement is that the user must have sudo permission to build the Singularity container. No special permissions are require to test or deploy the Singularity container.

   1) Download the README and tar files from https://bin.ssec.wisc.edu/pub/gumley/aapp_singularity/v2/ into a new directory of your choice
   2) Unpack the tar files
   3) Read the top-level README and follow the instructions

4. How can I produce quick-looks from raw AVHRR data (CADU or HRPT)?

   If you are working with Metop data in CADU format, you can use the cadu_to_ccsds and ccsds_displayer tools that are part of EUMETSAT’s Metopizer software. Use the –image-avhrr option of ccsds_displayer to produce output in tiff or jpeg. These images are unprojected.

   if you are working with NOAA HRPT data, we are not aware of a ready-made display tool, but you can make your own (e.g. in Python or IDL) bearing in mind that the HRPT format is simple: the frame length is 11090 words and the raw AVHRR data are in words 751 to 10990 (5 channels x 2048 pixels). A word is 10 bits as it comes down from the satellite, but front-end systems often unpack this for you to give 16-bit words.

5. How can I use local BUFR tables with ecCodes and/or Metview?

   The AAPP level 1d BUFR formats use local BUFR tables, which are included as an AAPP data file. These formats are not intended for international exchange, but they are used (for example) by UM partners. For running ecCodes utilities such as bufr_dump and bufr_filter, you can set the following environment variable:
   export ECCODES_DEFINITION_PATH=$AAPP_PREFIX/AAPP/data/tools_eccodes/definitions:$(codes_info -d)

   In recent versions of ecCodes, ECCODES_DEFINITION_PATH does not need to include the default location.

   Level 1D BUFR files can be visualised directly in Metview if you first define the evironment variable:
   export METVIEW_EXTRA_GRIB_DEFINITION_PATH=$AAPP_PREFIX/AAPP/data/tools_eccodes/definitions

6. Where can I find information about the MAIA cloud mask?

   The MAIA cloud mask is described in the following presentations: presentation about MAIA from CSPP meeting 2017, presentation about VIIRS to CrIS mapping from CSPP meeting 2015 and poster about VIIRS to CrIS mapping from ITSC22 in 2019.

   Real-time images, including cloud mask, can be found on the Meteo-France web site.

7. Why are there sometimes time stamp inconsistencies between AAPP processing and NOAA level 1B?

   For NOAA POES satellites, the operational NOAA level 1B processing includes a clock drift correction – see section 2.3 of the NOAA KLM Users Guide. The NOAA clock correction files are linked from the NOAA OSPO Polar Navigation page.

   By default, when using TLE bulletins for navigation, AAPP does not use a clock correction for NOAA POES, it just takes the raw time stamps, and these are normally accurate to ~0.5 second. For greater precision you could modify the (normally empty) clock error files in AAPP/orbelems/tle_db/clkerr_*.txt. For example, an entry for NOAA-19, designed to match the NOAA correction in May 2023, could contain

   last 26790   0.516  08/05/23

   Note that the second column is day number since 1st January 1950. AAPP will ignore any entries that are more than 60 days before the time of the data being processed.

   In the past, TBUS bulletins were used to adjust the AAPP clock error files, but examination of the current TBUS bulletins from NOAA shows that the clock corrections are not up to date.