CLAVRx Reader for AHI data misses CLAVRx files with naming convention that retains full AHI original name.

[joleenf]

Describe the bug The CLAVRx reader has based the input AHI filename on a shortened version of that filename which typically is not generated by the CLAVRx processing routine, but is a branch that usually does not survive updates. Therefore, files routinely produced by the CLAVRx processing routine are not found with find_files_and_readers. To Reproduce

Attempting to load a filename of clavrx_H08_20220920_1230_B01_FLDK_DK_R10_S0110.DAT.level2.nc in a directory which also contains files with the filename convention of clavrx_H08_202209181230_B01_FLDK_DK_R.nc in a local path represented by <path to local AHI data>

# Your code here

from satpy import find_files_and_readers
f = find_files_and_readers(base_dir=<path to local AHI data>

Expected behavior Ether filename convention should be discovered by the CLAVRx reader. Actual results Only the filename which was actually added to the setup file for the CLAVRx reader is found: clavrx_H08_202209181230_B01_FLDK_DK_R.nc

Environment Info:

• All Environments (oversight in reader)
• Readers and writers dependencies (when relevant): clavrx reader dependency

[djhoese]

Thanks @joleenf. Could you make a pull request with the new pattern(s)?

I think when the original file pattern was added the AHI support in clavrx was very experimental so I'm not surprised at this missing functionality. When you talk about the CLAVRx processing routine, do you mean the CLAVRx team generating these products operationally or the default filename scheme used by the CLAVRx software?

[joleenf]

We are discussing if this current filename (with the original resolution tag from H8 filename) is appropriate (CLAVRx is 2km resolution). I am going to hold off on changing the CLAVRx reader until the CLAVRx team is settled on what the actual product filename should be in this case.