Thanks. that is the reason for the failure.
Only the debug log does not show any query item containing the version or I should check other place for this message?
I have a question about the version, geolocation file is found with different versions, I wonder if all versions of granule go to chain to produce other products like surface type EDR, channel data SDR or only the highest granule version?
I am also surprised why only cloud mask file gives the error but others not. The whole input data set in the same granule are having the same version.
Thanks.
HDF Unpacker
Re: HDF Unpacker
You are correct that the N_Granule_Version metadata is not part of the actual query metadata that gets dumped out. Initially one would think that this is in error, but in actuality it is done this way deliberately. The main reason having to do with how complicated the cross granule granule version acceptance rules are. There are numerous different granule versions that can be accepted for a cross granule item, while the primary items have to match exactly the granule version that has been tasked from the run-time environment file (light weight config). The method pruneURs() is the method that prunes the query results that are returned, validating that the granule version meets the primary or cross granule rules.
Geolocation should abide by the exact same granule version rules as Cloud Mask IP. However, I suspect that you see the failure on CM IP due to it being the first item that is retrieved for which there aren't inputs that match appropriately. The framework software does not try to retrieve other items when there is a failure on an earlier item. I suspect that if you fixed the CM IP input version issue without fixing the geolocation issue, the input failure would just move to geolocation from VIIRS CM IP.
Both granule versions are tasked completely through the VIIRS or sensor chain. But the products for one tasking would be marked as "A1" and the other as "A2" so that they could be distinguished.
In the end, you should have only been able to run when you made all inputs have the same granule version as the tasking information in the light weight file. Hopefully this helps clarify some of the confusion but if not, please post again and I will try to explain further.
Thanks,
Bryan Henderson
Raytheon Company
Geolocation should abide by the exact same granule version rules as Cloud Mask IP. However, I suspect that you see the failure on CM IP due to it being the first item that is retrieved for which there aren't inputs that match appropriately. The framework software does not try to retrieve other items when there is a failure on an earlier item. I suspect that if you fixed the CM IP input version issue without fixing the geolocation issue, the input failure would just move to geolocation from VIIRS CM IP.
Both granule versions are tasked completely through the VIIRS or sensor chain. But the products for one tasking would be marked as "A1" and the other as "A2" so that they could be distinguished.
In the end, you should have only been able to run when you made all inputs have the same granule version as the tasking information in the light weight file. Hopefully this helps clarify some of the confusion but if not, please post again and I will try to explain further.
Thanks,
Bryan Henderson
Raytheon Company