Getting Started With PSEII and Secloud
PSEII is the Python package used by the European Space Agency's Climate Change Initiative for ocean salinity retrieval. It reads satellite data and turns raw radiometer signals into usable salinity fields. Secloud is a companion tool for handling cloud contamination in microwave brightness temperature data. They're designed to work together but the documentation is thin and nobody really explains the practical workflow. I'll walk through what actually happens when you run these tools, not just what the manual says they should do. The first thing you need is a working PSEII installation with the correct dependencies. Conda environments tend to work better than pip here because the package pulls in some older scientific libraries that don't always play nice with newer Python versions. I set up a dedicated environment with Python 3.9 and installed PSEII version 4.2. Using anything significantly newer or older than that version pair tends to cause import errors you won't find documented anywhere. The standard workflow starts with downloading SMAP L2C or L3 radiance data from the LAADS DAAC. You grab the HDF5 files. PSEII reads them directly. But here's where people run into trouble quickly. The sea surface temperature field you pass into the algorithm matters more than most tutorials acknowledge. If your SST comes from a different source or resolution than what the algorithm expects, you get retrieval bias that can reach 0.1 to 0.3 practical salinity units depending on latitude and season. I learned this the hard way when my results showed anomalous freshening near the equator that I couldn't explain until I checked the SST dataset alignment. I switched to using the MUR SST product at the native SMAP resolution and the bias disappeared. It took me about two days to debug what should have been obvious from reading the algorithm reference paper.
For the Secloud side, the key input is the cloud water path and the radiometer channel frequencies. You feed in the auxiliary cloud products and the software applies correction coefficients to the brightness temperatures before PSEII processes them. A common mistake is skipping the quality flag check on the cloud product itself. Secloud will process bad cloud data without warning you. I once ran a full month of retrievals only to discover that a corrupted auxiliary file had been passing through as valid. The fix was straightforward — validate every input file against its metadata before running the batch job. I built a simple validation script that checks file timestamps, sizes, and internal consistency, and it saves significant time compared to debugging bad output later. When running batch processing, I recommend splitting your data by orbit granules rather than processing whole days at once. PSEII handles granules natively and memory usage stays manageable. Processing whole daily files can cause the algorithm to consume several gigabytes of RAM per tile, which becomes a bottleneck on standard hardware. I typically run 4 to 8 parallel jobs depending on available cores, and the total throughput on my machine is roughly 200 to 300 granules per hour. Output validation is where most people stop paying attention. Check the retrieval flags in the L3 product. PSEII flags retrievals with poor signal-to-noise, land contamination, or extreme weather conditions separately. If you're aggregating to monthly means without filtering these flags, your averages will be biased toward clear-sky conditions and you'll miss the high-variance periods that matter most for climate analysis. I set a minimum flag threshold and exclude any pixel where more than two flags are raised simultaneously. This usually removes about 8 to 12 percent of the data globally, which is acceptable for most applications.
There are scenarios where this entire pipeline breaks down. Coastal zones within about 20 kilometers of shore are unreliable because the algorithm wasn't designed for the mixed land-ocean pixels that dominate that region. High-latitude areas during winter also produce questionable results due to low signal strength and ice contamination. Neither PSEII nor Secloud advertise these limitations prominently. You just discover them when your time series shows artifacts that don't match any known oceanographic process. In those cases, you either mask the affected regions entirely or switch to a different retrieval method. The GOSAD product or the NASA JPL salinity product are reasonable alternatives for coastal work, though they come with their own set of tradeoffs around spatial resolution and update latency. The download links for PSEII are available through the ESA CCI website and the package itself is on PyPI. Secloud is distributed separately under similar terms. Both require a free account registration to access the full satellite data archives, which means you should set that up before starting your first job rather than discovering the access restriction mid-process.
Get the Full Details
