3 On Friday, 07.10.1994 13:07

Contents of this section

3.1 Progress reports (cont.)

Progress reports continued with the last subproject, EMU 400.

3.2 EMU 400: Computing

Schilizzi asked Mujunen to present his views about the most appropriate approach that EVN should take regarding field system software that will be used at the upgraded MarkIV stations.

Mujunen began by pointing out the diversity of field systems currently in use at EVN stations. The following table was created at the meeting:


System name   Hardware  Op.sys.  DAR    Used at
-----------------------------------------------
NASA FS8.x    PC        Venix    MkIII  Westerbork, Medicina, Yebes
                                        Shanghai,
                                        apparently Urumqi, Simeiz,
                                        Hartebeesthoek
NASA FS8.x    PC        Venix    VLBA   Noto
NASA FS       HP1000    RTE      MkIII  Onsala
Darfs         PC        DOS      VLBA   Cambridge, Metsahovi,
                                        apparently Torun
Barfs         PC        DOS      VLBA   Pico Veleta
MK3PC         PC        DOS      MkIII  Jodrell
PCFS          PC        DOS      MkIII  Effelsberg
VLBA          VME680x0  VXworks  VLBA   Effelsberg (and VLBA)
PCASTR        PC        DOS      VLBA   Russia, app. Ussuriisk

All three variations of ``NASA FS'' share a common FORTRAN code base. ``Barfs'' is a variation of ``Darfs'' and also ``MK3PC'' shares much of Darfs Turbo Pascal code. ``PCFS'' is a unique program written in QuickBasic and ``PCASTR'' borrows most of its C code from NRAO standard ``VLBA'' station control software written in C. Some statistic comparisons between NASA FS and Darfs are presented in the text file ftp://bigbang.hut.fi/pub/emu/fsEvaluation1.txt .

Schilizzi summarized that what EVN would need is a consistent field system compatible with VLBA and VLBA correlator. He then went on to find a recommendation for the base of this system.

Schilizzi asked Mujunen about the consequences of EVN supporting the NASA FS which seems to be the most popular at the moment. Mujunen wanted to hear the opinions of Burgess as he has had good insight into original NASA FS code on HP1000s.

Burgess listed high cost, difficulties in station-specific code, antiquated source code, and the ``speed converter'' (a second PC) for VLBA MCB bus among the reasons against NASA FS with Venix. Mujunen added to that general maintenance difficulties caused by antiquated program structure that once was dictated by HP1000 limitations. He also described FS source code as ``fluffy'', meaning that the same functionality can be achieved with at least 80% less source code with modern tools. Unmanageable program structure and its fluffiness would most severy hamper introducing those new features that are needed for EVN to be ``VLBA correlator compliant''. Porcas reminded that the need for EVN modifications has been made clear in Friday's meetings.

