(please message on ~asimov channel on mattermost if you need the password).
Zoom meeting link: <https://uofglasgow.zoom.us/j/95137690928> (please message on \~asimov channel on mattermost if you need the password).
This meeting will be held in accordance with the [asimov developers' code of conduct](https://git.ligo.org/asimov/asimov/-/blob/review/CODE-OF-CONDUCT.rst) and the [LSC code of conduct](https://dcc.ligo.org/LIGO-M1900037/public).
# Agenda
## Announcements
+ Submission of asimov paper to JOSS this week
## Major items
...
...
@@ -18,6 +18,49 @@ This meeting will be held in accordance with the [asimov developers' code of con
# Attendance
<spandir="">Aaron Zimmerman, Daniel Williams, Alan Knee, Soichiro Morisaki, Greg Ashton, Jan Steinhoff, Michalis Agathos, Surojit Saha, Richard Udall, Zoheyr Doctor</span>
# Minutes
+ See also the [decision log](decision-log)
\ No newline at end of file
-<spandir="">Asimov paper to be submitted soon</span>
-<spandir="">Discuss roadmap</span>
*<spandir="">Greg: had an idea to have a script to generate prior ranges automatically from trigger time. Inspired by a RIFT approach. </span>
*<spandir="">Richard Udall interested in helping</span>
*<spandir="">Greg: in O3 often found initial runs railed. Idea is to automate widening priors when initial results rail. </span>
*<spandir="">Doesn’t even need to create good posteriors initially, so the prior-finding can be another algorithm</span>
*<spandir="">Daniel: for interaction with Condor, don’t run Asimov as a cron job but in a way that checks more frequently. Not flashy, but this is a high priority task</span>
*<spandir="">Method for specifying priors needs to be improved, more options and less ad hoc</span>
*<spandir="">Interfacing with Asimov: want to move to a web-based interface. Gitlab approach was stressed to limit in O3</span>
*<spandir="">This would be used to set up a PE run. Point to a gracedb trigger and it would set up the run</span>
*<spandir="">Like Git Repos, would be good to “clone” an Asimov analysis for further offline work (good for TGR). Maybe also allow for packaging of full run and run info for full reproduction</span>
*<spandir="">Add additional pipelines, improve interface to existing pipelines (for example rapid inference pipelines)</span>
*<spandir="">Michalis: How much work to add a new pipeline? </span>
*<spandir="">Daniel: \~45 min to add PyCBC, for example. Need config file, and then figure out the map between Asimov and the pipeline. And code to produce dag files if needed.</span>
*<spandir="">But the bigger issue is maintenance: need experts in pipelines as part of Asimov development team</span>
*<spandir="">Aaron: adding analyses outside the core ones that will be used should be lower priority, and those pipelines should provide an expert to Asimov to maintain</span>
*<spandir="">Even more, need experts from core pipelines present</span>
*<spandir="">Daniel: highest priority is improving the handling of errors from pipelines</span>
*<spandir="">Greg: asks about how review (of results) will work. </span>
*<spandir="">Daniel: This needs documentation and to be reviewed. Automated tests do exist to check posteriors</span>
*<spandir="">Greg: Also there is a desire to put these things on gracedb, and Daniel agrees that is a good idea, but not sure what to put there</span>
*<spandir="">Greg: idea would be to have metadata on gracedb, for example in a json file, which could log review status. Allows for automatic review checking scripts to be written.</span>
*<spandir="">Discussion about needs of downstream users</span>
*<spandir="">Zoheyr: Needs from R&P need to be communicated upstream to PE. Filename, directory, results formats and structures would be helpful (they want to to intermediate analyses)</span>
*<spandir="">Also good if that structure looks the same as what the outside world will see (start with final product and work backward)</span>
*<spandir="">For example, PE samples may be produced at intermediate stages</span>
-<spandir="">Need to build a team. Daniel has 1 day per week to work on Asimov.</span>
*<spandir="">Aaron: this call identifies some people. People also signed up on their MOUs for Asimov devel, so we can get in touch with those people</span>
*<spandir="">Michalis: will there be training? Daniel: since things will develop over the next few months, may not be good to train users now</span>
*<spandir="">Daniel: code does many different things, like scheduling, file storage; then pipeline interactions</span>
*<spandir="">Documentation exists for the pipeline interactions, but not really the rest. Others can get familiar with aspects, but this will depend on their expertise.</span>
*<spandir="">Michalis: TGR will have a few people working on the pipelines, so an intro for them would be a help. Either main call or automation call</span>
*<spandir="">Daniel: will have to make some material explaining better how to add pipelines and pipeline features</span>
*<spandir="">Aaron: also should interface with the GWCloud devels to find out what role they can fill, what interactions can be created. Their expertise may be particularly good for creating the web interface.</span>
*<spandir="">Daniel: will liaise with them and check in on things.</span>
-<spandir="">Interfacing with Detchar: what connections can be made here? Alan Knee coming from this angle</span>
*<spandir="">Daniel: in O3, Derek added detchar recs by hand. Automating and streamlining this would be potentially helpful</span>
*<spandir="">Errors were made when transferring the recs from Derek to later stages.</span>
*<spandir="">Aaron: frequency range recs seem like they can be coordinated easily, but deglitching was needed a lot and it would be great to automate in some way</span>
*<spandir="">Daniel: things that it may be possible to automate, but with a human checking the output. Given the BW already is usable by Asmiov, this may be doable</span>
-**<span dir="">ACTION ITEM</span>**<spandir="">: Everyone add their names to the table indicating what area you might be interested in to the roadmap page, even if you don’t know how much time you can commit</span>
