Add resolution-based chunking to ABI L1b reader

[djhoese]

Add resolution-based chunking to the ABI L1b reader and switch default data type to 32-bit floats. This is similar to #2052 and #2584, but for the ABI L1b reader. This PR was a little more difficult than those as we are using xr.open_dataset here so we can't tell xarray what chunk size we want and have it be on-disk-chunk aligned. I cheat by having the on-disk chunk size hardcoded. Without this we'd end up with misaligned resolution chunks which defeats the purpose of this PR. I noticed that full disk files have a chunk size of 226 (consistently) and CONUS and M1/M2 are 250.

Edit: CSPP Geo GRB is configured to produce on-disk chunks of 226 for all sectors.

Additionally, I changed the default processing to produce 32-bit floats instead of 64-bit floats since the extra precision for non-x/y variables should be unnecessary.

Lastly, I rewrote the L1b tests. They didn't make it possible to test what I needed to test and there is a lot sense duplicate code now.

TODO:

• Actually add tests for the dtype and chunk size changes

• Closes #xxxx
• Tests added
• Fully documented
• Add your name to AUTHORS.md if not there already

[codecov]

Codecov Report

Merging #2621 (006136e) into main (86c075a) will decrease coverage by 0.01%.
Report is 7 commits behind head on main.
The diff coverage is 97.48%.

@@            Coverage Diff             @@
##             main    #2621      +/-   ##
==========================================
- Coverage   95.18%   95.18%   -0.01%     
==========================================
  Files         354      354              
  Lines       51270    51316      +46     
==========================================
+ Hits        48803    48846      +43     
- Misses       2467     2470       +3     

Flag	Coverage Δ
behaviourtests	4.24% <1.00%> (+<0.01%)	⬆️
unittests	95.81% <98.96%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
satpy/readers/abi_base.py	95.36% <100.00%> (+0.80%)	⬆️
satpy/readers/abi_l1b.py	98.87% <100.00%> (-0.03%)	⬇️
satpy/tests/reader_tests/test_abi_l1b.py	98.95% <98.85%> (-0.43%)	⬇️
satpy/utils.py	27.05% <40.00%> (+0.17%)	⬆️

... and 2 files with indirect coverage changes

[coveralls]

Pull Request Test Coverage Report for Build 6712031249

• 201 of 203 (99.01%) changed or added relevant lines in 4 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage increased (+0.003%) to 95.762%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
satpy/tests/reader_tests/test_abi_l1b.py	177	179	98.88%

Files with Coverage Reduction	New Missed Lines	%
satpy/readers/abi_base.py	1	95.36%

Totals
Change from base Build 6663415040:	0.003%
Covered Lines:	48966
Relevant Lines:	51133

---

💛 - Coveralls

[djhoese]

So the tests are passing here and the individual ABI L1b tests pass locally, but if I run all the Satpy tests, some of these new tests fail at the dask array chunking checks with unexpected chunk sizes. I'd still like to investigate but that shouldn't hold up a review on this. My guess is some poorly configured test in something else and/or one of my other edits/debugs in my other packages screwing things up.

[djhoese]

Scratch that. Pycharm was using an old Python 3.10 environment that I haven't used for a long time. No idea what was in there, but my guess is an old version of xarray not using previous_chunks was giving different final chunk results.

[mraspaud]

Looks good overall, and great job on the test refactoring/rewitting.

I have a couple of comments in-line, but one general thing I want to bring up is the use of the scene object in the tests. Is this really necessary? these tests are for the file handlers iiuc, so I suggest we stick to that api. Using the scene here makes these test fragile and likely to break if the scene object changes or is deprecated in the future, while the abi reader will still be valid.

[mraspaud]

Do we need this dead code?

[djhoese]

one general thing I want to bring up is the use of the scene object in the tests. Is this really necessary? these tests are for the file handlers iiuc, so I suggest we stick to that api. Using the scene here makes these test fragile and likely to break if the scene object changes or is deprecated in the future, while the abi reader will still be valid.

Agreed. I brought this up on slack and Panu was the only one that commented. I don't like using the Scene in the tests either, but also I hate the number of functions/methods I have to call just to get a reader instance. I can change it, I'm just not sure where to use utility functions in readers/__init__.py versus calling the class and class methods directly. I'd like it to load the YAML and it seems dumb to do that manually, so maybe I should use the helper functions in readers/__init__.py.

[mraspaud]

LGTM, thanks for the heavy work on the tests and not using the scene interface anymore