We'll meet tomorrow in ER245 at 10am.
The consensus seems to be that the next step is to aim for a concrete list of what we would like a developer to do (he relation to CASA follows from that). To help frame things, here's a rough compilation of expected typical ALMA analysis, with commentary for a few specific cases:
Thanks to Crystal & Mark for the input here and feel free to add your own notes to the page. Of course CASA can do many of these things already using the viewer, a combination of of viewer and tasks, or the toolkit and this functionality is also available in other packages.
1) Should we be tackling the "line forest" problem head on?
2) If not what tools are most important to help with this indirectly?
3) What is our relative prioritization of data exploration vs. analysis? (for example: basic 3d source finder -> text vs. an interactive line fitter)
4) Inside each category which capabilities are a disaster if they aren't there by cycle 1?
5) Are there areas where other groups are already putting effort that we would be foolish to duplicate?
6) How long would it take to implement a sampling of these tasks? (let's again use the example of a basic 3d source finder and a line fitter)
7) For non-gui applications how important is working within CASA?
8) Where is professionally written code important? Where are user-driven tasks more appropriate or sufficient?
9) Details of discussing non-image-cube outputs and inputs? Related ... interface with external packages.
Notes from the Meeting:
- There appears to be consensus that a late entry into the "dense spectrum to physical conditions" race is a poor idea. This was noted to require as much scientific as coding expertise.
- The intermediate product of line identification and profile fitting in a spectrum with many (relatively unblended) lines had support to be achievable and more developer oriented.
- The spectral line browser was repeatedly called out as an area in need of improvement on both stability and functionality.
- No significant discussion of other viewer capability one way or the other.
- Effort for cube-side viewer improvement is scattered and low priority, with this "fourth or fifth" on Darrell's list.
- Suggested that cube-side improvements are not likely to be done without additional person-power.
- There are unfilled (viewer-related?) European positions. These have been vacant for several months.
- Skill-set related notes:
- There is a push to hold a community workshop to collect community "wants" and spur community effort
- There may be differences among the partners regarding the appropriateness of allocating development funds to tools that do more than browse data.
- What are the expectations for the European developer positions? This seems relevant given the rather long timescales for a NAASC hire.
- We concretely discussed only the spectral line browser when discussing viewer functionality. Is there a consensus for additional functionality?