Jump Over Left Menu
- COMPUTING DIVISION REORGANISATION
- FRONT END TESTS OF THE ATLAS 10
- REGIONAL LIAISON MEETING BRISTOL
- Graphics Supplement
All systems have performed reliably during the last month with all user demands satisfied in terms of batch and interactive use. There have been some problems with access (caused by Memorex 1270 and PSE faults) which do not appear to have prevented users getting their work done. The Memorex problems have been cured but investigations are still continuing on the PSE.
This is the issue with the Graphics emphasis and there is a 12 page supplement from the Graphics Section. Major items of general interest include an overview of the FR80 replacement devices, GKS and Graphics on the Primes and GECs. The whole of this supplement was produced on the IBM 4250 which is one of the FR80 replacement devices.
There is an important article from Professor Hopgood announcing a major reorganisation of the Computing Division at RAL into two new Divisions. Unfortunately it is not possible to provide complete information on this until a few key issues are resolved. A full description of the new Divisions and their functions will appear next time.
The Computer Review Working Party Report has now been sent to Boards and to Council. The June meeting of Council included a preliminary discussion of the report and there will be a major discussion at the July meeting when the comments of the Boards will be available. It is anticipated that Council will make decisions on the Working Party recommendations in July. A full report of these recommendations and, hopefully, the Council decisions will appear next time. Meanwhile full discussions are being held in the various User Group Meetings and users are being invited to comment on the recommendations. A paper summarising the views of the RAL User Liaison Committee has been sent to the Working Party Chairman.
Mike Jane, Retiring Head of User Support Group
COMPUTING DIVISION REORGANISATION
The last few years has seen a significant and steady increase in the size of the Computing Division despite moving specific Board-funded projects to other Divisions. Consequently discussions have taken place concerning the possibility of splitting the Division into two.
The Central Computing Committee's Computer Review Working Party has recommended that:
- The mainframe computers at RAL should be run as a profit centre charging Boards for use.
- Infrastructure activities such as networking should be funded directly by Council.
- Control and Funding of the Interactive Computing Facility and the Single User System programme should be handed back to the Engineering Board.
The last recommendation provides the opportunity to split the Division between those projects funded directly by the Engineering Board and the rest, keeping both Divisions of a significant size.
From 1 July 1984 it has been decided to reorganise the Computing Division as follows:-
- Central Computing Division (Dr C J Pavelin) this Division is responsible for the mainframe service, infrastructure activities and administrative developments associated with the mainframe system.
- Informatics Division (Prof F R A Hopgood): this Division is responsible for the Engineering Board's interactive computing facility, single user system programme, the Alvey infrastructure and coordination/research in IKBS, Software Engineering and other related Alvey areas.
Fuller details including the structure of the Divisions will be published in the next issue.
F R A Hopgood, Informatics Division Head
FRONT END TESTS OF THE ATLAS 10
The Atlas 10 has been run in the front-end role on several occasions during the past few months for two specific reasons, firstly to investigate the MVT storage overwrite problem and secondly to determine whether it is a viable alternative to the 3081 in running the interactive CMS service.
MVT Storage Overwrites
These have occurred at a very low level for many years but increased dramatically to around 10 per week at about the time the new 3081 was installed last October. Unfortunately, a number of software changes had to be made within a very short time to support the new hardware. These were a new release of VM, the installation of VM/HPO (High Performance Option) needed to support more than 16 megabytes of memory and considerable changes in MVT to support 4K rather than 2K keys.
Since the problem appeared to be only in MVT, a lot of time and effort was spent on trying to find a bug in the 4K key software. When this produced no results and other factors, such as twice losing the VM spool, indicated that the problem might be elsewhere, a plan was devised for exonerating the various pieces of software one by one. This involved running the Atlas 10 as the front end because it could be run with or without VM/HPO and with either 4K or 2K key software in MVT.
Fortunately, the first test produced the desired result very quickly. The Atlas 10 was run with the 4K key software but without VM/HPO and the storage overwrites immediately disappeared, or at least dropped to their pre-September level. With a strong indication that VM/HPO was the guilty party the IBM faults database was scanned and a fix was discovered which it was thought might cure the problem although it was not very obvious why.
The fix was applied on 16 April and shortly afterwards the 3081 was reverted to the front end role. The storage overwrites have not come back and other problems such as HASP abends have dropped to a low, acceptable level also. Clearly the VM/HPO fix has solved the problems.
During the times that the Atlas 10 was run as the front end it was noticed (and monitoring data confirmed) that the CMS performance, particularly the response to trivial commands, was not as good as on the 3081. However, the 3081 had 32 megabytes of real memory whilst the Atlas 10 had only 16. Certainly the paging rate on the Atlas 10 was considerably higher and might well be a major factor in the difference.
Another factor was the maximum throughput on the channel to the paging device. On the 3081 this was 3Mb per sec but on the Atlas 10 it was limited to 1.5Mb per sec because of cross channel configuration restrictions. The recent acquisition of an additional channel processor for the Atlas 10 has removed these restrictions and allowed the full 3Mb per sec to be attained.
There still remained the difference in memory and in order to carry out a more realistic comparison we were fortunate in being loaned an extra 16Mb by ICL for one month. This was installed early in June and the Atlas 10 was put into the front end role on 18 June for a trial period.
The indication from monitor data for the first three days of this trial is that the response times for trivial commands are at least as good as on the 3081. However, to achieve this the Atlas 10 CPU appears to be working flat out and the VM overheads are very much higher, particularly as the number of users increases. This has an effect on the low priority high cpu virtual machines such as the MVS development system and CMS batch which are spending a much greater percentage of time in an involuntary wait state.
So, although a 32Mb Atlas 10 does provide a good alternative to the 3081 as far as interactive response is concerned, there is clearly a CPU overhead problem, which is being investigated further.
Tim Pett, Computer Services Group
REGIONAL LIAISON MEETING BRISTOL
The second joint SERC/CB Regional Meeting was held on Thursday 28 June. It was attended by nearly 80 representatives from Universities, Polytechnics and various AFRC, NERC and other science based establishments in Wales and the South West.
The meeting was chaired by Dr Geoff Manning, (RAL Director and SERC Computing Coordinator) and included talks on the Common Base Programme, JANET, National and Regional computing, SERC computing and the Alvey Programme.
In his summing up of the meeting, Dr Manning included the following views of the audience.
- Concern was expressed at the lack of provision made by SERC for a high powered vector processor. This is considered by many to be a very important area for which SERC has to provide the solution.
- The recommendation by the Computer Review Working Party that the mainframe computers at RAL will be run as a profit-making centre from April 1985 is a major concern to existing users of these facilities. Dr Manning explained that the two previous methods of funding computing have not worked and a complete change is necessary. This proposal will at least quantify the extent to which Boards require central computing facilities.
- The Bristol users present felt that the PERQ1 does not give useful computing facilities at present. Dr Manning explained that discussions are in progress with ICL to see if the 4K writable control store can be raised to 16K for a realistic price. This should realise the full benefits of PNX version 2.
- The importance of the network (JANET) was stressed.
It was generally felt that regional meetings are beneficial. The plan is to have something like a two-year cycle for these.
Jacky Hutchinson, User Support Group
Text of a supplement to the July 1984 edition of the Forum newsletter
- FR80 Replacement
- Graphics on Primes and GECs
- Graphics Clinic
- Who's Who
- Molecular Display Programs
- FR80 Archive
- Painting System for Pluto Displays
Introduction - All Change for Graphics?
Nothing could be further from George Orwell's prediction for 1984 than the year as seen by Graphics Section. Whereas Orwell foretold of grey and dull uniformity, we have been involved in projects that signal a minor revolution for graphics on RAL (and SERC) computers.
New Devices for Old
Last December the CCC (SERC's Central Computing Committee) gave the go-ahead for the FR80 replacement project. As a result, an NCR 5330 microfiche system was purchased and a Xerox 8700 laser printer rented; we had already ordered an IBM 4250 electro-erosion printer.
In January this year all the software for the Xerox laser printer and the graphics software for the IBM electro-erosion printer were delivered.
March was busy: on the 1st the NCR was delivered; on the 2nd the Xerox arrived; on the 7th they both produced their first output. The IBM 4250 arrived on the 14th, followed by some paper for it on the 16th; on the 18th we printed 120 pages on it for distribution at the Graphics Day on the 19th; that was where we tried to explain to everyone what was going on.
Since then development of the software has taken place and in June an experimental service was made available on the Xerox. In July the same was done for the IBM 4250.
In the first article, you will find further details of the services that will be available on these devices.
Feverish activity was not confined to new hardware: most of Graphics Section was completing work on GKS. The project began in May 1982 when a collaborative project was set up with ICL to develop a transportable GKS system. In November 1982 the pilot system drew its first lines and text.
Throughout 1983 the team brought the system from being a pilot to being a proper system at GKS level 0a and then adding input and segment facilities so that it conformed to GKS level 1b. This was achieved in January 1984 despite changes of operating system (POS->PNX), Fortran compiler and even GKS specification (7.0->7.2).
During January and February the user manuals were written and the system was released for field trial by ICL during March. The final system was released by ICL as a program product in May. Julian Gallop, the project leader for distribution of GKS around the SERC, gives you all the news in the second article.
Support for Primes and GECs
There have been changes resulting from Computing Division's reorganization into two divisions and from revised ICF support levels: Ruth Kidd brings you up-to-date in the third article.
This supplement provides an ideal opportunity for us to publish answers to recent questions: some of your favourites, including some that were raised during the Graphics Day, are in the fourth section.
What's in a Name?
Although Graphics Section has had rather fewer changes of name and staff than the rest of the (Central) Computing Division, we thought you might like to know Who's Who in the section; the next time we do this, let's hope we have a graphics scanner and can give you actual pictures of them.
Paint Your Molecules
Computer Graphics is, of course, for end-users and so we asked you to tell us how you are using graphics. Kate Crennell takes the opportunity with an article on Molecular Display Programs. Kate also has a request for more examples of FR80 output. Finally, Brian Bramer has some information about a Painting System for PLUTO Colour Graphics Display.
The End, or the Beginning?
On the day this article is written, Graphics Section is in a new group of a division with a new name, providing access to new devices through new software. While one era may seem to have ended with the removal of the FR80, another starts with the advent of the new devices. The installation of GKS throughout SERC and University computer centres is a major step towards compatible software systems.
We have planned these new systems and devices so as to continue to serve the needs of the SERC computing community; for this reason, any revolution has been contained and much of the software development has been to provide software bridges so that most users do not need to do anything. For some it may be an appropriate time to review their own methods to see if the new facilities provide an opportunity for improvement.
Most of you will have heard by one means or another of the FR80 Replacement Project. The aim of the project is to replace all functions of the FR80 that are extensively used by using modern, online hardware. The resulting savings to the SERC are considerable - of the order of £120,000 per year.
All the hardware for the project is now installed:
- Xerox 8700 laser printer capable of mixed text and graphics, duplex (double-sided) printing at 70 pages per minute;
- NCR 5330 microfiche recorder capable of text microfiche at 3.5 pages per second;
- IBM 4250 electro-erosion printer capable of very high quality mixed text and graphics (resolution 600 dots/inch) at 1 page every 90 seconds;
- IBM 3203 lineprinter capable of identical output to an IBM 1403 at the same speed (1100 lines/minute).
The CCC (see front page) had originally requested that migration to the new devices should be complete by the end of March this year; granted that the equipment was delivered in March, this was never feasible. However, all devices were installed and produced output during that month. Development of the software to link the MVT FR80 spool to the Xerox 8700 and IBM 4250 has proceeded slower than was originally hoped but is now close to completion. An experimental service on the Xerox 8700 provided access (direct or via FTP and/or VNET) from CMS, MVT, MVS, VAX, Prime and GEC systems and was heavily used. This is now an initial production system.
A similar experimental service has been launched, for CMS users only, for the IBM 4250 and one is imminent for the NCR 5330. The plan is now to run a test user service on the replacement devices during August and a full user service on them during September and then switch off the FR80 on October 1st.
The hardcopy facility on the FR80 has been used for both graphical output and production of documentation originals. This latter task has also been accomplished on daisy-wheel printers. The Xerox 8700 laser printer and the IBM 4250 electro-erosion printer together provide a much simpler method of producing both text and graphics output.
Both devices are being attached to the system in such a way that current FR80 users and other users have equally simple access. For FR80 users, the MVT and VM DESPOOL systems are being modified so that hardcopy output will be sent automatically to the virtual machines that control the new devices. This will redirect SYSOUT streams specified as (G,,HCM and G,,HCS) under MVT and GRAPhics FR80 streams specified as HCS and HCM under CMS. It will also redirect all output from graphics packages on ICF computers.
Most of the work on the DESPOOL interface is now complete; we aim to install this at the beginning of August, have in-house testing during the rest of August and a parallel service during September.
In addition to providing FR80 emulation, new applications of the devices are possible. The Xerox 8700 is a fast system printer with extensive font and format capabilities. We have defined a large number of output formats for different applications. These are all described at present in the "User Guide to the Xerox 8700", available from RAL User Support and Marketing Group. This document also describes the ways in which the Xerox 8700 may be accessed directly via FTP from most types of computer on JANET and from MVT and MVS on the RAL computers.
The IBM 4250 is directly supported by DCF (Script) and GDDM (IBM's mainline graphics system). Direct interfaces from DCF and GDDM (and both together for mixed text and graphics) have been provided and are being documented in "Using DCF at RAL", available shortly from RAL Graphics Section.
The experimental services on the Xerox 8700 and IBM 4250 have provided some selected users with an opportunity to see what sort of output is possible. I: has also allowed us to sort out most of the operations problems in the service. Interestingly, a great deal of the usage of the Xerox 8700 has been from network users.
There were three main paths to the FR80 so far as microfiche as concerned:
- text fiche via SYSOUT = M on DD statement;
- text fiche via FLIST procedure;
- graphics fiche via graphics package.
The last path cannot be provided on the NCR 5330 microfiche system, since it is a text-only system. All tapes containing graphics will be sent by daily courier to the Stock Exchange COMp80 in London and the fiche will normally be returned the next day, excepting weekends. We have run tests on this machine and the results were excellent.
Fiche produced using the FLIST procedure (which currently produces graphics fiche, albeit the only graphics are characters) will continue to be supported. The FLIST program has been completely rewritten so that it supports all options that were relevant to microfiche output but it now drives the NCR 5330 instead of the FR80. This in turn provides support for CMS NFLIST, GEC RARESYS.FLIST, PRIME CPL > FICHE and VAX IBMFICHE. Users of these systems do not need to convert their jobs.
Production of fiche by SYSOUT = M will also continue to be supported. This in turn provides support for the COM option of CMS NPRINT. The MVT DESPOOL system will no longer be involved, so output will be processed as soon as the microfiche recorder is free.
The NCR 5330 has a fixed reduction ratio of 42 x. This provides a fiche with 14 rows of 16 columns: at least one row will always be a title line.
Before the CCC agreed to the FR80 replacement programme, it had already suggested that RAL look at the possibility of using the Dicomed film recorder at ULCC and this was being investigated. The Dicomed machine is broadly similar to the FR80; its addressability is 32k x 32k and its resolution and colour capability much the same as the FR80.
An FR80 emulator exists for the Dicomed which allows tapes that would otherwise be processed on the FR80 to be taken as input to the Dicomed. We are in the process of obtaining and testing this emulator -at present we believe it emulates the FR80 faithfully.
The existing mechanisms by which FR80 output is produced will be left working: MVT graphics packages + MVT DESPOOL, CMS graphics packages + VM DESPOOL, ICF graphics packages and programs that write their own tapes, on IBM or other machines.
The tapes produced in this way will be sent to ULCC and recorded on the Dicomed. ULCC have film processing laboratories close at hand and aim to process the film in about 24 hours. The processed film will be returned to RAL for distribution.
Several points should be noted about this service. The first is that, because ULCC have laboratories close at hand, they will have excellent turnaround on that part of the process. The second is that many users requiring film were only using RAL computers so that they had access to the FR80: we would regard it as natural if those that also had access to ULCC sought to move their applications there, since this would further reduce turnaround times.
The final point is that a survey of the usage of film over the last couple of years has shown that 8 users (or small projects) have accounted for all the film output that could not be handled on a much slower film recorder - of the order of minutes per frame rather than seconds. We hope that such a film recorder, which would be permanently loaded with 35mm colour film, may be purchased and located at RAL. This would provide a slide-making facility for which fast turnaround would be simple to achieve and whose quality would rival that of the FR80.
All the methods of accessing all three devices - both as FR80 emulators and as native mode devices - are being documented in a single report Use of RAL Specialized Output Devices. This will bring together all the material in the individual User Notes mentioned above; it will also repeat relevant parts of the information previously found in RL-78-086 Text Output Facilities on the FR80 Film Recorder. RL-78-085 GEROFF User's Guide, the RAL Prime User's Guide and a number of VAX/Starlink Local User Notes.
Questions and Answers on FR80 Replacement
- QUESTION: Concerning quality control on the new devices: I draw patterns by means of small spots on film and hard copy. Will the dots vary from week to week?
- ANSWER Quality control will be much easier and results should be more consistent than has been the case with the FR80. The operators have been receiving training on quality control from the manufacturers. The IBM 4250 has built-in tests and a manual wholly concerned with quality control. A single dot can just be seen on both the Xerox 8700 and IBM 4250: normally several are used to produce a noticeable point.
- QUESTION: Will it be easy for ICF users to use the new devices?
- ANSWER Each device is serviced by an separate virtual machine, allowing file transfers direct to the devices. This is available in the experimental system and has been used extensively.
- QUESTION: Will Greek letters, subscripts, and superscripts be available on the IBM 4250 and Xerox 8700 from the beginning?
- ANSWER In some typestyles and sizes, yes. A Script file containing definitions of all Greek characters, many mathematical symbols and a number of punctuation characters has been prepared which allow equivalent results to be obtained on the IBM 4250 and Xerox 8700: E = mc2 ∴ εΝρηκα. The Xerox 8700 may therefore be used for proof-reading documents finally intended for the IBM 4250. We are looking at doing the same, with limitations, for the IBM 6670.
- QUESTION: What are your recommendations for PERQ users?
- ANSWER PRIME, GEC, VAX and IBM machines are all connected into the network, allowing access to the new devices. Hardware that supports X25 is now available for- PERQs running under PNX 2. With this configuration, PERQs will be able to access the Xerox 8700 as a printer via HHCP and to access both the Xerox 8700 and the IBM 4250 from TROFF and GKS via metafiles.
- QUESTION: What happens to people with existing FR80 allocations?
- ANSWER For the rest of this financial year, the situation is unchanged. Those who are using hardcopy on the FR80 will receive Xerox 8700 or IBM 4250 output; Xerox output will be produced by default. People producing fiche will receive output from either our NCR 5330 or the Stock Exchange COMPSO. Those producing film will receive output from the ULCC Dicomed. The charges for use of the Stock Exchange and ULCC machines will be met, to the level already allocated.
- If there is any change in charging method next financial year - as has been proposed to the CCC - the method of dealing with existing grants of FR80 time is expected to be similar to that for other resources.
Graphics support from RAL has rested on a variety of basic graphics packages (GINO, FINGS, SMOG, etc), to a large extent doing the same task in different ways. This has been difficult for users wanting to move programs from one computer to another It is also difficult for users of only a single machine who may want (for example) the contouring routine provided with a particular package, but output to a device only available with some other package Clearly supporting multiple packages has stretched our own human resources.
By installing GKS on the various computer systems that RAL Graphics Section supports, we hope that we can achieve the following.
- Provide a graphics system that makes good use of most well-designed graphics devices
- Unify support of the devices through a single package: this does not necessarily mean that exactly the same devices are supported on all machine ranges: it does mean that, if a handler is wanted for a device that is already supported on another system, this can be arranged as long as driving the device itself is practical in the new situation.
- Unify support of the high-level graphics routines though a single package: this means that there should not be artificial barriers against moving such routines to other machine ranges
- Provide a standard graphics system: this has the obvious benefits that users' software can move outside the SERC community and also that graphics software from elsewhere can run on our graphics devices.
- Provide exchange of graphics files between machines.
Figure 1 shows how both high-level graphics routines and device support can be unified through GKS. Our system design encourages better access to the capabilities of intelligent devices.
Figure 1: GKS system structure.
RAL Implementation of GKS
The draft of the GKS document currently in circulation (GKS 7.2) has existed since December 1982. Comments from ISO member nations have resulted in only minor changes which will lead to the publication of a new (and we hope final) GKS document later this year (GKS 7.4).
At RAL, we have implemented GKS 7.2 in collaboration with ICL. The implementation has taken place on Perq under PNX and VAX under VMS with source code being frequently exchanged between the two machines. At the time of writing (early July), it is ready for general release by ICL on the Perq and almost ready for release by SERC on Vax VMS.
The implementation is complete to GKS level 1b except that we have omitted segment highlighting and PICK input for the time being: this was done to avoid further delay to the release.
Distribution to supported SERC machines
Installing GKS on the RAL supported computers is a significant task in itself. To provide a GKS-based graphics system that we can recommend to users in place of existing packages, we have to do three things.
Write GKS drivers for the devices we support. For each driver this will be about the same order of magnitude as writing one for GINO. We will provide drivers for the following devices, amongst others:
- Tektronix 4010/4014 storage tubes and variants like Cifer 2634;
- Sigma 5000 series (1/4/8 plane, mono/colour, low/high resolution);
- Calcomp 81/84 8 pen A3/4 desk top plotters;
- Sigma 6100 workstation;
- Sigma ARGS image display.
Other devices will be available indirectly, through graphics metafiles, such as:
- Benson 13x2 plotter;
- Xerox 8700 laser printer;
- IBM 4250 electro-erosion printer.
Transfer GKS to the computer systems on which Graphics Section supports graphics. GKS is now available on Vax under VMS and PERQ under PNX. We will install GKS on Prime under Primos and IBM under CMS and MVS. We will not be installing GKS under MVT. We also expect to install GKS on the Unix systems run by Informatics Division (Vax, UX63 and UTS).
We cannot install GKS on GEC machines that predate the 4090, since they have no Fortran 77 compiler. Our plans for the GEC 409x and 41xx will be reviewed later this year once manpower (both graphics and systems) is known. We will also be studying the outline recommendations of the "Needs of Engineering Computing" working party set up by the Engineering Board.
GKS will be tailored to the environment in which it runs. For example it will work through spooling systems where that is the best method and also (for example) CMS graphics will be able to view graphics files created by MVS.
Re-implement high level graphics routines using GKS. Graph and contour routines (for example) are not part of GKS itself, just as they are not part of GINO, SMOG or FINGS. However for many people, the high-level routines are an essential part of the graphics software we provide.
We are investigating using the Nag graphics chapter on as many machine ranges as possible (Primes, GEC's and CMS have this already). Nag graphics has many facilities that do not exist in RAL's own high level graphics: it also has the advantage of being externally supported. We may well not re-implement some of our own high-level routines, where we believe Nag does it better.
We envisage that, on a given machine range, we will release GKS in at least 2 stages:
Preliminary Release There will be no high level graphics routines and very few devices will be supported: perhaps limited to Sigma 5000 series (not high resolution) and Tektronix 4010. Despite these limitations some users may well be sufficiently keen to use GKS that such a release would be adequate for the time being.
Full Release This release will include the well used high level graphics facilities that we currently support (at least graphs, contouring, curve-fitting) and it will support all the essential devices. When a full release is available, we can recommend that the majority of users change over their graphics calls to GKS.
After Perq and Vax, our priorities will be Prime and CMS. We want to achieve a preliminary release by September/October and a full release at the beginning of next year. Currently staff in post in the section is low compared with complement (about 70%). Therefore achieving these goals will be more likely if we succeed in approaching our complement and if there is good progress on FR80 replacement software, thus releasing people with IBM expertise.
Distribution to other machines
The way in which our GKS system may be distributed is controlled by a contract between SERC, ICL and British Technology Group; it is also affected by our desire that GKS should be maintained wherever it is installed, not just put onto the system and left to decay.
Despite this, we will supply GKS to some machines that are financed directly by SERC grants. As at present, we will not be able to provide continuing support on such machines.
We are also supplying GKS to the Computer Board for them to install and support on the machines that they finance. This means that other computers in the universities will be using the same implementation of GKS. The Computer Board may, if they have the effort available, provide GKS to other UK academic institutions.
Our GKS system has been written so that different levels can be generated from the same base source; however, at present we only anticipate distributing and supporting level 1b.
There is obviously no lack of work involved in just getting GKS installed on all the machines for which we are responsible. However, a number of further developments are planned: most of these will, as long as effort permits, be done in parallel with the main installation program and with each other.
- Completion of GKS level 1b: this involves the addition of segment highlighting and PICK input and upgrading to the latest (and last) revision - GKS 7.4 - after it is published in November this year.
- Extension to output level 2: this will provide Workstation-Independent Segment Storage: most of the code for this has been written but not integrated.
- Migration of application programs to GKS: this will include facilities like DRAFT and VIEW on the IBM system.
- Extension to input level C: this will provide SAMPLE and EVENT modes of input; it will have to be done on a system-by-system basis since it requires control of parallel processes. Prime, Vax and PERQ appear the simplest systems to tackle first.
Since completion of all of these tasks is likely to take us into 1986, there will be further reviews of relative priorities as the installation project continues.
Questions and Answers on GKS
- QUESTION: What documentation will there be?
- ANSWER: We have already completed a Reference Manual (about 320 pages), a User Guide (about 160 pages) and a Pocket Book (about 24 pages). These will be available from the Documentation Officer.
- We are in the process of writing a guide on how to write new workstation (device) handlers. This will be very large (because of exhaustive documentation of data areas etc..) but will only be required by those responsible for new workstation handlers.
- QUESTION: Will there be courses on GKS?
- ANSWER: We believe that courses will be of most use to people who have just started using GKS. We will therefore organise courses shortly after a full release of GKS has taken place.
- QUESTION: How will GKS affect support of existing packages?
- ANSWER: The answer is slightly complex as already our support varies from one package to another and according to the machine. Another article in this special issue explains the position on the ICF computers. In practice, the effort used to implement GKS has reduced the support we have provided for existing packages.
- When a preliminary release of GKS occurs, support for old packages will be unchanged. When a full release occurs, further development of old packages will be frozen if that has not already happened. In general, new devices and new high level graphics packages will be supported only via GKS. The policy on maintenance (including bug fixes) and user support of old packages will be unchanged for a transitional period, except that maintenance and user support of GKS will take higher priority. One area that should improve is that of access to the new output devices. Since these will, in general, accept GKS metafile input from the network, access will be simpler and can even be contemplated from old packages if there is effort available to write a device handler that produces a GKS metafile.
- QUESTION: What will happen about 3-D?
ANSWER: We find that our 3-D users fall into one or more of the following categories:
- people who write their own 3-D software using a 2-D package provided by us;
- people who use RAL-supported 3-D high level graphics;
- people who use 3-D GINO or 3-D SMOG directly.
Category a. will be served by GKS and category b. will be served by 3-D high-level graphics that will use GKS. We believe that among our users category c. is small. For such people, the old packages will remain available but frozen. A standard which extends GKS to 3-D is being developed internationally and an implementation of that would answer the needs of category c. and will greatly simplify a. and b.
- QUESTION: What effort is required to implement a workstation handler?
- ANSWER: Writing a driver is a task of about the same order as writing a GINO device driver, but there are rather more functions to accommodate. We expect it will take about one month to write and one more to test.
- QUESTION: Will GKS be available from Pascal?
- ANSWER: Access to GKS is being standardized for several languages including FORTRAN-77 and (ISO) Pascal. The next draft of the Pascal interface to GKS will be published later this year. Since Pascal is an SERC Common Base language, we wish to make the standard Pascal interface available (on those machines that have ISO Pascal), but greater priority will be given to producing a full release of the FORTRAN-77 interface on each machine.
- For many machines it so happens that calling a FORTRAN subroutine from Pascal is straightforward: the RAL implementation is written entirely in Fortran 77. Some users may wish to call from Pascal into the Fortran 77 GKS library as an interim measure, but this method will not be supported by Graphics Section and it will result in an interface different from the forthcoming standard Pascal interface. ICL provide a Pascal interface for GKS on the Perq. Again this should be regarded as an interim measure and it will be different from the standard.
Graphics on Primes and GECs
As with other areas, CCC has reduced the amount of effort for graphics on the PRIMEs and GECs, and this is reflected in the effort available. At the same time, there is more work on the GECs with the support of additional graphics libraries (ie. those for FORT3). Also, effort is being put into the provision of GKS on the PRIMEs. This has led to a rationalisation of graphics support, which will now be provided in the following manner.
GINO-F, GINOGRAF, GINOSURF
These libraries will continue to be supported but with limited development. User support will continue but bug fixes may be delayed. (On the GECs, development, maintenance and user support of the FORT2 libraries has been frozen. Users experiencing problems will be referred to the FORT3 or FORTY libraries. This will inconvenience very few users as these libraries are only used at all at one or two sites.)
GINO-F Mark 2.7 will not be implemented. This is because CADC rewrote a large part of the internal code in GINO-F when providing the new facilities in 2.7. As so many changes have been made, there are potentially problems remaining in 2.7, and so 2.6 is a much more stable system and a better version on which to move to limited development.
With regard to new device drivers, site managers have been given information on writing drivers. However, the need for low-cost desk-top plotters is recognised, and a driver for one will be provided in the near future. This will be for the Calcomp models 81 and 84 which are already used by Computing Division and are low-cost.
NAG Graphical Supplement
On the GECs, FORTY and FORTS versions have been supplied and will be supported as for GINO-F. The purchase of the NAG Graphical Supplement for the PRIMEs is going ahead, and it will be supplied and supported as for GINO-F.
The Graphical Supplement provides routines for graph plotting, curve drawing, contour maps and surface views. In this implementation, the Graphical Supplement sits on top of GINO-F.
Development is already frozen. (No FORT3 version will be provided on the GECs.) Documentation will not be revised, but a supplement describing use of the Benson will be produced. Maintenance will be low priority. User support will continue.
There are very few users of this package. Development will be frozen. (On the GECs, no FORT3 version will be provided.) Mark 2 will not be investigated. Documentation will not be revised. Maintenance will be low priority. User support will continue.
It will be a high priority to bring all the graphics documentation up to date. On the GECs, the existing GEC Graphics User series will be updated and expanded. On the PRIMEs. the graphics documentation will be included in the Applications Manual. This is nearing completion.
This has been dealt with in depth by Julian Gallop in his article above.
- QUESTION: What documentation is there describing how to use the CalComp 81 plotter and Dunn camera in the graphics terminal pool?
- ANSWER: The multiplicity of network methods by which users access computers makes it increasingly difficult to write instructions for public devices such as the CalComp 81 plotters. However, instructions for use of this plotter and the Dunn Camera will be prepared and boards with operating instructions displayed near the devices.
- QUESTION: What is the current recommendation concerning the production of high-quality documentation?
- ANSWER: This really needs a supplement to itself for an adequate answer: as a result, a FORUM supplement in the near future will be devoted to document production.
- In a nutshell, we will be providing active support for two methods:
- IBM DCF (GML and Script) with embedded graphics produced by GKS backended by GDDM;
- UNIX TROFF, EQN, TBL and PIC with GKS as an alternative graphics source.
- Details of how to use the Xerox 8700 from GEROFF, SCRIPT and RUNOFF are available in the User Guide to the Xerox 8700.
- QUESTION: What about colour hardcopy?
- ANSWER: We have no recommendation for a best buy at present. We are looking at the Seiko 5201 resolution desk-top printer. This produces one print per minute and has a resolution of 1536 × 1024. It can output to paper or foil and attaches to a colour terminal. It would therefore not be made available centrally, but would be just for evaluation for users to buy their own. There is also an interesting ink-jet printer from Diablo.
- QUESTION: Why are the CMS HELP files for graphics so out-of-date?
- ANSWER: This has happened as a result of the pressure of work on the GKS project and - most recently - the urgent work required for the FR80 replacement project. As soon as the FR80 replacement project is complete (ie when the FR80 has gone), the updating of these HELP files will be given high priority.
- QUESTION: I called the GINO routine DEVPAP (210.0,295.0,0) to produce A4 plots on the Benson, but I only got two frames across the Benson roll and not three as I expected. Am I doing something wrong ?
- ANSWER: The maximum width of paper available to GINO programs which use the Benson is 890mm. In order to save paper, GINO orientates the frames so that the largest dimension of the frame is across the roll (if it will fit). Although the frame size may be altered after a call of PICCLE, the orientation is determined solely by the first frame. A gap of 10mm is left between frames. Thus, three frames of 295mm cannot be fitted across the roll (295 + 10 + 295 + 10 + 295 is greater than 890). So, this explains the results you are obtaining.
- Do you really just want to pack A4 plots economically onto the Benson paper ? If so, it is possible to place four A4 portrait frames (ie Y greater than X) across the Benson, if you first trick the driver into using the correct orientation. DEVPAP should be called immediately after device nomination to select a very small landscape frame eg. DEVPAP(0.5,0.2,0). If PICCLE is then called, followed by DEVPAP(210.0,295.0,0) the required four frames will fit across the roll.
- This information is included in the new version of GEC Graphics User 3 which will available shortly.
- Chris Osland
- Head of the section: regularly not at the end of the phone or screen as a result of being at standards meetings, particularly those aimed at graphics metafiles; something of a nutter where high quality mixed text and graphics are concerned; in charge of the software end of the FR80 replacement project.
- Julian Gallop
- Technical deputy head of the section; project leader for the GKS Installation project; another "standards globe trotter" who specializes in the language bindings for GKS; best person to contact about graphics on VAXes.
- Dave Greenaway
- Administrative deputy head of section; mainstay of documentation and metafile aspects of our GKS system; the only one of us that knows anything about micros; long-time curator of MUGWUMP and GINO-F packages on the IBM systems.
- Dale Sutcliffe
- Our final standard bearer who is perhaps the chief editor (world-wide) of the ISO GKS document; in charge of ICF graphics and our main databank on graphics hardware.
- Ruth Kidd
- Familiar to all those who go to ICF meetings; has been doing most of the support and development of the ICF systems (code and documentation) while the rest of us have been banging the GKS drum.
- Graham Crisp
- Previously worked with Kate Crennell on molecule display systems; now responsible for finding, vetting, installing and (as a last resort) developing 3-D graphics systems.
- Glory Johore
- Librarian to the GKS implementation project; knows more about GKS COMMON blocks than the rest of us put together.
Molecular Display Programs
Many scientists need to display molecules or chemical diagrams. At RAL this may be done both interactively and in batch mode. The well known program PLUTO78 has been enhanced and now runs on the IBM and the GEC computers. Contact Graham Crisp (GMC @ RLIB) for instructions on running a Do-it-yourself demonstration.
CPK82 running on the IBM can be used to make multi-coloured shaded plots either on a Sigma terminal or the FR80. Users wishing to Browse through their molecule can use R.Hubbard (York)'s BLOBS program on the GEC computers.
I have written a new program, TETRA, to design diagrams of materials conventionally shown as linked tetrahedra. This was used for the first time in the production of a computer animated film Silicates in Solution which has recently been incorporated into a video recording on the same subject. A sample frame from this is shown in figure 2. Copies of this may be obtained from the University of Aberdeen, audio-visual aids department.
Grey scale images of molecular models or electron microscope simulations can be displayed on Sigma terminals or on the FR80. Work is in progress to see how well these images can be plotted on the new devices.
I should like to thank all those who have already given me interesting examples of output for the FR80 Archive. The collection is a little biased at the moment; in order for it to truly represent all the sciences I need a few more examples. The plots do not have to be very complicated or use exotic graphical techniques. Your usual old plot may be just the one which I need. Plots showing many contours, computer aided design, or output from programs such as HBOOK. would be particularly welcome: please send them to Kate Crennell, Atlas Centre (KMC @ RLIB).
Painting System for PLUTO Displays
The PLUTO unit produced by IO Research is an add-on unit that can be attached to many computer systems to provide a cheap, high quality colour raster graphics system. The device has a resolution of 640 × 576 pixels with 8 or 256 colours selected from a palette.
The unit contains firmware for the generation of lines, circles, area fills, copy functions, etc. A painting system has been implemented in UCSD p-System Pascal that allows the user to paint or generate pictures, diagrams, flowcharts, etc.. using a tablet or a mouse as the input device.
The facilities include, amongst others:
- paint using pre-defined brushes;
- draw lines, boxes, circles, arcs;
- fill areas using fill while or fill until algorithms;
- select an area of the screen as a symbol to form a user defined brush;
- define symbols, pixel by pixel, then edit them
- enter characters.
The painting system is currently available on the Sinus 1 and Sage microcomputer systems running the UCSD p-System. Tablet drivers are available for the Summagraphics Bitpad 1, SummaMouse and the terminal keyboard. The system is available free for teaching or research purposes from:Dr Brian Bramer
Human-Computer Interface Research Unit
PO BOX 143