# FAST data

## L1b

- current test pipeline produces new product types:

    SW_FAST_MAGA... etc

They cover most/all(?) of the publicly available L1b products.
These are updated ~3 times per day, producing e.g.:

    SW_FAST_MAGC_LR_1B_20220530T095110_20220530T220806_0601_MDR_MAG_LR.cdf
    SW_FAST_MAGC_LR_1B_20220530T220809_20220531T074006_0601_MDR_MAG_LR.cdf
    SW_FAST_MAGC_LR_1B_20220531T074009_20220531T090605_0601_MDR_MAG_LR.cdf
    SW_FAST_MAGC_LR_1B_20220531T091409_20220531T121806_0601_MDR_MAG_LR.cdf
    SW_FAST_MAGC_LR_1B_20220531T121809_20220531T134404_0601_MDR_MAG_LR.cdf

### Implications for VirES

- Defined as new product types? (i.e. `OPER` vs `FAST`)
- or only use FAST data where OPER is not available? (replaced with OPER once OPER becomes available)
- or will the ESA OPER processor be changed to present the FAST data as part of the OPER data?
- Increase pull rate from swarm-diss / set up a push process

## L2daily

- Which of these are planned to update for FAST?
- For each, what are the auxiliary data needed (i.e. those which are not part of the L1b FAST products)
- aux inputs:
- Dst: already available hourly from Kyoto WDC, but should swarm-diss AUX copies be updated?
- RC/MMA: Nils to increase production to hourly
- Some products (e.g. AEJxLPL, AEJxLPS) use data+models from VirES:
- VirES will need to handle the FAST L1b data and the more frequent CHAOS-MMA updates
- Since the L1b->VirES step adds delay, then the L2 products will be further delayed (and their processor triggers should be delayed wrt the expected L1b availability time on VirES)