Need to flip `glt_x`?

[piyushrpt]

Need to flip `glt_x`?

[piyushrpt]

Testing more - everything that was processed with software version 010613 appears to have this issue. The ones with 010611 do not. Looking for examples of 010612 but havent found any yet

[ebolch]

Thanks for bringing this to our attention. I started to look into this and found the same inconsistency with newer granules. I'm guessing the data is now being flipped (or no longer being flipped) with the new software version. We will reach out to the EMIT team.

[pgbrodrick]

Reference to emit-main was simply to give the timeline (dates) as requested above - I understand that's independent of the desire to access the particular metadata with each granule.

Re: file metadata, I should have been more explicit - certainly the build number is in the netcdf, but it's also available in the ummg (along with quite a bit of other metdata), which may give you what you're after.

[pgbrodrick]

We also have a positive ID on the core issue, which did occur in 010612, due to a gdal read failure for long metadata fields. We are working on a fix.

[ebolch]

Until a fix is implemented, you can retrieve the software build version from the additional attributes via cmr using the umm_json cmr endpoint. Something like this in python:

import requests

granulesearch = 'https://cmr.earthdata.nasa.gov/search/granules.umm_json'

cmr_param = {
    "collection_concept_id": 'C2408750690-LPCLOUD', # EMIT L2A Reflectance
    "temporal": '2022-09-03T00:00:00Z,2022-09-03T23:23:59Z',
    "point":'-62.1123,-39.89402'
}

response = requests.post(granulesearch, data=cmr_param)
response.json()['items'][0]['umm']['AdditionalAttributes']

[ebolch]

The L1B and L2A EMIT granules generated with the buggy process will be reprocessed and replaced. We've identified and removed the them. The reprocessed versions should be available soon.

[piyushrpt]

Thank you. Closing this as these products have already been removed.

[piyushrpt]

Here are other examples. There appears to be a correlation with the software_version?

Granule that needed a flip: EMIT_L2A_RFL_001_20230528T220519_2314815_009
Granule that did not need a flip: EMIT_L2A_RFL_001_20230427T173257_2311711_009

[pgbrodrick]

We are looking into this. I suspect the issue was either introduced with the flatfield update in 010612 or is unrelated to the software build. 010613 is unlikely to be the culprit.

[piyushrpt]

Would it be possible to provide a timeline (dates) on which software updates were deployed. Alternately, it would be nice to have the software/processor version in the CMR metadata for the granules.

[pgbrodrick]

The easiest way to track the release history through time is to look at the emit-sds/emit-main repository (https://github.com/emit-sds/emit-main/releases). The software build version is also available in the file metadata (not the CMR), which I believe (?) is api queryable. @ebolch, can you confirm that?

[piyushrpt]

Yeah - intent is to make it queryable via CMR. Right now I have been looking at the netcdf metadata to identify the software version. The releases to emit-main are less useful as we don't really know when these were deployed and used in production without accessing the granules and looking up the metadata in them.

[piyushrpt]

Following up on this - would the products generated with the buggy processor retired and reprocessed (or) instructions be provided to use the look up tables correctly for those versions?