Sea Flux

Latent Heat Flux From Satellites at the Air-Sea Interface: A Nine Year Dataset

People : D. Bourras, Laurence Eymard, W. T. Liu and G. Reverdin, Cyrille André, Kristell Dever, Jose Lopez, C. Thomas


Description of the dataset:

This web page describes a product of latent heat flux (in W/m2) derived from a combination of instantaneous SSM/I-F14 brightness temperature (TB) measurements and AVHRR SSTs (pathfinder SSTs, 'best SST' product). Because AVHRR SSTs are not available when clouds are present, we found useful to create two flux products : one that uses daily AVHRR SSTs, and another based on 8-day (7-day after 2002) averaged AVHRR SSTs. Data are available from 1 March 1997 to 30 April 2006 at five time scales, namely 7-year, 1-year, 1-month, 8-day (week number 1 corresponds to days of year 1 to 8, week 2 to days 9 to 16, ...), and 1-day periods. Other time periods (3-day, 5-day, 7-day, or 10-day, for instance) can be made available upon request. Spatial resolution is 0.3° x 0.3°, that is each global field has 1140 x 570 pixels.
The algorithm used is a based on an artificial neural network described in Bourras et al. (2002a).
Missing data were set to zero. There are no negative latent heat flux estimates.
The neural network was applied to every combination of instantaneous SSM/I-TB and 1-day or 8-day AVHRR-SST. Next, the flux estimates were averaged on 0.3°x0.3° grids. In addition to the flux averages, we included two other types of grids corresponding to the LHF standard deviation (in W/m2), and the number of points per pixel.



Warning: this an experimental product

At this time, and to the best of our knowledge, there is no method for deriving accurate LHF from satellite data. The accuracy of the present flux estimates should be 15 to 35 Wm-2 in rms according to 'instantaneous' comparisons with moored buoy data (Bourras 2006) or ship data for several experiments (Bourras et al. 2002, Bourras et al. 2003). However, biases were noticed, sometimes larger than 50 Wm-2 depending on the experiment, because of the poor sensitivity of the SSM/I to near surface specific humidity and surface atmospheric boundary layer stability.
The flux users should also be informed that the neural network algorithm is very sensitive to the liquid water content in the atmosphere. A cutoff value of 0.15 kg/m2 was applied. Beyond this threshold, no flux is calculated. However, it is an empirical choice, which means that the flux estimates may be biased below the threshold. This sometimes result in spatial artifacts that are clearly visible on the flux fields, at the location of cloud bands.
The learning of the neural network algorithm is based on a, let us say ugly, combination of ECMWF analyses, in situ observations, and SSM/I data. This approach was selected after a number of attempts because it gave the best performance. For instance, attempts to build an algorithm with only in situ data, or radiative transfer models were unsuccessful because on one hand, in situ data are sparse and were obtained from heterogeneous sets of instruments and with different methods, and on the other hand radiative transfer models were not up to the task, especially in terms of surface emissivity. Overall, we advise the reader to be careful before interpreting the structures on the latent heat flux fields. However, we found several times already that the present flux product was a valuable tool for studying air-sea interactions (e.g. Bourras et al. 2004; see also the comparisons with NCEP, TAO, and ECMWF on this site), that is why we eventually made it publicly available.
The SSM/I orbit files contain bad data that were not always flagged. They are clearly visible on the flux fields as arcs that are not correctly located. No efficient algorithm was found to remove them automatically. As a result, a supervised quality control of each orbit was applied. The user is aware that some of the bad data may not have been removed.



What do I see on the LHF fields?

It depends on the averaging period:


  • Daily fields: they are a blend of night and day flux estimates. With these fields, you can check the location of the flux structures and clouds. However, you should be careful in the interpretation of the data, because there are two to four points per day maximum, with a time lag of 12 hours. The daily fields should be useful for analyzing the long term variations of the flux.
  • 8-day fields. At this timescale, synoptic atmospheric systems are smoothed, and the number of points becomes sufficient for filling almost entirely the oceans. However, the number of points per pixel is still small, and real flux structures will appear as wavy shapes, which just reveal the superimposition of the SSM/I and AVHRR orbits.
  • Monthly and yearly fields. They should represent well the monthly and yearly flux averages. Please, note however that :


    • Flux fields based on daily and weekly AVHRR SSTs are sometimes quite different (see below).
    • There is probably a meridional bias in the flux estimates, because the algorithm implicitly accounts for a constant vertical profile of humidity.
    • Clouds are often encountered at the same locations, broadly speaking. It would be surprising if it had no consequence of the representativeness of the monthly and yearly flux fields. Please check the monthly and yearly fields of number of points.

