Salinity Wind Cells - JPL's SMAP salinity data product combines sea surface salinity (SSS) and wind speed. Time-ordered data are projected into swaths (Level 2A) whose along-track and cross-track coordinates are similar to longitude and latitude, respectively. These gridded data are, in turn, used to generate "Salinity Wind Cells" (SWCs).
Flavors - SMAP's spinning antenna results in some footprints acquired either to the fore or aft of the spacecraft. Also, the retrieved signals are horizontally and vertically polarized (H-pol and V-pol, respectively). JPL processing separately bookkeeps these four "flavors" of TB for each SWC: Fore H-pol, Aft H-pol, Fore V-pol, and Aft V-pol. JPL's data fields are shown in detail in the Appendix.
JPL pre-processes collocations of HYCOM SSS, NOAA Optimum Interpolation SST, NOAA WaveWatch III Significant Wave Height, and SMAP Level 1 TB data. For each SWC, land- and ice-contaminated data are flagged and removed before averaging. Averaged "four-flavor" composite TB values with a small number of corrections (i.e., Galaxy Correction, high-latitude TB Bias Adjustment, Reflector Emissivity Correction) are generated prior to Level 2B processing.
Both salinity and sea surface roughness affect sea surface emissivity and cannot be fully distinguished from one another. Thus, the two effects are combined during JPL processing but generated as two datasets (smap_sss for salinity and smap_spd for wind speed). SSS uncertainties are estimated from combined salinity and wind speed computations and include the effects of cold water, radio frequency interference (RFI), geophysical model function (GMF) errors, and measurement errors.
Data are provided in the case of "extreme winds" such as those associated with tropical storms. In these cases, salinity is fixed at the ancillary HYCOM value while the emissivity signal is attributed to winds. Users should be aware that errors in the ancillary salinity – e.g., areas with high salinity variability such as major river outflows - will map to erroneously high wind speed.
Visit the SMAP SSS Products Overview and Ancillary Data Sources section to learn more about how RSS and JPL process SMAP data.
The SMAP Project makes its own brightness temperature calibrations; however, the requirements needed for land are not nearly as stringent as those over the ocean. For salinity, RSS recalibrates brightness temperatures from the antenna based on a long history of doing this type of work.
We at JPL take the brightness temperatures provided by the SMAP Project and are doing some empirical data-driven calibration, which we believe has captured some of the potential errors in the Level-1B data. Also, the Project's brightness temperature calibrations are getting better over time, partly because we are all learning from improvements in each other's algorithms and data version updates.
Many of the variable fields in the RSS list are directly related to their brightness temperature corrections. Since we are using the SMAP Project's correction, we don't need those variables.
The algorithms that go into making the salinity and wind speed retrievals are very similar. They involve almost all the same steps. We could have made it into two different products but that would have meant a difference of just one additional data field in the Level-2b product. So, it is easier to combine them together in the same product from the data management point of view.
Our processing is based on what was developed for scatterometers (e.g., QuikScat, RapidScat). We are using the same software and algorithms used to process scatterometer data. Scatterometers have HH and VV measurements from a spinning antenna. So, in every wind vector cell - which we call "salinity wind cells" for SMAP - we would get an HH measurement and VV measurement from the fore side of the scan and the aft side of the scan. Radar data are very wind direction dependent. So, it's very important to not average those two observations (i.e., fore and aft). We need to keep them separate through the Maximum Likelihood Estimator (MLE) part of the retrieval. We're applying this same philosophy to the brightness temperatures for SMAP. There is not as much wind direction dependence for brightness temperatures, but there is still some... so we keep them separate.
It's really just the average of the h-pol (i.e., horizontally polarized) looks, looking forward of the spacecraft or the average of the v-pol (i.e., vertically polarized) looks, looking forward of the spacecraft. Also, the h-pol looking backwards and looking forward. They're all in the same ground cell together; these are the four numbers that go into the MLE and we bookkeep separately.
The Geophysical Model Function (GMF) is an empirical relationship between geophysical factors such as sea surface wind, wind direction, significant wave height, sea surface temperature, and the observation geometry (e.g., incidence angle, azimuth angle), and radiometer wavelength (i.e., L-band). It's an empirical relationship between those geophysical parameters, the geometry parameters, and the observed microwave brightness temperature. We create a look-up table based on a lot of data... in essence, the expected observation given the sea state.
We have the measured brightness temperature and we know the time and location it was measured. We also know the incidence angle and the azimuth angle from the instrument (i.e., spacecraft ephemeris so we can compute them). Then we use ancillary data from the National Centers for Environmental Prediction (or ECMWF) to get the wind speeds, wind directions, and wave heights. We get sea surface temperature from NOAA Optimum Interpolation and salinity from HYCOM. From all of these model parameters and the geometry, we can synthesize the expected observation. The whole retrieval process involves comparing the actual observation and figuring out which salinity and wind speed gives you the expected observation that compares best with the model observation.
The MLE process quantifies this process. We have SMAP's radiometer observation and we have a model function, which is a big table of expected observations based on given geometry, salinity, wave height, sea surface temperature, and wind speed/direction. The MLE process solves for the best salinity that makes the measurements most match the model function. How good that fit is helps to quantify the uncertainty; this also comes out of the algorithm in the retrieval process.
This equation (also called the "objective function") is the MLE. The summation index (Σi) is the four "flavors." TB,i is the observed brightness temperature. TmB,i is the geophysical model function, which is a function of wind speed, salinity, wind direction, significant wave height, and sea surface temperature. We take the sum of squares of the measurement minus the model divided by the expected variance (NEDT squared); these are contributions from each flavor to the objective function. The last term is the speed constraint that makes the problem have a single solution, otherwise there would be a one-dimensional set of solutions in wind speed and salinity space.
This overall equation is what we minimize. We take the objective function, F, and find its smallest value using numerical libraries. That's what gives the salinity solution (i.e., the SMAP salinity retrieval).
We don't deal with rain at all in Version 4.3. We don't have quality flags for rain (unlike RSS). Rain data are not being brought in as an ancillary variable and it's not currently in the model function. We may include rain in future versions of our processing.
However, rain would presumably cause an increase in uncertainty. So, in our product, the rain-affected data would look less like the model function and give a larger uncertainty in the retrieval. A more general statement is that anything that could make the retrieval worse should be reflected in the uncertainty. If folks are really interested in rain, they should probably get the GPM IMERG product.
It's definitely easier from our perspective as data providers since there are fewer products and also less data to download for users. Most of the salinity users are probably using Level-3 products, except for those are who assimilating data into their own models.
Wind data users are probably using our near-real-time product. For example, NOAA is trying to assimilate SMAP brightness temperatures into their ocean surface model, trying to operationalize it.