Changes from FS9

Both non-VGOS and VGOS operations are supported by the new version. Previous installations of the main (non-VGOS) branch will need to have some new local control files added.

The most significant change for users is that previous main branch users will find that input is case sensitive, as it was already in the VGOS branch.

The new version should run on 32-bit systems that currently support the FS (we support as far back as FSL8, we have not yet been able to test with FSL7 or other even older systems), as well as on 64-bit systems. The Converting to a 64-bit System document contains instructions for transitioning to a 64-bit system.

The key change to the source code to make this compatibility possible is removing use of longs as 32-bit ints in C, particularly in fixed length data structures. Note that some system calls do require longs. A tool, unlongify was developed by Dave Horsley to help convert the FS code. It is available to help convert station code. Its use is described in the Conversion of C code sub-step of the Converting to a 64-bit System document.

A second important issue is that pointers and time_t variables in C are 64-bits on 64-bit systems and 32-bits on 32-bit systems. Care must be taken if these are passed back to FORTRAN callers or used in fixed length data structures.

The FS source is now managed using git and github is used for distribution. The source code is now under the GPL3 license.

The details of the model used for FS releases under git are described in the Release Model document.

We expect updates in the future to require fewer steps, typically less than in FS9 updates. This is in part due to the fact that distributing the FS via github will make it easier to have smaller incremental updates instead of having to collect lots of changes for infrequent updates.

This change increases the importance of not modifying the /usr2/fs directory tree since such changes will make it more difficult to simply pull updates to install bug fixes and new features.

Hopefully, this change will make the update notes easier to read and navigate. Among other improvements, there are clickable links to other sections within a document, as well as to sections in other related documents, and a clickable table of contents. The major points of the change are:

The go program emulates a facility of the RTE operating system that was used to support passing control from SNAP back to an external program (typically aquire, fivpt, holog, and onoff) after it had suspended itself to wait for FS commands to be executed. The program was renamed to rte_go to make room for the go compiler, which is now being used for some software.

Instructions for updating local .prc files for this change are included in the Convert from go to rte_go sub-step of the Update .prc files step of the Upgrading from an FS9 version section of the FS 10.0.0 Update Notes document.

These changes include support for encrypted access to cddis, support for other data centers, respecting skedf.ctl, and answering optional drudg prompts for geodesy schedules. Please see the FS 10.0.0 fesh Changes document for full details.

These changes introduce new functionality to fsserver, including an FS log stream, as well as simplifying some use cases. Please see FS 10.0.0 fsserver Changes document for more details.

This allows the geometry and other parameter of the FS help display xterm to be controlled locally.

This maintains consistent window naming for agreement with existing documentation. This only affects bash users.