Which flux product should I use ? daily or 8-day AVHRR SSTs ?

For convenience, let us call the two flux products Flux-day and Flux-8day products in the following.
In theory, the Flux-day product is the best, because the mesoscale SST may vary considerably in a period of 8 days, in areas of strong surface current or in case of strong meteorological events, among others. However, the answer is not so simple. For daily fields, the number of available Flux-day estimates is often too small for rendering the flux structures. The same problem occurs with the 8-day Flux-day product. For the monthly and yearly products, the number of points is no longer a problem. However, the effect of "stationary" clouds affects more the Flux-day than the Flux-8day product.
Last point, the shape of the monthly and yearly flux structures are more blurry in the Flux-8day product. Note also that these structures have different values depending on the AVHRR time averaging period. Indeed, the time period used for averaging the AVHRR SST (1-day or -day) acts on the flux averages as low pass filter: a mesoscale structure of large Flux-1day monthly fluxes will turn into a uniform structure of large Flux-8day monthly fluxes, resulting in a flux increase.
Overall, unless the user knows what he is looking at, we would recommend using the Flux-8day product.

Known problems

  • Bad SSM/I orbits were more frequently encountered in September to December. As a result, the number of points is smaller at this time of the year. This could affect seasonality.
  • Because of a change in the JPL-PODAAC AVHRR Pathfinder SST products, 8-day SSTs were replaced with 7-day SST products, as of 1 January 2003.
  • Flux-8day products from Day 155 to 165 (8-day periods 10 to 13) in 2003 are bad data, due to inaccurate 8-day AVHRR SSTs.

Content of the data files

  • unzip the files with gunzip if .gz extension is present
  • files are written in binary, with "big endian" like byte ordering.
  • Six (1140,570) fields of floats are written sequentially
  • These six fields are avnnd, avnnw, stnnd, stnnw, nbnnd, and nbnnw
    • avnnd is the flux field calculated with 1-day AVHRR SSTs
    • avnnw is the flux field calculated with 8-day (7-day after 2002) AVHRR SSTs
    • stnnd is the flux standard deviation corresponding to avnnd
    • stnnw is the flux standard deviation corresponding to avnnw
    • nbnnd is the number of points corresponding to avnnd
    • nbnnw is the number of points corresponding to avnnw


IDL(tm) sample for reading the data are included in the data distribution:


;* Sample code for reading the raw files

;* of gridded latent heat fluxes

;* derived from SSM/I TB and AVHRR SSTs




; If you experience some difficulties with this code, try to replace previous line with :











To get the flux fields, please follow the link.
To browse the gif images, click here.


  • Bourras, D., L. Eymard, and W.T. Liu : A neural network to estimate the latent heat flux over oceans from satellite observations. International Journal of Remote Sensing, 23, 2405-2423, 2002a.
  • Bourras, D., W. T., Liu, L. Eymard, and W. Tang: Evaluation of Latent Heat Flux Fields from Satellites and Models Over the SEMAPHORE Region. Journal of Applied Meteorology, 42, 227-239, 2003b.
  • Bourras, D., G. Reverdin, H. Giordani, and G. Caniaux (2004), Response of the atmospheric boundary layer to a mesoscale oceanic eddy in the northeast Atlantic, J. Geophys. Res., 109, D18114, doi:10.1029/2004JD004799.
  • Bourras, D., Comparison of Five Satellite Derived Latent Heat Flux Products to Moored Buoy Data, J. Climate, 2006, accepted.

Particular requests/cooperation

  • Other time periods (3-day, 5-day, 7-day, or 10-day, for instance) can be made available upon request.
  • Users who would like to initialize an ocean model with satellite products may find the present flux fields inappropriate, because the SST that is embedded in the LHF formulation should not be used as an input in the ocean model. For this specific need, an intermediate solution can be tried: we can make available the flux algorithm together with the SSM/I gridded TB fields. Next, the user can combine its ocean model SSTs with the gridded TB, which should finally be used for calculating the LHF estimates with the neural network.
  • Improvement of the neural network algorithm is underway at IPSL/CETP.
  • We welcome users who want to compare this flux product to existing products. Please let us know if we can help/customize the product.

Data sources

  • SSM/I level 1b data were obtained from Satellite Active Archive at National Oceanic and Atmospheric Administration (NOAA).
  • AVHRR and MODIS data were provided by Physical Distributed Active Archive (PO-DAAC) at Jet Propulsion Laboratory


Please contact Cet e-mail est protégé contre les robots collecteurs de mails, votre navigateur doit accepter le Javascript pour le voir


Dernière mise à jour : ( 07-07-2006 )