LBNL-2016: Time-Ordered Data Processing
Time-Ordered Data Processing Birds-of-a-Feather Session: Wednesday, March 9, 9 AM
Attending: Julian Borrill, Tom Crawford, Ted Kisner, Kris Gorski, Graca Rocha, Clem Pryke, Nick Harrington, Jesse Treu, Kyle Story, Nathan Whitehorn, Olivier Perdereau, Reijo Keskitalo
Discussion of TOD scanning simulations
- Scanning with full 4-pi beam: do we really get the 4-pi beam at high fidelity?
- at some level, not the data folks' problem.
- Are we really going to simulate full TODs, including data that we will eventually cut in the real TOD?
- yes, at least to test automated data cuts.
- who is going to take on the task of creating this model?
- we pretty much know how to do it now, unless the fundamental detector and/or readout architecture changes.
- Do we need to simulate TES & electronics response?
- Not a high priority. Assume detectors/electronics with funky response will not pass CD.
- RFI pickup?
- Impossible to implement in sims without model of pickup.
- Time-dependent focal plane / optics distortion?
- Real-world examples to go on from ACT & PB
- We need scan strategy to be defined to do sims.
- Is anyone considering using anything but azimuth scans as fast and wide as you can go?
Digression into computing plan
- Are we really going to use grid computing (rather than parallel processing on large clusters)?
- Certainly not for anything for which we have to send around real TOD. (I.e., just for sims.)
- What about data management / delivery from sites?
- Pole bandwidth barely accommodates SPT-3G and will be unlikely to increase enough to handle S4. Similar issues exist in Atacama.
Return to TOD sims
- Will there be half-wave plates on S4?
- Can't rule it out. How do you make a model of non-ideality for a HWP?
- Are we aiming to have a perfect set of TOD sims by summer or 10 years from now?
- There will be a profile of what we can simulate. Could in theory have some level of TOD sims by summer.
- What about atmosphere?
- Moving slab prototypes exist.
- Loudly stated that TOD sims will not be used in the 3-month timescale forecasting.
- OK, but is there something we can do on the next timescale (~6 months)
- At least agree on common inputs & data formats.
- That's coming up soon.
Time to Pixel Domain
- Are preprocessing steps included in instrument?
- In a perfect world, yes.
- Are we discussing mapmaking procedures yet?
- They should all be implementable. Though ML-mapping will be hard from Pole.
- Everything will be driven by data volume.
- First step is to avoid I/O as much as possible.
- How to accommodate two analysis modes (interactive development on small number of timestreams vs. full-TOD MCs)?
- Does a python-based codebase disfavor HPC?
- Not fundamentally, but it would be great to be able to swap in a C/C++ module for the corresponding python module seamlessly.
- DATA FORMAT
- Everyone agrees that Healpix is the right pixel format.
- Use currently implemented cut-sky Healpix format in FITS?
- That is not using any of the advantages of FITS and incurring many disadvantages.
- Sounds like we have decided to use hdf5 and take on the job of writing a healpy interface.
- Scalable software used at LBNL
- python-based implementation of LFI control & mapmaking (PyTOAST calling libmadam)
- Will we be able to run different Stage-3 experiments' data through each others' pipelines?
- [raucous laughter ensues]
- Perhaps require that all S3 experiments' data run on their own pipeline and a common pipeline.
- Some consensus achieved that S4 pipeline will be high-level python with some C/C++ under the hood.
Word of the day: Exciting
All perfect data sets are identical; each imperfect data set is imperfect in its own way. (Anna Karenina)
First, we kill all the I/O. (Henry VI)
|11:20||Ted, on behalf of Nathan||Ted|