Previously setcl only checked for this issue (which is due to use of 32-bit arithmetic in the time handling code), if the time model was not computer. In principle, when the model is computer there is no need to check for this issue. However, since the time is still managed with the same 32-bit arithmetic (on both 32- and 64-bit systems) as for the non-computer models, it is still necessary to check. Not doing so was an oversight. The result was that there were no warnings of an impending 248 day time issue if the model was computer. This is now fixed (closing #56). Thanks to Richard Blaauw (WSRT), and subsequently Jon Quick (HartRAO) for reporting this.

This change is to avoid accidentally closing an active procedure or schedule file if the new one specified in the proc=…​ or schedule=…​ commands, respectively, does not exist or has incorrect permissions (closing #45). Previously, if the new file did not exist, or did not have the correct permissions, the old file would still be closed. Thanks to Jon Quick (HartRAO) for pointing out this inconsistency.

There is a now a -t …​ time-out option. If the command being run by popen has a time-out feature, it is generally better to use that command’s feature. See help=sy for more details.

There are very few cases in the code where a procedure library is closed; one was overlooked in the previous fix of this issue in 9.13.1. This case could happen if the schedule that was opened was named station, which would lead to the automatic closure of an already open schedule procedure library (there cannot be a station schedule procedure library since station is already the station procedure library).

This fixed a benign and spurious error message if a log was kept open past the end of the year and any procedures that had last been logged in the previous year were executed again (closing #23). Thanks to Eskil Varenius (Onsala) and Alexander Neidhardt (Wettzell) for reporting this.

This bug caused errors from antcn to be ignored for only these commands. It has been fixed (closing #82).

This was caused by inject_snap not implementing the new linkage that was added for fserr. To correctly retrieve the error message would have required making a new interface to fserr or subsuming it into a library routine that both ddout and inject_snap could use. It was not possible to do either in the available time. Instead inject_snap was modified to output the error without the message, but pointing out that the message can be found in the log and display. This is covered in more detail in issue #50. Thanks to Dave Horsley (Hobart) for reporting this.

Previously, it reported the error as being in the following "" line.

The example sked.ctl file incorrectly identified the lo_config keyword as if_config. This has been fixed (closing #81). It is recommended that you check and, if needed, update your local copy in /usr2/control/skedf.ctl appropriately, including the comments.

This is accomplished by including the /usr2/fs/include.mk file in every Makefile except for drudg, its libraries, and third_party/. The scheme is opt-in so it is not necessary for every program or station programs to participate. An explanation of the new scheme is provided in /usr2/fs/misc/fs10_makefile.md.

For programs that are opted-in, the most significant consequence of this is that a make at the top-level will re-compile anything that depends on a library or include file that has changed. Since drudg has not yet opted-in, updates to it, and its libraries and include files, will require remaking all of the libraries and drudg to be sure they are consistent. The drudg program has its own separate ecosystem within the FS source tree, consisting of the skdrincl/, skdrlnfch/, skdrutil/, vex/, and drudg/ sub-directories

The latest version of the server may not make successfully on some older Linux distributions such as FSL7. To help users in that situation, an option was added to disable inclusion of the server by setting the FS_DISPLAY_SERVER_NO_MAKE environment variable before make-ing the FS (partially closing #76). Follow the steps below to remove the server.

This is defensive in case local variable are changed to being automatic. The NOVAS routines seem to require static variables.

This was a long standing but benign error in the misc/fsinstall script.

As was the case for the VGOS branch, input from the operator, schedules, and procedures is now case sensitive. This change should present no difficulties if all normal input is in lower case. All SNAP commands and most parameters are lower case.

The change was made because in some cases it necessary to send upper or mixed case input to devices and other computers from SNAP commands. For MAT and GPIB communication, all communications sent to the devices is still mapped to upper case.

The biggest consequence of this change is perhaps that strings sent in antenna=…​ commands to the antenna are not by default mapped to upper case. If this an issue for your antenna, it may require changes to your antcn program. This is covered in the Case sensitive strings in antenna= commands sub-step of the FS 10.0.0 Update Notes document.

This was added to avoid logging very large amounts of data for RDBE systems if the schedule ends or is halted while tpicd is recording data i.e., when data_valid is on. It is probably beneficial for all back-ends, so has been made a general feature. Data can still be logged when a schedule is not running using tpicd=yes (which does not depend on data_valid).

Currently this is only supported for RDBE racks and Mark 6 recorders. Please see the Parallel command execution sub-section of the FS RDBE support document and the Parallel command execution sub-section of the FS Mark 6 support document for more details.

This support does not provide the complete command set and functionality usually provided by the FS for a rack. However, it is sufficient for normal FS operations for VGOS observations if the schedule procedure library is provided by a specially crafted .skd schedule file (see the $PROCS block change in the drudg changes relative to the main branch sub-section below for more details).

The details of RDBE features are described in the FS RDBE support features section of the FS RDBE support document.

This support does not provide the complete command set and functionality usually provided by the FS for a rack. However, it is sufficient for normal FS operations for VGOS observations if the schedule procedure library is provided by a specially crafted .skd schedule file (see the $PROCS block change in the drudg changes relative to the main branch sub-section below for more details).

The details of DBBC3 features are described in the FS DBBC3 support features section of the FS 10.0 DBBC3 support document.

This support does not provide the complete command set and functionality usually provided by the FS for a recorder. However, it is sufficient for normal FS operations for VGOS observations. (see the Mark 6 change in the drudg changes relative to the main branch sub-section below for more details).

The details of the FS Mark 6 features are described in the FS Mark 6 support features section of the FS Mark 6 support document.

This was originally developed for Mark 6 recorders in the VGOS branch, but has now been expanded to support Mark 5 recorders as well (closing #61).

To support VGOS operations with two DBBC2s, limited support for a second DBBC2 was added. This consists of the low-level device communication commands dbbc2 and fila10g2 and time and configuration setting of a FiLa10G attached to the second DBBC2 with fmset.

This support is sufficient for normal FS operations for VGOS observations with two DBBC2/FiLa10G units if the schedule procedure library is provided by a specially crafted .skd schedule file (see the $PROCS block change in the drudg changes relative to the main branch sub-section below for more details).

A second instance, dbbc2, of the DBBC2 control program, dbbcn, is used for communication with the second DBBC2. The dbba2.ctl control file is used for the second DBBC2.

This allows leading spaces in parameters that are parsed as strings to be ignored, as they were already for integer and real numbers. Since FORTRAN commands already had this feature, it should be universal now.

This change was made so that the last output from a command will always be the error message, if an error occurred. This should make the error more visible when the command also produces non-error log responses. This is particularly import for parallel execution commands for RDBE racks and Mark 6 recorders, but should be beneficial in general.

Previously the responses were handled by the general processing (in boss) which did not remove these characters. Instead the responses are now processed with the code that would handle this if there were no error, which does remove these characters.

The order of operations was changed to provide better fractional accuracy for very large numbers of samples.

In chk_time/:

This utility was developed by Jason Soohoo (Haystack) as vgos-msg-gui.py. It is an RDBE oriented version of the FS msg utility for sending operations emails. Originally it ran on a different back-end computer. It was ported to the FS computer, expanded to provide pointing data, and generalized to support more systems. For more informaion, please see the rdbemsg utility sub-section of the FS RDBE support document.

The scnch window was initially developed for Mark 6 recorders. The form has now been generalized to cover Mark 5 recorders as well (closing #61).

The s_client script should be used to replace other similar, new but now deprecated, TCP scripts from the VGOS branch: be_client and mcicn.

The s_client script was already present in both the main and VGOS branches. It is a generalization of the be_client script written by Chet Ruszczyk (Haystack). Errors are reported as lg -1 errors in the log if the FS is running. The details on its use are available from help=sy.

This script is intended as a tool to allow stations, and schedule writers, a way to update schedules for changes in the ifdbb procedure used by VGOS stations, particularly those with RDBE back-ends. For RDBE stations, the attenuation used in the signal chain, which is set by the schedule, depends on the observing mode being used and the conditions at the station. The provides a way to incorporate needed changes into schedules. If the script is run without other command line arguments, it will output “help” information.

Thanks to Eskil Varenius (Onsala) for reporting that this was missing.

Since these external programs do not depend on the FS, they can continue running (detached) after the client is closed.

The instance of the program is now correctly reported. It can be dbbcn or dbbc2.

Error messages that should refer to the active_rdbes and active_mk6s commands were corrected to no longer incorrectly refer to the rdbe_active and mk5_active commands, respectively.

For 64-bit use of FORTRAN, eight-byte integers are needed to support some calls in the VEX library. As a result, drudg and its libraries are configured to automatically use four byte integers for 32-bit and eight byte integers for 64-bit. The rest of the FS uses four byte integers for both. This made it necessary to give drudg it own version of lnfch/, in skdrlnfch/.

The drudg program source is maintained external to the FS. For each drudg update the source in imported into the FS git repo for distribution with the FS. This does not provide the same level of tracking as having drudg itself in git but it is still useful.

Several previously uninitialized variables are now initialized. As part of this implicit none was added to all FORTRAN routines that did not have it before, except for xat.f.

Previously at the end of line, the number of passes and the tape length were listed. Since there is no tape support, these fields were replaced with the recorder type.

Fixed bug in reads.f.

A particular error in the mask format intermittently excited an uninitialized variable bug. Thanks to Beppe Maccaferri (Medicina) for reporting this. He discovered it while testing with r1971.skd (which was not an experiment that included Medicina).

Previously it has to be the first block.

This was broken in the implementation of staggered start for FS 9.13.0 and has been restored.

drudg provides effective, but not complete, support for broad band (VGOS) systems with .skd schedule files. The support is not complete because the FS commands for the broad band systems are under development. As a result, drudg does not currently generate the schedule procedures. Instead they are provided verbatim by the .skd schedule file. Additionally, drudg only provides preliminary support for Mark 6 recorders (see the Mark 6 recorder support change below) for use with RDBEs. The features for broad band support are:

The drudg Mark 6 support is selected by using the Mark6 recorder type in drudg. Currently this is only for use with RDBE racks. It is implemented using low-level mk6 device communication commands in the .snp file. These are direct commands to the recorder using its communication protocol. It is assumed that the recorder had been initialized and modules mounted and grouped before the schedule starts. drudg inserts commands at the following points for each scan:

This allows schedules to include a fixed amount of additional wait for buffering per station. This seems to be needed for Mark 6 recorders in configurations that otherwise would require no buffer time for disks that are slower than nominal.

The size of the GB being recorded in mk6=record=…​ commands had the same issue in the VGOS branch as well. This was also fixed. This error had no impact since the value is only used by the recorder to determine whether the disk module has enough room for the recording and the Mark 6 modules were not being used near their capacity limit.

This makes schedules more useful with other recorders, particularly none (which is used for single dish tests).