 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 1367 |
|
T.J. Cornwell, NRAO
2000 December 5
In this document, we report on the work accomplished in this development cycle. As is our standard practice, the work followed a development plan (AIPS++ Note 234 drawn up and circulated at the beginning of the cycle. The goals for this development cycle were: i) to achieve greater scientific completeness in the package; ii) to expand the user base for the capabilities that currently exist; iii) to meet time-critical local consortium priorities where AIPS++ is in the critical path for instrument use, and iv) to explore automated and pipelined imaging solutions.
The major work this cycle was the support of the first and second public releases (version 1.2, 1.3), and the preparation and issuing of the third release ( version 1.4). There was much new functionality in this third release. The most notable new capabilities were in single dish processing, image analysis, and in synthesis processing. The single dish environment, dish, has been reworked to be command line oriented instead of GUI oriented. This allows certain significantly more sophisticated processing to be scripted than was possible before. The image analysis capabilities have been significantly extended by the addition of source finding and fitting functions. The synthesis processing has been extended through calibration and editing. This allows end to end processing of data from the VLA and potentially from all consortium telescopes. In addition, we continue to support other activities such as the GBT commissioning.
The most notable achievement of development cycle 1.4 was the completion of end to end processing of VLA data as demonstrated in the mosaicing of Orion Nebula performed by Debra Shepherd. In Figure 1, we show the resulting image:
dowait := T;
#
# Fill from a disk file containing a VLA export file
#
include 'vlafiller.g';
ok:=vlafillerfromdisk(filename='/aips++/data/nrao/vlafiller_test/dstst.vla',
msname="orion.ms",
overwrite=F,
project="DSTST" ,
bandname="X",
verbose=F,
async=F);
#
# Do the obvious flagging: autocorrelations, quack, known bad antennas
#
include 'flagger.g';
myflagger:=flagger(msfile="orion.ms" );
ok:=myflagger.auto();
ok:=myflagger.quack(scaninterval="5.1s" , delta="10s", trial=F);
ok:=myflagger.setantennas(ants=21);
ok:=myflagger.timerange(starttime="21-SEP-2000/11:15:48" ,
endtime= "21-SEP-2000/13:38:18" ,
trial=F);
myflagger.done();
#
# Set the fluxes for the flux and phase calibraters
#
include 'imager.g';
myimager:=imager(filename="orion.ms" );
ok:=myimager.setjy(fieldid=1, spwid=-1, fluxdensity=-1.0);
ok:=myimager.setjy(fieldid=2, spwid=-1, fluxdensity=-1.0);
myimager.done();
#
# Solve for the gains and apply
#
include 'calibrater.g';
mycalibrater:=calibrater(filename="orion.ms" );
ok:=mycalibrater.setdata(msselect='FIELD_ID in [1,2]');
ok:=mycalibrater.setsolve(type="G" , t=300,
table="orion.gcal");
ok:=mycalibrater.solve();
ok:=mycalibrater.fluxscale(tablein="orion.gcal",
tableout="orion.ref.gcal",
reference='0518+165',
transfer='0539-057');
ok:=mycalibrater.setdata(msselect='');
ok:=mycalibrater.setapply(type="G" ,
table="orion.ref.gcal" ,
select="FIELD_NAME=='0539-057'" );
ok:=mycalibrater.correct();
mycalibrater.done();
#
# Flag outrageously large points
#
include 'flagger.g';
myflagger:=flagger(msfile="orion.ms" );
ok:=myflagger.filter(column="CORRECTED_DATA" ,
operation="range" ,
comparison="Amplitude" ,
range='1e-6Jy 1e2Jy',
trial=F);
myflagger.done();
#
# Make an MEM mosaic image.
#
include 'imager.g';
include 'measures.g';
myimager:=imager(filename="orion.ms" );
ok:=myimager.setimage(nx=600,
ny=600,
cellx="2arcsec",
celly="2arcsec",
stokes="I" ,
doshift=T,
phasecenter=dm.direction('B1950', '05:32:50',
'-05.25.00.000'),
spwid=[1, 2]);
ok:=myimager.setdata(spwid=[1, 2] ,
fieldid=[3, 4, 5, 6, 7, 8, 9, 10, 11] ,
msselect='');
ok:=myimager.weight(type="briggs" , robust=-1);
ok:=myimager.setvp(dovp=T, dosquint=F);
ok:=myimager.regionmask(mask="orion.mask",
region=drm.box([215,215], [385, 385]));
ok:=myimager.mem(algorithm="mfentropy" ,
niter=60,
sigma="4mJy",
displayprogress=T,
model="orion.mem" ,
mask="orion.mask" ,
image="orion.mem.restored" ,
residual="orion.mem.residual" );
myimager.done();
#
# Display the image
#
include 'image.g';
myimage:=image("orion.mem.restored");
myimage.statistics();
myimage.view();
The necessary script is therefore simple and compact.
In Single Dish support, Jim Braatz, Joe McMullin and Bob Garwood continue to focus on support of the GBT and development of the dish environment for general single dish analysis in aips++. There continue to be regular visits by Garwood and McMullin to Green Bank and Braatz to Charlottesville. Braatz has primary responsibility for GBT support while McMullin has primary responsibility for dish development. There was only minimal contact with the Arecibo group, primarily at the end of this development cycle.
Most of the work this cycle was focussed on migrating all of the single dish software to work with version 2 of the MeasurementSet. This includes the gbt fillers, the sdfits conversion tools, the sditerator and sdaverager tools, dish, and the GBT commissioning tools. Significant changes where made in each of these areas in order to write to and read from version 2 of the MeasurementSet. At the same time, the contents of the sdrecord data container were modified to make better use of the AIPS++ measures. This change also impacted the commissioning tool and dish.
The Green Bank tipper software was reevaluated and rewritten by Braatz. Braatz continued to support GBT mockup users. The mockup was dismantled at the end of this development cycle in preparation for GBT acceptance and commissioning during the next cycle. Several improvements were made to the commissioning tool.
Dish work, in addition to the changes related to the new sdrecord and changes in the sditerator, was focussed on making dish a true aips++ tool and improving the dish CLI. Dish is now recognized as a tool by the toolmanager. The CLI was completely rewritten to be more intuitive in the setup of parameters for each operation and to be easier to use with the scripting tool. This work was prompted, in part, by feedback from users at Arecibo.
In Synthesis in keeping with the fundamental objectives of the development cycle, a strong overall emphasis was placed on higher-level synthesis applications, and in adding scientific features in areas where they most aided end-to-end reduction. The focus remained on connected-element reduction, although important VLBI development was scheduled in this development cycle in keeping with the planning priorities in this area. The high-level application development was complemented by a significant effort in user testing and public outreach. (See below)
At the highest level in synthesis development this cycle, a focused effort was made to enhance the access users have to integrated synthesis applications, formed by combining low-level synthesis toolkit capabilities as more powerful, high-level tools. This process of vertical integration was pursued on several fronts, including large composite applications (map.g), tools for guided or assisted data reduction (imagerwizard.g, mosaicwizard.g), and in expanding the scientific functionality in the automated GUI system (toolmanager) and in other separate custom GUI's, such as visplot.g. At the intermediate, and lower levels in the synthesis system, signficant work was scheduled this development cycle, balanced against the higher-level integration effort. The primary infrastructure change concerned the full implementation and migration to the second revision of the MeasurementSet (MS) data format (Kemball and Wieringa). This data format was adopted earlier after discussion within the consortium, and provides improved support for combined single-dish and synthesis data, advanced synthesis development and VLBI support. It also makes several general changes proposed since the adoption of MSv1. All fillers have been migrated to MSv2 with the exception of the BIMA filler. A MSv1 to MSv2 converter was provided by Wieringa and Badia as an aid in the transition.
In the area of general filler development, continuing improvements were made in several areas including the VLA (Marson) and ATCA (Wieringa and Badia). A prototype MERLIN filler exists (Maguire), and will be publicly available in v1.5. Other fillers were updated in the course of their migration to MSv2. The UVFITS filler was improved, and an initial FITS-IDI filler, required for VLBI, has been written (Maguire).
Calibration work has been actively continued in this cycle. The primary focus has been on improving optimization for greater speed and efficiency, in testing convergence properties using simulated and real data, and in adding new capabilities and infrastructure. A thorough review of all convergence issues was conducted, and new simulated data tests have been added to calibratertester.g and the higher-level test tool, assay.g. The speed of the calibration solver has been improved significantly. A new pre-averaging mode is also available for all calibration solvers, targeted primarily at improving coupled or iterative instrumental polarization solutions. Work has continued in the area of ionosphere correction (Smirnov), and the integration of this code into the calibrater. It makes use of a global empirical ionosphere model known as PIM, which will later be supplemented with GPS and other local ionosphere data. The global data system implemented by Schiebel has proven very useful in supporting larger test datasets in all areas for synthesis.
Imaging development has continued in this cycle (Holdaway and Cornwell). This has included work on optimal-sized FFT's for mosaicing, algorithm refinement in deconvolution in general, and in improved integration of deconvolution algorithms and imaging contexts. Several key mosaic observations have been imaged in AIPS++, to demonstrate the mosaicing capabilities. An example Glish script which performs end-to-end reduction of a sample VLA dataset has been checked into the AIPS++ system for general reference. We intend to add supplementary scripts of this type for other datasets, which either demonstrate end-to-end reduction or specialized imaging capabilities. Work has also continued on the AIPS++ simulator (Holdaway), with work aimed at supporting pointing and other more advanced errors.
Image analysis capabilities were expanded by
In the Infrastructure area, work continued to support underlying applications development.
In Glish the ongoing work to memory leaks which arise from reference counting of values in Glish was finished and merged with AIPS++ development. Subsequent testing indicated that, while this work was successful, some work is still required both in terms of performance and memory leaks in specific cases. The changes which were integrated and tested, however, brought the amount and rate of leaks to a level which is manageable as part normal development.
In addition, other minor bugs fixes and additions were made. Some of which are seen by end users of glish, e.g:
Many other defects which resulted in no visible change to the user were also fixed.
In Parallelization, the principal effort is aimed at providing data reduction capabilities for the most demanding computational problems in radio astronomy. This infrastructure is being developed in a partnership with NCSA as part of the Alliance program, and forms part of the regular AIPS++ system.
The current focus is both on expanding the existing parallelization and high-performance capabilities, as well as in demonstrating them for selected key science projects. Building on the second revision of the parallelization infrastructure, developed for v1.3, a key focus of the development in v1.4 has been the implementation of a fully parallelized wide-field imaging (3-D) application (Golap and Kemball). This involves parallelization of several operations per imaging facet, including PSF generation, visibility prediction, and image formation. Progress in this area has been good, and was described in a poster paper at ADASS X in November, 2000 (Golap et al). This capability is targeted at several key science datasets. This work has involved a significant investigation of multi-process I/O in AIPS++. Several issues in this area were identified as a result of careful analysis, and changes have been agreed in the Table system to support the I/O methods needed for applications of this nature. A deeper investigation of fully parallel I/O is also underway (Young). The remaining technology area which has received time during this development cycle is that of the NT port of libtrial and libaips, completed in the main by Paulo Cortes. This will be carried forward to allow a test parallel application to be run on an NT supercluster. To build on the existing NT work, a migration proposal has been drafted (Young) which proposes how these identified changes might be moved into the main AIPS++ code distribution. This process will be considered as we go forward.
Doug Roberts left the AIPS++ parallelization effort in this development cycle. His responsibilities have been assigned to several individual developers, but new members (Cortes and Sarma) will help in this area in development cycle v1.5. Parallelization will retain its priorities and goals as we go forward, but an increased focus on Linux clusters is planned, to reflect strong trends in the supercomputing community. This includes initiative targeted at the new 64-bit IA64 Intel processor, which is expected to be publicly available on that timescale. Improved progress in needed on the key science projects, and this will be a strong focus in v1.5.
In the User Interface, we improved the GUI by expanding the use of larger data items in the user interface to describe scientifically meaningful data. Examples include uv-data selection, antenna selection, and deconvolution algorithms and parameters, amongst others. These data items simplify the user interface, and allow the development of specialized, tuned GUI's for user entry of data of this type. The automated GUI system, toolmanager, was revised to allow full support for these newer data items. It was also improved in many other areas to enhance scientific usability, and in response to user group feedback.
The user interface work and vertical integration is not yet complete, and will continue as a strong focus in development cycle v1.5 (November 2000 to April 2001). Although there are some known deficiencies in the user interface, we find a high level of variance in user feedback and advice in this area, given the somewhat subjective nature of user interfaces in general. Given the high cost of GUI development, we will actively solicit the widest possible user commentary regarding the synthesis user interface before making major revisions, but will continue to make improvements which increase scientific usability and about which there issignficant user agreement.
It should be noted that the vertical integration does not compromise the toolkit architecture of AIPS++, which remains a fundamental driver for the package. It simply provides a high-level view for cases in which this is scientifically appropriate or useful.
In Documentation, by choice, no changes were made to the mechanics of generating documents. Some chapters were added to ``Getting Results in AIPS++'', and of course a lot of material was added to the User Reference Manual to accompany new features in the package.
Mark Holdaway took over the editorship of the AIPS++ Newsletter and considerably improved the layout and content.
In Management:
In Outreach, an active scientific user group was formed in collaboration with the Scientific Services Division of the NRAO at the AOC, who were tasked with using AIPS++ for the reduction of several trial datasets. Regular meetings were held with this group, who were encouraged to submit defects in the AIPS++ bug tracking system when using the system. They also contributed suggestions in general areas of the package including the user interface and documentation system.
This process increased local scientific expertise in AIPS++, helped to identify defects and improve the user interface to the package. This effort will be continued in subsequent development cycles, expanded to other NRAO and non-NRAO sites, and targeted at a broader audience.
Presentations concerning AIPS++ were made at a number of meetings, including the AAS in Atlanta, the ADASS meeting in Boston, and the Synthesis Summer School in Socorro. Copies of AIPS++ on CD ROM were distributed at all of these meetings. We also gave demonstrations of the use of AIPS++.
In the Quality Assurance Group, reviewing of a few classes was completed. Regular monitoring of the unit testing and glish assay tests by McMullin continues. The unit testing e-mail is now sent to the archived address aips2-testing. The overall testing was broadened to include all five canonical architectures (Solaris, Linux, SGI, HPUX, and Alpha). McMullin took over the responsibility for logging and shipping CDs. Brouw created a set of scripts to more easily move code around in the AIPS++ code tree.
In Visualisation, UV-visualization and editing has been considerably expanded in visplot.g (Cornwell), and have expanded the thin-path capabilities in this area signficantly. At the same time, uv-visualization work in the Display Library (DL) continues, and included the development of prototype infrastructure in the area of uv-data display (Minter). Final design considerations in this area were concluded in direct discussions with Barnes, Marquarding, Kemball, King and Minter.
With the release of version 1.4, we are now supporting three versions of AIPS++. The total number of users of AIPS++ is still rather poorly known. Although we ask people to register their copies of AIPS++, relatively few do as evidenced by the discrepancy between the number of registered sites and those sites submitting defect reports. Our current mailing list has roughly 270 names at academic or commercial locations and 150 names at private addresses.
As the number of users increases, the rate of defect submission has increased correspondingly. During each week we currently receive roughly 30 defect reports. For comparison, the rate one year ago was about ten defects per week. This means that the amount of time dedicated towards defect fixing has to be increased thereby reducing correspondingly the amount of time possible for development. As a result we have increased the amount of time dedicated to defect fixing to 30%.
Here we show the defect arrival and repair rates from May 1999 when we adopted the ClearDDTS program (replacing the GNATS program).
The next development cycle (v1.5), scheduled for release in April 2001, will retain a strong focus on scientific completeness, the provision of further high-level synthesis applications, and user testing and public outreach to the scientific community. The effort in pipelines and automated imaging will also continue. As indicated in the last report, we feel strongly that a coordinated effort in pipeline infrastructure would benefit the consortium as a whole. With the increasing maturity of the connected-element reduction capabilities, increased effort will also be devoted to VLBI. Work already done in this area includes the initial version of the FITS-IDI VLBA filler (Maguire), as noted above.
There are challenges for synthesis development as we move forward to release v1.5 and beyond. At the current stage of development, adherence and committment to the existing synthesis design framework is imperative, both to ensure code re-use and add capabilities in a coherent manner. These integration questions are more pressing now that we have moved beyond low-level infrastructure development to add high-level capabilities. Also, we have tried to schedule time for the development of instrument-specific Glish reduction scripts, both in v1.4 and v1.5, for all consortium sites. These scripts, and associated chapters in the Getting Results cookbook in AIPS++, are important guarrantees that the core synthesis development is meeting all consortium needs. This investment of effort at each site is vital in this regard.
As noted above, the most notable achievement of development cycle 1.4 was the completion of end to end processing of VLA data as demonstrated in the mosaicing of Orion Nebula performed by Debra Shepherd. This shows that a user can process VLA data entirely using AIPS++ tools. From the point of view of public acceptance of AIPS++ it is unfortunate that similar demonstrations have not been possible for other consortium telescopes. This must be one of the highest priorities for the next development cycle. It is clear from our experience that users have the varied reactions to use of the package. Some find the interface an obstacle, some do not. Some find the documentation too poor, some do not. It is our view that before making substantial changes in either one of these two areas, feedback from a wider range of users is vital. Therefore the emphasis for this next development cycle must remain on applications rather than a user interface or documentation issues. In particular, it is vital that at the end of this next development cycle end-to-end processing be possible for all consortium telescopes.
As is our practice, the detailed planning for release 1.5 was initiated following the end of this development cycle. Continuing the theme of scientific completeness we have emphasized the need for high priority applications development. Although some infrastructure developments are clearly needed in the medium term, these have largely been deferred until a subsequent development cycle. The exception is the initiation of a study of how best to replace the tasking system. The tasking system is responsible for the execution of applications inside AIPS++. The current second generation version was designed prior to the widespread acceptance of CORBA as a mechanism for distributed object invocation. A number of key deficiencies as seen by the user of AIPS++ are related to the current design. In this next development cycle, we will investigate how best to replace the tasking system with a framework based upon CORBA. Another reason for making this change is that it improves interoperability with other systems. This is particularly important in the context of of new telescopes such as ALMA.
The aggregate amount of time available for development in this and the previous development cycle is between 240 and 250 person weeks. Although this seems like a lot, only a limited amount can be achieved with this allocation. For our planning to be effective, it is vital that the time allocated actually be used as we planned. This of course is uncertain because of local problems that may take priority. This tends to be a strong effect for non NRAO developers since the NRAO developers are all 100% allocated to AIPS++. In the last development cycle (1.4), on average the non NRAO developers were roughly half as successful as at the NRAO developers at completing targets.
At the end of development cycle 1.5, scheduled for April 2001, we plan a meeting of developers inside the project similar to the meeting that was held in April 2000. At this meeting, we will consider how best to proceed on the related areas of user interface, documentation, and at the tasking system. We have found that the complicated interrelated topics involved are best addressed by face to face meetings. Such meetings also play a vital role in forming a cohesive group from geographically distributed individuals.
The Institute Formerly Known As NFRA will henceforward use its Dutch name (ASTRON) also internationally. All references to NFRA in AIPS++ should gradually be replaced by ASTRON.
The upgraded WSRT (and the JIVE correlator operations) continue to rely heavily on AIPS++. The on-line system (TMS) uses AIPS++ Tables, Measures and Glish, and MS2uvfits for data export. Data inspection is done with (at least) three different uv-data visualisation tools, which have been written locally with Glish and AIPS++ modules. The next step is a quality monitoring pipeline, which might evolve into a calibration pipeline. The latter is seen as an important way to demonstrate what AIPS++ modules are capable of, which should help to convince local astronomers to start doing their own data reduction with AIPS++ rather than with one of the older packages.
Ger van Diepen and Arthur Coolen have contributed mostly to the AIPS++ infrastructure, and between them they keep the local site going. Ger has also played a major role in preparing the various data converters for the transition to MS version 2. Oleg Smirnov has spent most of his time implementing synthesis applications, notably for ionospheric calibration. The latter has also 'exercised' the AIPS++ concepts for storage and distribution of auxiliary data. He has started work on the flagger. Tom Oosterloo uses AIPS++ (modules) for WSRT off-line processing, and Jan Noordam does the same for LOFAR/SKA design and simulation. Between them they promote and assist local astronomers in the use of AIPS++.
For release 1.4, the ASTRON contribution in FTE's was as follows: Ger van Diepen, 75%, Oleg Smirnov 80%, Jan Noordam 10%.
Oleg has continued his work with the ionosphere and PIM (Parametrised Ionospheric Model). He has mostly finished integration of PIM into AIPS++. Unfortunately, due to the large amount of dependency issues, we were unable to complete binding of the ionosphere modules into the synthesis package in time for this release, so, e.g., correction for Faraday rotation remains unavailable. This is something that we expect to resolve in the nearest future, once Oleg puts in some more "face time" at Socorro. Meanwhile, a lot of ionosphere functionality has quietly made its way into the trial package, so it is already available, for, e.g., modelling - if one knows what to look for.
Here is a more detailed look at Oleg has accomplished so far:
1. PIM has been integrated into the trial package. This has been a rather tricky operation, because PIM is essentially a very large stand-alone FORTRAN program, and one of the goals was to encapsulate it in such a way so as to minimize future effort when newer PIM versions are available.
2. The data handling issue has been by far the biggest obstacle. PIM uses a number of static databases (essentially model parameters; a black box to anything except PIM) in native binary format; it also requires a number of geodetic databases, such as IGRF, solar flux, interplanetray magnetic field, etc. The geodetic databases must somehow be kept up-to-date. In addition, applying GPS-based corrections to PIM estimates requires RINEX files and GPS ephemeris data.
Most of this data is available via the Internet. Wim Brouw has dealt with similar issues in his Measures modules. However, PIM-related data comes in such a zoo of formats and protocols (FTP, HTTP, even gopher), that Wim's scripts could not be easily applied.
3. Oleg has also implemented two DOs, which have made various ionosphere-related functions easily available from within Glish.
ATNF underwent some significant staffing upheavals this cycle which have impacted on our contributions to aips++.
Firstly, David Barnes left ATNF at the end of the previous cycle. However, David and his new institute (Swinburne) management kindly agreed that David would continue in AIPS++ during this cycle on a 7-week contract (funded by ATNF). To replace David we have hired Malte Marquarding who joined us towards the end of the cycle. My thanks to David for this and his other efforts in the last two years which have culminated in the Viewer tool providing high-level user display services. Welcome also to Malte.
Secondly, Mark Wieringa's time was severely reduced owing to staff losses elsewhere in the ATNF (the ATOMS OO on-line software project) requiring Mark to pick up leadership of that project so that delivery of the new Antenna Control Computers (required for the continued operation of the Compact Array and the MNRF mm upgrade) would occur. We offset some of this by contributing some of Frederic Badia (Narrabri computing) to pick up some of the things Mark was going to do. Fred has now left the ATNF.
Thirdly, Neil Killeen's time was impacted upon by the Australian Federal Government's decision to outsource its IT infrastructure. Neil is the outsourcing coordinator for the ATNF and this role takes significant toll, often at very short notice.
Our systems have been quite stable this cycle except for some continuing problems with the help system. We have installed the latest versions of the Purify products which now operate to some degree with the egcs compiler again. These products are not fully operational, but effective enough to be useful again.
David's time (7 weeks contract in total) was spent on
During the 1.4 cycle Wim spent 3 months in Socorro, in partial exchange for Ralph Marson who spent a year in Epping. Over the period Wim spent about 75% of his time on AIPS++ related issues.
(see separate QAG report)
Neil's time (60%) went on:
Malte joined the ATNF towards the end of this development cycle and had no specific targets in that time. His time (75%) went on
Mark's time (10%) was mainly spent on defects, email and system maintenance.
Fred's time (30%) was spent on
During this cycle, NCSA and BIMA had three people contributing to AIPS++. Ray Plante (the local manager) contributed at the 50% level, Dave Mehringer at 35% (the site installation manager, and Harold Ravlin at 60%. Doug Roberts, the previous local manager, left the project at the beginning of this development cycle; as a result, much of our time has been spent rebuilding local AIPS++ expertise.
The computer systems at NCSA include Linux, Solaris, and SGI IRIX machines. AIPS++ is primarily run on Solaris platforms for both development and end-user use. We recently added an SGI 4-processor Linux box for use with the BIMA Image Pipeline, now under development. The builds on SGI IRIX platforms continue to be stable, including the NCSA Origin system. We also experimented with an AIPS++ build on a preproduction Linux system based on the new Intel 64-bit Itanium processor; a full build is expected when the production system is delivered to NCSA in Spring 2001.
Ray Plante's has been shared between AIPS++ and managing our local pipeline development. Specific work has included.
Harold Ravlin has spent all of his effort developing an interactive fitting & regridding tool for calibration tables. Apart from some integration issues, a useful initial version was completed.
Dave Mehringer serves as the AIPS++ site installation manager.
At the beginning of the development cycle I visited Socorro where I learned the basics of developing within the AIPS++ environment. Upon returning to the UK I began work on a filler for the MERLIN array which has now been completed. Shortly afterward I was asked to begin work on a filler for the new FITS-IDI format, particularly VLBA data. Work is still progressing on this. Distributed approx 150 v1.3 CD-ROM's at the General Meeting of the IAU at Manchester in August.
The core NRAO group is now Braatz (75%), Cornwell (50%), Garwood (75%), Golap (75%), Holdaway(75%), Kemball(75%), King (100%), Marson (75%), McMullin (75%), Moellenbrock(75%), Schiebel (100%), and Young (100%). Golap and Young are funded by NCSA-NRAO collaboration. King is funded by the NSF visualization grant and we have one open position funded by that grant. Toney Minter left the group to take a more permanent position with the GBT project. Mark Holdaway will leave AIPS++ on February 1, 2001 to join the ALMA project where he will work on array design questions. We expect his involvement with AIPS++ to continue at a reasonably high level.
Jim Braatz' primary responsibilities are to manage the Green Bank installation of AIPS++, to support GBT operations, develop software for analysis of GBT commissioning and continuum observations, and to assist with single-dish spectroscopic applications. Specifically, Jim worked on the following tasks during this cycle:
Bob Garwood's primary responsibility is to oversee and contribute towards the single dish work in AIPS++. This work remains focussed on the DISH environment and the support of the GBT. His contribution in support of the GBT is primarily through the GBT fillers which convert the GBT FITS data files to an AIPS++ MeasurementSet. His DISH work involves the maintenance and enhancement of the data access tool (sditerator), the data averaging too (sdaverager) and the data conversion tools (sdfitstoms and ms.tosdfits). In addition to these duties, he is responsible for the maintenance and enhancement of the FITS classes and, as author and maintainer of the GUI guidelines, he spends some amount of time reminding other AIPS++ workers on the importance of following those guidelines. He is also the chief code cop and head of the QAG.
Over the past development cycle (April through September) he has done the following:
The last few months I have been mainly involved in the parallelization of the wide field imaging. This has taken approximately 70% of my time. A large chunk of that time was taken by debugging and understanding mainly the locking of tables mechanism and the FTMachine components. A summary of the parallelization effort:
The remaining of the time I've been doing some science data reduction
at P-band of a supernova remnant; in the process I've been testing
imager and calibrater on such data. I've been trying to understand
the problem of assymetric sidelobes at P-band at the VLA. I am
involved with a project trying to achieve sensitivity of 100
Jy. I'll be experimenting with the data once its observed in
December to try and implement something in AIPS++ to reduce the effect
of assymetric beams at P-band. I have also been thinking about the
ionospheric iso-planatic problem at low frequencies. This is a problem
that I may start tackling once I get the parallelization working
reasonably well.
I took over the task of editing the AIPS++ Newsletter, which basically consists of setting a schedule for the newsletter releases, figuring out what new work in the project is of general interest, bugging people until they submit, and throwing it all together for distribution on the web. We had a newsletter in August and also one in November, which details some of the new functionality in release 1.4.
I did some work on a second-order multi-scale deconvolution algorithm, implemented at the glish level, in which extended emission is imaged and deconvolved at very low resolution with large cell sizes. The low resolution model is regridded onto an image with smaller cells, and used for the starting model for higher resolution imaging. At each step, any desired deconvolution method can be used, but multiscale clean is the method of choice for the first step. This works especially well for multiconfiguration mosaics.
I wrote the mosaicwizard, which walks the user through setting up a mosaic image, by default performing a second-order multi-scale deconvolution. Of course, the user can set the parameters to do other sorts of deconvolutions as well, and the user can go straight to a full resolution deconvolution. Much of the mosaicwizard's work is written to the scripter, which the user can edit and rerun.
I fixed and improved the progress displays for maximum entropy, clean, and multiscale clean algorithms, for both the single field and multi-field contexts.
I have spent a fair amount of time working on the reduction of an 81 pointing VLA L band D array mosaic of the Galactic Center.
For development cycle v1.4 I have retained the following responsibilities: i) deputy project manager; ii) coordination of synthesis development; iii) direct calibration development; iv) coordination of parallelization; v) technical leader; and, vi) assistance in the release process as the patch controller. I have also spent time in user support and testing. The synthesis and parallelization work is described in the appropriate sections above. I have also attempted to allocate time for documenting and communicating information regarding coding and design assumptions in the synthesis system to a wider audience of developers in the consortium, to smooth integration and development of new capabilities. I played an active role in implementing MSv2, and in assisting in filler and application migration. I have also coordinated the new visualization development effort at the NRAO in AIPS++, which is separately funded and targeted at the visualization of large datasets. In v1.4, this has primarily concerned design questions related to uv-data visualization, and in End of document areas of responsibility transferred from David Barnes to new developers. I have drafted the development plans for v1.4 and v1.5 in collaboration with Tim Cornwell. We have also contributed a document describing software engineering practices within the AIPS++ project, which can be found as Note 237 in the AIPS++ documentation system. I have not undertaken any code review this development cycle, but have spent the standard allocation of time on defect correction (approximately 20 percent).
Jul - Sep 2000: (Absent Jul 1 - 21: USAR duty)
Joseph McMullin's main responsibilities are work on single dish applications within AIPS++ and help with GBT commissioning duties.
He is also currently serving as Chief Tester and also handles the aips2-request list, logging and shipping AIPS++ release CDs.
For the v1.4 development cycle, George Moellenbrock contributed as follows:
In the area of synthesis (and related) development:
In the areas of scientific utility and user interaction:
Darrell provided system support for AIPS++, aiding installations at many different sites, and also was responsible for all the Glish work described above.
In this section, we give the names of people in the various AIPS++ groups and the nominal fraction of time allocated to AIPS++.
Thus, in aggregate, we have 26 people contributing about 16 FTEs to the AIPS++ Project.
