Ubuntu 10.04 ssh DISPLAY problems

See this thread: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/434799

Getting sshd to run with -4 solved this problem, at last.

Using lwimager to predict visibilities

The following:

$ imagecalc in=foo.fits out=foo.img
$ lwimager ms=bar.ms model=foo.img operation=csclean niter=0 fixed=1 wprojplanes=128 mode=channel chanstart=0 nchan=8

...will populate the MODEL_DATA column with visibilities predicted from foo.fits with w-deprojection in effect!.

Replace nchan=8 with however many channels you have in your MS. Note that the frequency axis of your image needs to overlap with the frequencies of the MS (you can always edit the FITS header to make it so), if you're finding unfilled channels in your MODEL_DATA column, it's probably because of that.

Profiling the meqserver with oprofile

Oprofile docs here: http://oprofile.sourceforge.net/docs/

To profile kernel calls, an image of the kernel with debug info (vmlinux) needs to be installed. (You can also skip this step and pass --no-vmlinux to opcontrol instead, but then kernel profiling will not be available.) On Ubuntu, you can get this by adding the ddebs repository, then

$ sudo apt-get install linux-image-$(uname -r)-dbgsym

Start up the profiler like this:

$ sudo opcontrol --init
$ sudo opcontrol --start --separate=kernel --vmlinux=/usr/lib/debug/boot/vmlinux-$(uname -r)
Using default event: CPU_CLK_UNHALTED:100000:0:1:1
Using 2.6+ OProfile kernel interface.
Using log file /var/lib/oprofile/samples/oprofiled.log
Daemon started.
Profiler running.

NB: the --separate=kernel option is vitally important, otherwise each dynamic library and kernel call is profiled in total (as opposed to being associated with an application, which is what we want here).

Now do your stuff (meqbrowser, build tree, start job). Use

```
$ sudo opcontrol --reset
```

...to clear all profiling counters, i.e. when you really want to start profiling.

A quick report may be obtained by running:

$ sudo opcontrol --dump; opreport -l "*meqserver*"

Note that the profiler treats dynamic libraries as separate entities, so they must be included in the specification above. Fortunately, wildcards work.

A report including call graphs is obtained with -c. This produces a bunch of warnings, but the log is reasonable.

$ sudo opcontrol --dump; opreport -l -c "*meqserver*" >log

An annotated source report may be obtained via

$ opannotate --source --output-dir oprofile/ "*meqserver*"

Profiling data may also be dumped into an archive for later analysis, or compared to a previous archive dump:

   ### dump data to archive_name (a directory named archive_name will be created)
$ oparchive -o archive_name "*meqserver*"
   ### report on data from archive rather than from current session
$ opreport -l archive:archive_name
   ### do a differential report of archive vs. current session
$ opreport -l "*meqserver*" { archive:archive_name } {}

Building a release build with debug symbols

Since we really want to profile optimized code, it's good to make a release build with debug symbols. Bootstrap the build as follows:

$ Tools/Build/bootstrap_cmake release -DCMAKE_CXX_FLAGS=-ggdb -DBLITZ_INCLUDE_DIR=/opt/mpp/blitz/0.9/include/

Build AOFlagger

Andre Offringa's flagger can be downloaded here: http://www.astro.rug.nl/rfi-software/

Most dependencies are available on Ubuntu, except for log4cplus, which I had to download and build from here: http://log4cplus.sourceforge.net/. This follows the standard scheme of downloading tarball, unpacking, then doing:

$ ./configure --prefix=/usr/local 
$ make 
% sudo make install

NB: Andre's page recommends log4cplus-1.0.4, as the later 1.1.0 release seems to cause some problems. Binary packages that I needed to install were:

$ sudo apt-get install libxml2-dev libboost-date-time-dev libboost-thread-dev libboost-filesystem-dev libboost-system-dev libgsl0-dev libgtkmm-2.4-dev

Apart from that the make was fairly straightforward, as per http://www.astro.rug.nl/rfi-software/#installation.