Foley defended the FS by saying that although it is not bulletproof, it performs mainly ok. TCP/IP networking cannot be actually used in Venix because it can crash the system---very undesirable during a session. Burgess noted that any operating system is bound to have difficulties with PC hardware when I/O bandwidth is exceeded. (Editor's note: Apparently network software crashing the whole Venix system is not due to excessive I/O bandwidth. This problem has occurred in many unmature and little tested Unixen on PC hardware---even Linux used to crash with network-related causes in its early development versions in 1993.)

Mujunen then asked Graham whether the NRAO ``VLBA'' station system would be a viable alternative. Graham noted that it is suitable for VLBA DARs only and that it would like to have VLBA-style infra- and interstation infrastructure in its control. Graham also reminded the European stations with VLBA DARs that in order to use barrel roll in their formatters both new formatter firmware and the new Digital Switching Module are required---the latter is required only because the former won't run without it.

Porcas pleaded for reducing the current diversion of field systems.

Reasons for why a given system wouldn't be suitable as the recommended EVN system were found as follows:


System name   Reason
--------------------
VLBA          VLBA DARs only.
PCASTR        Adaptation of old buggy VLBA.
PCFS          Unique to Effelsberg.
NASA FS8.x    NASA vs. MarkIV modes, VLBA correlator?

Mujunen asked the meeting how they felt about NASA adding MarkIV features to the field system. Graham replied that he would expect all possibilities available in MarkIV formatter to be included eventually, but that he would be very surprised if VLBA DAR/formatter was ever completely supported.

Schilizzi then wanted to know whether we could run NASA FS on Linux. Mujunen replied that although this would relieve the cost factor, we would still face difficulties in adding the required level of compatiblity with VLBA.

After this Schilizzi asked Burgess and Mujunen about the consequences of EVN supporting Darfs which seemed to be the only option left on the list. They suspected that EVN support is needed as neither Darfs nor MK3PC are currently ``turnkey'' solutions that can be readily run at any station without additional work.

Action: Mujunen looks into Darfs, MK3PC, and---where appropriate---NASA FS source code and prepares a recommendation for EVN within three months. The expected way to proceed is to consolidate Darfs, MK3PC, and desired functionality from NASA FS into a new software package that can be run on PC hardware.

3.3 Miscellaneous items

Tsys measurements and phase calibration

Much in the same way as with providing GPS--H-maser time differences in machine logs, most EVN stations have problems with one or more of the following items:

  1. Only high-level noise diodes are available that cannot be switched on during tape passes, thus no Tsys values can be taken during a pass.
  2. Noise diodes cannot be remotely controlled by the field system computer. This prevents using all BBCs to get Tsys of all channels separately. Also this makes synchronizing Tsys measurements to schedules much more difficult.
  3. Resulting Tsys figures are not recorded in machine-readable form and if they are, they are not directly usable by PIs (=not in AIPS ANCAL format.)
  4. Sanity checks are not routinely performed on Tsys data---absurd values are offered to PIs.

Graham mentioned about a method of following total power output changes during the scans and estimating Tsys by assuming the effect of noise diode constant during the scan. This might help in case 1) of high-level noise diodes. When using VLBA BBCs automatic gain control must be taken into account and AGC value must be read in addition to TPI value---which addmittedly should be around 1.0 when AGC is in effect.

Action: ??? Somebody should verify whether this method would work. Graham? Nancy Vandenberg at NASA? Apparently unstable receivers would be problematic with this approach.

A short survey of different ways of getting Tsys info at various EVN station, requested by Mujunen, showed the following:


Station     Noise diode   Remote  Channels  Interval
----------------------------------------------------
Effelsberg  High-level    No      ?         ?
Metsahovi   Medium-level  Yes     All       BOP,EOP
Jodrell     High-level    No      1         ?
Onsala      ?             ?       ?         ?
Shanghai    ?             Yes     All       BOP,EOP
Westerbork  ?             No      1         10 secs

(BOP=Beginning of tape pass, EOP=End of tape pass, ?=not discussed)

Action: All VLBI Technical Friends: The aim of all EVN stations should be to provide Tsys information of each channel in 1--2 minute intervals in a machine-readable format useful to PIs.

Matching BBC passbands

This item was not processed in detail at the meeting. Schilizzi conveyed a message from Spencer that most of them came from the same factory but at least Jodrell has a few home-built ones.

Documentation

The meeting relied on that the different subgroups working on the upgrade will provide their own documentation of their own modules in professional manner. It is also a responsibility of individual teams to include appropriate and current Haystack documentation in their docs.

Jive hardware engineer?

Schilizzi brought up the idea of having a dedicated hardware engineer at Jive. The meeting discussed various ways (s)he could be useful in recorder testing etc. TWG felt that this subject should be brought to the EVN directors meeting.

Date of next meeting

The date of next meeting was left to Spencer to decide.

Action: Spencer to negotiate via email a suitable date for the next meeting.

Buiter announced that a MAT bus tester has been built at Dwingeloo. It is based on a Haystack design and can be made available if need for volume MAT testing arises.

3.4 Production note

This document is written using the linuxdoc-sgml DTD. SGML stands for ``Structured Generalized Markup Language'' and I chose SGML for this document because SGML is made specifically for translation to other formats. SGML allows you to specify the structure of a document---that is, what kinds of things make up the document. You specify the structure of a document with a DTD (Document Type Definition). linuxdoc-sgml is one DTD that specifies the structure for Linux HOWTOs and other docs. QWERTZ is another DTD; the SGML standard provides DTD's for books, articles, and other generic document types.

For further information about software used to process this document, the linuxdoc-sgml package by Matt Welsh, please refer to the text file ftp://bigbang.hut.fi/pub/emu/linuxdoc-guide.txt .

Next Chapter, Previous Chapter

Table of contents of this chapter, General table of contents

Top of the document, Beginning of this Chapter