Experience with the in-situ instruments has shown that, even when validated with flight data, small issues tend to crop up when deploying into production and trying to flow data from L0 through L3.
The expectation is that the map products will likely have a similar process to go through, and so we should deploy the map codes into production and trigger processing before the planned generation of the first three-month maps "for score". The plan is to generate all maps, even those that are normally only produced on a longer cadence (there will just be a lot of gaps).
This is the list of needed inputs / preconditions, to be replaced with GH blocking issues--i.e. once an issue is identified and added as a blocker to this one, the related item on the list is removed, so we only have it in one place:
- Ability to manually trigger map (dependency refactoring)
- Completion of goodtimes / culling work (I'm not seeing obvious by-instrument parent issue for this?)
- Identify how to manage archive impacts (e.g. do we keep these maps long-term)
Experience with the in-situ instruments has shown that, even when validated with flight data, small issues tend to crop up when deploying into production and trying to flow data from L0 through L3.
The expectation is that the map products will likely have a similar process to go through, and so we should deploy the map codes into production and trigger processing before the planned generation of the first three-month maps "for score". The plan is to generate all maps, even those that are normally only produced on a longer cadence (there will just be a lot of gaps).
This is the list of needed inputs / preconditions, to be replaced with GH blocking issues--i.e. once an issue is identified and added as a blocker to this one, the related item on the list is removed, so we only have it in one place: