ALMA Integrated Computing Team Coordination & Planning Meeting #3 Socorro, June 2014 Online system tools and Control's scope expansion Rafael Hiriart

Introduction The concern is that there are some areas that have been added in recent years to Control, which are not receiving enough attention (as perceived by our scientific stakeholders, or at least some of them). Besides this main "core" of Control (running observations and create datasets, Control is also responsible of QuickLook, the tmcdb-explorer, and other GUIs and tools). These can be classified in general as "tools". While most of the control group is fully dedicated to the "core", these tools have now limited resources. Do we have a resource/scope problem?

Questions For each one of these tools – Are these tools not being maintained as required? – If this is the case, should they be given more priority and/or resources, or can we wait for other tasks to be completed and resources be available?

Quicklook Quicklook came with resources, but we lost them. After we delivered QL "alarms" and summary reports, we thought this part of the system was going into maintainance mode. We were wrong, Quicklook was declared "unusable" because of freezing problems (was running out of memory in the OMC), and usability issues (UI didn't scale well with the # of antennas). We delived a new standalone GUI, which reads from DataCapturer relational database, and is based on Netbeans RCP. It provides a foundation to continue improving this tool. My assessment: I would say that QuickLook is being maintained, although improvements could be coming slow.

tmcdb-explorer This tool came from OBOPS with resources (.5 Steve Harrington), until we lost him. Finding a replacement proved difficult. SW deployment side is in the “limbo”. Alessandro agreed on taking over once the tmcdb-explorer has been divided on different plug-ins. This will take ~2 months of work. The hardware side, on the other hand, has been maintained. We have delivered several enhancements, including versioning improvements, tools to maintain the configuration of BACI properties, updates to account for library changes, etc. My assessment: We have been given a good level of support for the HW side. We haven't been given a good level of support for the SW side (invisible to science).

Control GUIs The Array Status GUI has been maintained. We have received help from Emanuel, who has delivered several improvements. The Antenna Status & Device GUI need work. On the other hand, they are not very much used, I believe. We recognize the need of providing better GUIs for diagnosing hardware problems and we have plans/ideas for this. The total power GUI. It was maintainance mode, but there is a bug that we still need to investigate. It's currently unusable. The amplitude GUI. This was developed by Bill Dent. It's outside Control, but I've heard that a request to include it into Control could be in the making. My assessment:  Array Status GUI is fine.  We need to fix the problem with the total power gui.  We need to improve and complete the Antennna & Device GUIs. Given that many operations can be done scripting with CCL, this can probably wait.

OMC Reloaded Besides QuickLook refactoring, this task has received relatively low priority. Emilio has requested that several tasks and scripts currently performed by the operators during the system initialization be moved into Control. This is planned for this period. My assessment: we'll be working on this during this period.

CorrGUI Developed originally as an engineering GUI, to be used during construction to test the correlator software. It was adopted by science and operations as well, for the lack of an alternative. Control got away during some time arguing that a tool like this should be in the scope of QuickLook. We can't make this point anymore because QuickLook was added to Control's scope :-) CorrGUIX? My assessment: not given high priority until now, there's some relatively small improvements that we can try to squeeze in during this period.  We just decided that CorrGuiX is not in OBOPS scope. We'll consider the prototype when we discuss new requirements with science.

More scope coming? The Dashboard could require some modifications in the TMCDB. SOS/OSS. Anything else?

Do we have a problem? If we do, I see three options:  1. We can wait 6 months. In this case we can assign freed resources by the end of the year: Jorge Avarias' scheduling load could be decreasing. Matias returns to Control/Correlator from APP at the end of the year.  2. We can't wait 6 months, but we are willing to descope other areas. What is more urgent. What do we descope?  3. We can't wait 6 months, we can't descope other areas. We'll need more resources. What resouces? (Note that even in the case that we get more resources, there's still a learning curve for a new developer.)