Output files always state scan mode M3

[gerritholl]

The Scan Mode as described in output file names is always M3. For example, the example adapted from the documentation:

python examples/grid/make_GLM_grids.py --fixed_grid --split_events --goes_position east --dx=2.0 --dy=2.0 --width="1000.0" --height="500.0" --ctr_lon=0.0 --ctr_lat=0.0 /path/to/GLM/104/04/OR_GLM-L2-LCFA_G16_s20201040404400_e20201040405000_c20201040405028.nc

results in a file

OR_GLM-L2-GLMM1-M3_G16_s20201040404400_e20201040405400_c20201991516380.nc

as far as I know, scan modes exist for ABI but not GLM. This scan mode is set to M3 in imagery.py:

glmtools/glmtools/io/imagery.py

Line 257 in d2823e1

modes = {'ABI Mode 3':'M3'}

probably as ABI was in scan mode M3 when it was written. It is now in M6. It's probably not important as I don't think this information is used, but it's confusing to read in ABI files with mode M6 along with glmtools-processed GLM files that say M3.

I'm not sure what the best solution would be. Perhaps this information could be considered not applicable to these files, perhaps with scan mode "NA" for "not applicable"?

[deeplycloudy]

@gerritholl yes, this is an awkward use of the ABI terminology since GLM does not have scan modes. I tried to match the ABI filename convention, which I think was motivated by a US NWS request. There's similar awkwardness with the definition of which mesoscale sector is being used when gridding to a mesoscale (1000x1000 km) domain. I'll ask NWS and NESDIS if they have an opinion about how to handle this to match with their systems.

[gerritholl]

Did you get any feedback? It's indeed awkward that there is no way to make a distinction between M1 and M2-based files. This is probably more important than the scan mode, because users may want to collect lightning corresponding to either M1 or M2 in a certain period (during which it doesn't move) in two different files.