| | | |
|---|
1:00 | Words from Randy | Randy | Cudos to Percy and Sherry for getting LRIS-R commissioned! Marc Kassis said very complimentary things. New RTC wavefront controller trying to be in the system for NGS science in late June, more LGS testing to do. Team Keck time announced; NIRSPEC/Greg program will get 0.5 night this semester, guaranteed another 0.5 night next semester. All time listed is modulo scheduling challenges. John is looking forward to adding Michael’s ToOs to the mix. As part of FY22/final FY21 budgettng, if you are planning to travel to a conference/meeting, please let Randy know!
|
1:10 | Words from John | John | Percy, Sherry, Luca, Kyle, summit crew - fantastically done! John is working on a thank-you for Connie’s team. John is designing an LRIS-red mission patch. Request for input in how to align with Grant on instrument projects; not to take away leadership, but how to leverage/make use of his summit experience. immediate project thoughts on laser frequency comb, guider camera replacement project, solar calibrator on KPF, etc.? Grant will help but not displace or take over the role from instrument scientists.
SSC meeting is on Friday May 21 at 7am. Reports on KPF progress, ORCAS (orbiting laser guide star) presentation. That week of May 21 John will be out doing fundraising. This year’s Keck Science Meeting will be at UCSD on September 9-10, 2021.
|
1:20 | | Randy | Currently ToOs are limited to reduce the support burden on SAs and summit crew. The biggest rules are: no instrument switches are allowed, and the ToO must be triggered by 4pm. As we come out of covid, should we keep them in 21B, starting August 1? Carlos: maybe delay one semester to let us ease back into normal? Jim: we could say we are tentatively ready or not as we get closer to August and have more experience being “back to normal”? Randy: obviously we need to talk to the summit crew about preparing an additional 1-2 instruments per telescope. Since at-home observing is more streamlined, we can have the observers do more of their observing, which will be less of a demand on SAs. Desired instruments seem to NIRES, MOSFIRE, LRIS… John: How ready does this group feel to support more instruments? Luca: If the SSH keys are required to be submitted at the beginning of the semester, that would be a big help for remote observing support. Percy: As before, if a ToO triggers an instrument that the night’s SA isn’t trained to support, how does someone get tapped to help support it? John: NIRES is theoretically available all the time; would we want to exclude its availability for things? Josh: Before, the policy was the SA would just do their best to support the instrument. Most triggers come during the day/afternoon. So backup is possible in most cases, especially for new SAs. Jim: Because the days are longer, we need the telescope to be released in time for calibrations, especially on KCWI split nights.
|
1:37 | Review list of CI projects for FY22 | Randy | 6 selected for FY 22, a few selected for this year. Shui is going to submit a CI about access to rotators even when the instrument is not on the telescope (says Josh). Implementing a system to notify day crew about calibrations in progress should be a CI. Kyle has submitted a CI to migrate MOSIRE to Linux. Randy: are any project particularly high priority? The general pool of FY22 hours won’t be assigned to CI projects. John: Josh, what happened to weather/allsky cameras? How are they going under UNO? Josh: They are proceeding under UNO, revisit after this year. Templates for Python instrument script/GUIs. Templates or sample scripts, or guidelines: clarification for us as well as outside groups like the AO teams. Randy is putting in a CI for MAGIQ to read TRICK images. The lead person of each task should submit their own CI project. Add whatever documentation of the CI being submitted to the Science Support Software tasks.
|
1:55 | Is it worth a CI to create proxy services to combine keyword services on instruments? | Jim | During the NIRSPEC upgrade, NIRSPEC transitioned to ~10 keyword services instead of one, making it hard to know which server has the needed keywords. Global/proxy keywords servers exist to combine them into one system. A few folks are for it, a few folks are against it. Carlos: If you change one of the services or a keyword, do you then have to change it in both the server and the global service? Jim: Yes. Josh: There would also be naming confusion in the global services, since similar keywords (STATUS, ITIME) would have to be renamed. Randy: could making global services allow some to use them and some not, as they prefer? Or would a smart script help fill in this gap? Jim: some keywords are in logical services, and some are in “plus” services when someone didn’t know where the keyword went. Sherry: even though we are only modifying LRIS-red keywords, some of the blue keywords behavior are changing even though we haven’t modified them. And some keywords written to the LRIS server are propagated to both -red and -blue. see Kyle’s comment in the issue about confusion, proxy’s causing problems. Josh: could issues be fixed with better documentation about what each services contains? Using ct or testAll can help with finding services.
|
2:15 | finished! | | |