Progress reports continued with the last subproject, EMU 400.
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.
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:
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.
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.
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.
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.
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.
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