fluxsclale: added the covariance matrix to the returned dictionary. Support for higher order fitting is essentially done, want to wait for covariance matrix work is merged to master before submitting PR for this. (TT)
Imaging
automask: CAS-11984 was ready to test last week, then Amanda found some issues. Fixed one of them, looking into another one. (TT)
Fixed a data path issue in tclean for CASA6 (TT)
Measurement Set
Temptative implementation Support SPW with different number of channels CAS-8352
NRAO Backend Development team: Pam, Christy, Jason (ASIAA).
Release 1.0 scheduled for December 21 (Friday). Will support raster images (multiple but not overlaid on same plot), per-channel and per-cube histograms, xyz profiles, animation, export to png. Contour images in progress.
This week: Adding cube histogram feature and fixing issues reported on GitHub.
Arrangements being made for F2F meeting in Cape Town January 23-29, 2019.
Plotms
After CARTA is released!
CAS-11501: 5.4.1 pipeline discovered showatm/tsky overlay bug, connect points change introduced this bug. Will be fixed before PR for master (CASA 5.5).
CAS-12136: CASAplotms (CASA6 standalone version) crashes on opening a file on OSX. Will be fixed for CASA 6.
CASA 6
Finished CASAplotms OS X app and Linux AppImage build
Still no visible, published PIP wheels
builds have been disrupted due to casacore and bamboo issues(?)
Many open questions that would benefit from a bit of discussion:
If we start using two or more separate repositories (casatasks, casatools, casa/code), what workflow will we use for branches and pull requests? Current PRs often touch two or more of these.
At a minimum, CASAviewer and CASAplotms will be developed and released independently. It could also be that the tools and tasks could be released on a different schedule. As we approach CASA 5 sunset, it does make sense to consider which workflow fits.
Old questions from earlier meeting pages:
EG: Can we run the C++ tests inside CASAtools?
No, currently only user facing APIs are built and tested. However, the build properties file produced by configure could be used as the basis of a more developer-friendly build avenue.
SC: Is the history of tasks, tools and tests preserved in the new bitbucket modules for CASAtools and CASAtasks?
Almost all of the C++ code, is shared between CASA 5 and CASA 6 so that history is available. However, the goal is to drop all of the files which do not actually go into building the supported deliverables for CASA 6. For all of the CASA 6 deliverables, only the object files that are require are built. After we know everything that will be in the release, we will be able to make decisions about code that is shared among the pieces, CASAtools, CASAviewer, CASAplotms, CASAfeather, etc.
FMP: How does/will CASA 6 handle task subparameter default values? Pipeline and user scripts are sensitive/depend on that feature.
subparameters will only be supported in the CASAlith, all-encompassing release of CASA.
The list of task tests that pass can be misleading.
All tests added since [sometime_in_April, unclear_date] are in principle (silently) missing from the casatasks repository.
Same applies to all updates done in tasks, helpers, recipes, etc.
The test were not converted from one snapshot. It was announced that it is the developers responsibility to keep the python tests and hand-coded task code in sync.
In the current casatools and casatasks repositories we seem to have lost all the repository history for all the casatools and casataks files. Also, the very first version/commit of files in CASA 6 seems to already include changes with respect to CASA 5.
Since when do we need to synchronize? This implies reviewing a large number of PRs. That's a very manual, very error prone review of untidy diffs. Huge risk of introducing regressions and "losing" pieces of functionality in CASA 6.
The only thing that is out of sync (or lost history) is hand coded python code.
Changes in tool names produce many lines of conflicts between CASA 5 and CASA 6. Has there been some discussion of the requirement to change tool names? Could this be separated into different commits?
The same XML interface specifications are use for CASA 5 and CASA 6, but changing a tool name will require many changes in both CASA 5 and CASA 6. Even for just CASA 5 it was also true that it required a lot of work. There has been no specific discussion bout changing tool names (AFAIK).