PACE L1b and Cloud Granule Timestamp mismatch

[zachary.fasnacht]

I've been working with PACE OCI data and finding that there are some PACE OCI granule for which the L1B and cloud product have different time stamps. Any idea the cause? What's the best way to match granules if the time stamps don't match up?

An example....

PACE_OCI.20240401T021445.L1B.V3.nc
PACE_OCI.20240401T021449.L2.CLD.V3_0.nc

[OB ODPS - towens]

The L1B have the scheduled time of the granule in the name. The L2 names reflect the actual start time of usable data, which may differ from the scheduled time of the granule.

Tommy

[zachary.fasnacht]

Thanks for the clarification. Just to confirm, this means users need to match L1B and L2 files based on a time window rather than a one-to-one file id match? That approach seems a bit fragile, especially for automated processing or algorithm development that relies on synchronized L1B reflectances and L2 retrievals. Given the frequency of mismatches, is there a recommended or more robust way to associate corresponding L1B and L2 granules? A more systematic solution could significantly improve usability and reduce the overhead for users integrating both data levels.

[OB ODPS - towens]

If a fuzzy match on filenames doesn't work for you, you could download the L2 file first, and read the "ifile:" from the L2 metadata to ascertain the parent.
e.g.:
:ifile = "PACE_OCI.20250207T001005.L1B.V3.nc" ;
:ofile = "PACE_OCI.20250207T001009.L2.CLD.V3_0.nc" ;

Tommy