Initial CoDICE L1A Processing Algorithm

[bourque]

Change Summary

Overview

This PR includes an initial pass at CoDICE L1A processing. Currently it only supports/works on CoDICE housekeeping packets, and does not yet do any analog to EU conversions (that work will be in a future PR and is currently being done by @GFMoraga in #274). The code is heavily inspired by @tech3371's SWE processing code.

The PR also includes a re-organization of the CoDICE code as a whole. Basically I moved all processing code to be directly under the codice/ directory instead of having separate l0/ and l1a/ directories. This organization makes most sense to me in my head, but I'm definitely open to other ideas. I also tried renaming some files so that they are a bit less repetitive.

Lastly, I added/updated some module and function docstrings, and updated the CoDICE API reference docs.

New Dependencies

None

New Files

• /cdf/utils.py
  • Added condition to set the file_start_date for CoDICE files
• /codice/__init__.py
• /codice/codice_cdf_attrs.py
  • CDF attributes for CoDICE; basically just used what SWE had and replaced where appropriate
• /codice/codice_l1.py
  • L1A processing code
• /codice/tests/test_codice_l1a.py
  • Tests for L1A processing code

Deleted Files

None

Updated Files

• /docs/source/reference/codice.rst
  • Added new L1A reference documentation and made changes to reflect the reorganization of files
• /codice/codice_l0.py
  • Moved from imap_processing/codice/l0/decom_codice.py
• /codice/utils/decompress.py
  • Moved from imap_processing/codice/l0/decompress_codice.py
• /codice/tests/test_codice_l0.py
  • Minor formatting updates
• /codice/utils/codice_utils.py
  • Added some functions to support L1A processing

Testing

I added unit tests for L1A processing, but currently only tests on housekeeping packets.

[maxinelasp]

Nice, this looks great

[GFMoraga]

This looks great! I will have to re-base but I think all of your updates and naming conventions are great!

[bourque]

@GFMoraga Yeah, this will likely cause you some merge conflicts, but I can help resolve those since they will be my fault!

[greglucas]

Nice, looks great! Just minor comments from me, but would prefer the test cleanup one to be added if possible.

I also personally like this structure better, I find the multiple nested modules a little harder to follow. If you're working on naming I might even suggest dropping the codice from the filenames within your codice module since that is repetitive. Something like this with a flatter instrument structure. (But, that is just my personal preference, no need to take it if you disagree)

codice/
    cdf_attrs.py
    level0.py
    level1a.py
    decommutation.py
    utils.py

[greglucas]

Out of curiosity, do we care that the maxval is a 64-bit signed integer, but we have only 12 digits of representation in the format?

imap_processing/imap_processing/cdf/defaults.py

Line 30 in c20b1e8

INT_MAXVAL = np.iinfo(np.int64).max

[bourque]

I can't for the life of me figure out why the doc build is failing. There are tons of WARNINGs (which is its own problem) but I don't think those should cause the entire build to fail. I don't see any actual ERRORs.

[maxinelasp]

I can't for the life of me figure out why the doc build is failing. There are tons of WARNINGs (which is its own problem) but I don't think those should cause the entire build to fail. I don't see any actual ERRORs.

I think warnings do cause the check to fail. You can try updating the config.py file like what I have in my currently open glows PR, and I think you will also need a Methods block in your class docs. I have a docfix commit on glows l1a which fixes very similar errors from my doc warning, so it might help you to look there.

[bourque]

Thanks @maxinelasp!

[tech3371]

Nice work!