200 people made their way to RAL on 29 June for the Symposium on 3D-Computer Graphics in spite of the National Rail Strike on that day. The Symposium was jointly organised by the recently formed UK Chapter of the European Association for Computer Graphics (EUROGRAPHICS) and RAL. The author of this report has to declare an interest in that he is Secretary of the UK Chapter!
The Symposium consisted of 6 talks, commencing with an excellent overview paper by Mr Kilgour of Glasgow University. Almost every major application of computers, and computer graphics is no exception, requires the construction and manipulation within the computer of a model representing some entity or artefact in the outside world which is being designed or analysed. One of the major contributions of the graphics standards movement has been to make a clear distinction between viewing and modelling. The former is concerned with the generation of a picture from an internal model and the latter with construction of the model itself. However, many of the techniques and transformations needed for viewing are equally useful in modelling.
Mr Kilgour then considered the various types of picture format which depend on the kind of output device to be used. For a refreshed calligraphics display (or raster display accepting vector commands) the output format is expressed in terms of vectors. The stages in the graphical output pipeline include transformation of the geometric model to 3D edge format, application of the viewing transformation to generate normalized 2D vector format, then transformation to device specific 2D vector format. Much of the 3D graphics is concerned with the specification and implementation of the viewing transformation.
There is a major alternative picture format to be considered, namely in terms of polygonal faces or facets. This kind of format is essential if realistic, solid-looking images of 3D objects are to be generated, (eg the recent Horizon programme on Computer Graphics!), with proper hidden-surface removal. Display of such images is effectively limited to raster-scan type devices.
The graphical output pipeline in this case includes transformation of the geometric model to 3D facet format, application of a viewing transformation to produce a sorted 2D facet format, and raster conversion to raster (frame store) format. Several methods are available for converting the set of transformed facets into a single raster representation of the picture and some hardware has been developed (eg the Zone Management Processor at the University of Sussex) which makes a video signal in real-time from a set of facet definitions, bypassing the raster format altogether.
Mr Kilgour covered the various projections currently used in 3D graphics and their specification. A key paper in this area is by Carlbom and Paciorele, Computing Surveys, Dec 1978.
He then turned to methods for lines and polygon clipping and the key problem of hidden-surface removal. A successful early method was the algorithm for sorting polygons into priority order (Newell, Newell and Sancha) . Cohen has described two fundamentally different ways of formulating the hidden surface problem:
The second approach leads to the very simple depth-buffer or Z-buffer algorithm. Each polygon is independently raster converted but its colour or intensity is written to the frame store at any point only if its depth is less than the depth value stored at the corresponding location in the Z-buffer, a 2D array operated in parallel with the frame store.
Intermediate between the two approaches are area subdivision methods (eg that by Warnock).
Scan-line methods (eg Watkins algorithm) examples of the point-by-point approach in straightforward form.
There is much research effort going into the design of high performance hardware capable of solving the hidden surface problem in real time.
Mr Kilgour then discussed the search for realism in 3D graphics. Approximations of curved surfaces by a series of polygonal facets in which each facet is given a uniform shading, lead to surfaces which look anything but smooth. Gouroud first showed that a smooth appearance can be achieved by linearly interpolating the shading across a scan line from one edge of a polygon to the other. More sophisticated models have now been developed, requiring more and more computational power. Pictures that can now be produced are truly impressive. Techniques for texturing smooth surfaces (recall the synthetic strawberries and oranges produced by Blinn) have also advanced apace.
A problem besetting raster graphics at all levels is the so-called aliasing problem, manifested in its simplest form in the stepped appearance of straight lines on low resolution raster displays. It is possible, while not increasing the resolution of the display, to sample the scene at higher reduction and then use an averaging technique to compute the intensity at each picture point from a set of neighbouring high-resolution sample points. Much research remains to be done on the most effective and economical means of anti-aliasing (as the technique is known) complex scenes but at least one manufacturer now offers a raster display with hardware anti-aliasing of straight lines.
The final section of this talk was concerned with solid modelling (commonly known as geometric modelling). The approach most often taken is known as 'constructive solid geometry' in which a complex object is expressed as a combination of simpler objects, using the set operations of union, intersection and difference. Considerable effort has been expended to provide a solid theoretical foundation for this approach. Mr Kilgour kindly produced a written version of his presentation which is printed in Vol 1, No 3 of the EUROGRAPHICS journal. Computer Graphics Forum. Copies of this will be sent in due course to everyone who attended the Symposium. A limited number of spare copies is available from Dr D A Duce at RAL.
The other 5 talks will be summarized in the next issue of FORUM.
The SERC held a 'Town Meeting' on the subject of SERC Computing Facilities on 3 September 1982 at Imperial College.
The academic community, through the Vice Chancellors of all UK universities, major London Colleges and Principals of most polytechnics, was invited to send representatives of those disciplines and services having a strong interest in the type of facilities SERC provides for research support. The audience of about 270 contained most of the Directors of University and Polytechnic Computing Centres, their Computer Managers and a broad range of academic users, some of whom currently have access to SERC facilities.
The meeting was opened and chaired throughout by Dr Geoff Manning , Director Rutherford Appleton Laboratory and SERC Computing Coordinator. He set the scene by stating that the meeting should:
The SERC was aware that with a diverse and large community of direct users and interested parties (such as academic computer centres) there were problems with getting this kind of two-way flow of information using existing mechanisms (newsletters, joint committees, etc).
The meeting was organised as a series of talks. After each talk there was a period for discussion led by a spokesman from the community with some experience of the management of SERC or Computer Board facilities. The final session was devoted to general discussion and a summary of the major comments and conclusions was presented by the chairman .
From the SERC viewpoint Dr Manning thought that the 'Town Meeting' had been useful. There seemed to be have been good representation from most universities and polytechnics, covering the full range of interests. He hoped that the right sort of information had been put over and thanked the speakers and audience.
The major points arising from discussion were:
Dr Elizabeth Barraclough, on behalf of the IUCC, thanked the SERC for arranging the meeting.
The lifetime of ELECTRIC should not be longer than that of MVT because :
Assuming 18 months to 2 years from June 1982 for the development of a production MVS system means that the changeover from MVT to MVS will take place during 1984. The following notes discuss the run-down plan.
There are no problems in maintaining the ELECTRIC service for another 18 months. It requires very little operational knowledge and minimal systems support although consideration will be given to switching off the cache.
The user advisory service will be reduced gradually and users should expect the level of support to drop. User Interface Group are already adopting a policy of not training new people to handle ELECTRIC problems.
However, many users will be faced with a considerable amount of work in transferring their files to CMS. Computing Division personnel, particularly User Interface Group and Systems Group, will devote as much time as possible to helping users with this transition.
The on-line filestore will continue to be available from CMS via CMSELEC after ELECTRIC closure, albeit in read-only mode. This will allow users to copy files into CMS using the group edit facilities but the ELECTRIC files will be 'frozen' and not able to be altered in the ELECTRIC filestore.
There should only be a problem in cases where users have built up complicated edit file structures as other files can be transferred to CMS without any difficulty.
The archived filestore will not be directly accessible from CMS but some method will be provided for moving archive files to CMS. Users are encouraged to restore archived files before the closure date. To achieve this users will have to delete a lot of files from the on-line filestore.
Resource Management have started to contact users who have transferred completely to CMS so that their files can b? deleted from ELECTRIC. This can be achieved without much effort provided that all the files in a user's tree structure below the main directory can hp deleted , This will allow some small increases to be made to space allocations in the on-line filestore.
Archiving will be stopped well in advance of ELECTRIC closure and only restoring from the archive filestore will be allowed.
The implementation of XPLANT in CMS makes it very much easier to transfer, especially if a method of automatic conversion of ELECTRIC edit files to XPLANT files can be provided and this will be investigated. It has been agreed that the XPLANT documentation currently available is not adequate, particularly for new users of XPLANT, and a more 'user friendly' version will be written.
The graphics filestore, including pictures and routed lineprinter output, does not present any problems as these files are deleted automatically if they have not been accessed for a week. In other words they are regarded as temporary filer and users would not expect to retain access to them after ELECTRIC closure.
The only exceptions to this are archived picture files which cannot be accessed from CMS. It may be possible to convert these files to a form suitable for CMS and copy them into the CMS graphics filestore. This is being investigated.
The number of simultaneous users will not be altered as this is controlled by the allocation units. However, the number of PACX slots and network connections to MAST will be reduced gradually and transferred to CMS.
File transfer and the use of ELSEND/ELDIRE will cease when ELECTRIC closes.
Continuing activities during these 18 months:
Any users whose programs run slower on the 3081D than on the 360/195 should contact Dr M R Jane, ext 5408. Every effort will be made to compensate users for any problems resulting from this.
It started printing this enormous file and I could not stop it. I even switched my terminal off but when I logged in again it still poured out.
There is no standard solution to this problem. Not only do people use a variety of systems (CMS, ELECTRIC, GEC, PRIME, etc.) but access them in a variety of ways (Network, Rutherford PACX, distant PACX, and direct communication including dedicated screens) .
When a user logs in to a computer service, several processes are brought into operation. A terminal driver controls the keyboard and screen, appropriate network processes transmit text, the operating system sends and receives data, delivering it to the appropriate task such as the command processor, an editor , or a user program running interactively. Under normal circumstances traffic proceeds smoothly but certain problem conditions can arise, such as:
This article discusses these problems as they pertain to a CMS user working at an ASCII terminal, either via a network call across SERCNET or via the Rutherford PACX. (Users making PACX calls to a MUM followed by a network call should regard themselves as SERCNET users) . Users of other systems may recognise some of the problems discussed here and the general principles used here may help them. The article excludes IBM3270 equivalent screens, partly because the trouble shooting methods are different and because they are adequately discussed in "The CMS Terminal User's Guide".
Unfortunately typing NO (or HX or anything else) after a MORE message is no good. If you have logged into CMS via SERCNET, you can generate a suitable interrupt by typing @Y. (If the call enters SERCNET from another network then an additional @ will be required). When CMS responds with a . prompt, you should type HX which will halt your output after clearing a few more buffers. The rules for breaking in at the terminal will depend on the local system but most systems, including GEC and PRIME, display what the system sees of your typing. If continuous output is being produced on a PRIME such that you cannot type @Y you should use Control-P to produce a CMS interrupt.
If your call is via the Rutherford PACX, you may generate the CMS interrupt by typing two successive Control-F characters. (CIFER terminals with a CMS BREAK key may use that key for this purpose). Do not use the BREAK key as that will disconnect your terminal. After receiving the . prompt you should type HX as above.
If you get into a situation where you are unable to induce the . prompt but merely get the ! character to denote attention, your virtual machine probably needs to IPL CMS. You should break the network connection (by @Q) or the PACX call (using the BREAK key) . If you login again before the timeouts take effect, you will be told that you have been RECONNECTED. Do not make the mistake of typing BEGIN because that will return you to the same problem condition that you left. What you should type is IPL CMS and you should then be able to proceed as if you had just logged in.
ASCII terminals display a . prompt character to indicate that input is expected from the user. Whenever a command (in its most general sense) is typed by the user, a period elapses during which replies are sent to the terminal followed by another prompt. Once that prompt is displayed, with the exception of operator warnings no further replies can be sent and that applies to system broadcasts, user messages and the notification of spool file arrivals. Thus to bring a 'dead' terminal to life it may be sufficient to input a null line which will release any queued output. This is a feature of ASCII terminals only and does not apply to full screens unless they are in an input mode. Users have some control in EXECs about delaying the appearance of the . prompt by making use of the SLEEP command.
When CMS commands or programs take longer times to execute there is no . prompt displayed at an ASCII terminal . If you type when the terminal is in this state, the first character will act as an Attention Key. This will cause an ASCII prompt and unless you have specified otherwise what you type thereafter will be processed by CP. If you had typed prematurely then you can resume the execution by typing BEGIN. On the other hand you may stop the execution by entering the Debug submode. First you type EXT causing the system to reply DEBUG ENTERED and EXTERNAL INTERRUPT. You should then type HX which will return control to CMS. It should be added that some commands do not recover properly from this situation and in such situations an IPL of CMS will be required. (It was assumed in the above that the terminal had not been timed out due to a visit, phone call or taking too long referring to something).
User programs which accept input data from terminals would process instructions such as HX as data. To recover from loops in programs and EXECs you should proceed as follows. (Network users may type @\ which will induce another prompt after which they may type HX as before). The general method which works for either type of connection makes use of the CP linend character. (This has the default value of £ sometimes appearing on keyboards as dollar or pound but usually as upper case shift 3. Users may redefine it by the TERM command from the keyboard or in a PROFILE EXEC. In that case substitute the appropriate character). If you type £CP EXT you will receive the replies DEBUG ENTERED and EXTERNAL INTERRUPT. You may then type HX to return to CMS.
Symbols not People! Problems arise because certain characters are used to control terminal input and network calls etc. They are sometimes referred to as logical line editing symbols. Users who are unfamiliar with their use may be puzzled why characters such as £ @ \ " and maybe others appear to be ignored or induce strange effects. It is important in that case to read again the account of logical line editing symbols in the CMS User's Guide and to check what characters are in force for your virtual machine. (Section C of the User Reference Manual also contains explanations). Use the CP command Q TERM to display what characters are in force.
However, the situation is worse than an innocent user might imagine. Not only does CP (the control program which accepts the input) perform logical line editing but so do various utility programs notably XEDIT. In some cases the same characters are used but not always. In XEDIT, Q ESC will display its Escape character. For example the default line delete character of CP is £ which can be changed or suppressed using the TERM command. However XEDIT also uses £ as its linend character except when in input mode. Thus even if CP has LINEND OFF, you can type things such as TOP£C/A/K/**£TOF£T9 but had XEDIT been in input mode and CP LINEND been OFF this would be all one line. Turning CP LINEND ON would present four input lines to XEDIT.
Problem: How does one edit £ characters that are in a CMS file without retyping entire lines?
Answer: First switch off the CP LINEND by typing CP LINEND OFF. Then switch off XEDIT linend after entering XEDIT by typing SET LINEND OFF. (Alternatively you could define some other character as the linend symbols. This is safer because if you have LINEND OFF you would be unable to use £CP EXT if needed later). This is a simple recipe for users who are unfamiliar with the use of Escape characters.
Many users have experienced difficulty due to the above, but if you really wish to make trouble for yourself you can introduce character translation using the CMS commands SET INPUT and SET OUTPUT.
Networking adds the further complication that lines which begin with the @ symbol will be regarded as network control commands. For example @Y generates an interrupt and @Q a disconnection. To overcome this an additional @ (which the network call will remove) should be provided to ensure transmission. Users making calls involving more than one network may need further such prefixes.
Network users should also familiarise themselves with local editing conventions of the terminal driver. For example, GEC 4000 machines interpret Backspace (Control-H) locally but that may be suppressed by typing ?S. (On such machines any text involving ? is likely to be processed by the local terminal driver) .
Both SERCNET and PACX operate timeouts which close a call after about 10 minutes inactivity. It is untrue to say that CMS logs you out, it disconnects you. If you do not login again within 15 minutes of the disconnection (ie about 25 minutes since the last transaction) , the system will then log you out. Subsequent logins will IPL your machine as normal.
If you login within the 15 minute period CMS reconnects you. After replying to the LOGIN, CMS will not execute your PROFILE EXEC. What you type will be processed by CP. (If you input a null line here you will receive the reply CP which confirms this). You may type BEGIN to re-enter CMS and resume your previous activity. However, the page and line lengths will now have the default values of 0 (giving continuous printing) and 72. Alternatively you may type EXT to enter the Debug submode, followed by HX to halt the previous activity and enter CMS. Another choice following reconnection would be to IPL CMS followed by PROFILE to reset your page size etc.
This happens sometimes if the network or PACX signals induced by a broken connection are not received by CMS. When you attempt to LOGIN the system denies you access because the previous login is still in force. You may overcome this by supplying an additional parameter, DISC with your LOGIN, for example
LOGIN userid password DISC
On rare occasions problems occur with the operating system VM, which cannot be overcome by the above form of login or by the normal timeout mechanisms. In such cases operator intervention is required. This can be arranged through the PAD or, outside prime shift, through the shift leader.
UCL have announced that the PDP9 which provided ARPA access via the MAST address ++A ceased operation on 1 October 1982. Users not already using the recommended route via a network call to ZUXA should do so straightaway and refer to the September issue of FORUM (27).
The following is a list of articles taken from issues 23, 21, 25, 26 and 27 of FORUM and mainly of interest to IBM users.
23.3 Tape Library and TDMS news 23.5 IBM User Representative Meeting - 17/3/82 Supplement to Forum 23 - Computing Services Survey 1981-82 24.2 Questions raised at CCR meeting - 17/3/82 24.7 Good News - IBM 3081 approved Supplement to Forum 24 - CMS Users Command List and useful hints 25.1 Questionnaire results -List of worst cases 25.2 Central Computer Replacement 25.3 MVT Batch Usage Supplement to Forum 25 - Tips on how to write XEDIT macros 26.1 CCR meeting notes - 8/7/82 26.2 Questions raised at CCR meeting - 8/7/82 27.4 NAG Mark 9 Library 27.6 PASCAL/VS 27.7 IBM Systems Channel Configuration
The current terminal system response and usage statistics do not provide an adequate view of the performance of the interactive systems on the central machines.
The following usage graphs show the average and maximum number of users logged-on to the ELECTRIC and CMS systems. The response graphs for ELECTRIC show the average time taken by a command and for CMS show the average and maximum time taken for a trivial command. A trivial command is one which does not use the whole of its initial timeslice. Each graph has a dashed trend line drawn by using a least squares fit to the available data.
The data from which these graphs are calculated is collected from 08:30 to 17:00 on Monday to Friday of each week. The data will be presented for the current month and the previous two months to enable the trend line to present a picture not unjustifiably distorted by public holidays etc. It is thought that these graphs will give a better representation of the use of the central machine interactive systems.
The following list and diagram shows the many formally constituted bodies within the SERC and the Computer Board for Universities and Research Councils which are principally concerned with computing. Where those bodies have delegated powers of spending (SERC money), their limit is given in brackets in units of K£s.
| SERC CENTRAL COMPUTING | |
|---|---|
| CCC | Central Computing Committee (300). Reports to council of SERC. Membership includes the Computing Coordinator and representatives from: Boards, User Liaison Committees, Joint Network Team, Network Management Committee |
| CCP | Computing Coordinators Panel. Reports to Directors Committee. Membership includes Laboratory heads of Computing Divisions. |
| SNMC | SERC Network Management Committee. Reports to Coordinator. Coordinates Network within SERC. Subcommittees are: |
| SISC | SERCnet Implementors Sub-Committee |
| LANSC | Local Area Network Sub-Committee |
| SNOSC | SERC Network Operations Sub-Committee |
| DLCULC | Daresbury Computer User Liaison Committee. Representatives of user of DL. Reports to Coordinator. |
| RALCULC | Rutherford Computer User Liaison Committee. Representatives of users of RAL. Reports to Coordinator. |
| EDIUC | Edinburgh Decsystem-10 Installation Users Committee |
| CCRM | Central Computer Representatives Meeting (Batch + CMS) |
| GUG | GEC User Group |
| PUG | Prime User Group |
| CCSUM | Central Computer Site Users Meeting (Representatives from RAL on-site users) |
| TS | Technical Sub-Committee. Set up as required by CCC to study technical details. |
| SUSSG | Single User System Steering Group. Set up by CCC to control the provision of Single User Systems (eg PERQs) |
| SCIENCE BOARD | |
| SB | Science Board (300) . Advice on computing matters handled by: |
| SBCC | Science Board Computing Committee. |
| ASTRONOMY SPACE AND RADIO BOARD | |
| ASRB | Astronomy, Space and Radio Board (300). Starlink computing is handled by: |
| SAG | Starlink Advisory Group. Other computing matters dealt with by board, based on advice from its Committees. |
| NUCLEAR PHYSICS BOARD | |
| NPB | Nuclear Physics Board (300). Board relies on advice from Scientific Committees such as: |
| PPC | Particle Physics Committee (200) and its subcommittees, including: |
| UACPP | User Advisory Committee on Particle Physics |
| PPGSC | Particle Physics Grant Subcommittee |
| ENGINEERING BOARD | |
| EB | Engineering Board (300). ICF Applications Software is handled by: |
| EBCC | Engineering Board Computer Committee (200) deals with SERC DAP and has a number of: |
| SIGS | Special Interest Groups |
| Other Computing is covered in a number of different Committees especially the: | |
| IEC | Information Engineering Committee (200) which has: |
| CCSC | Computing and Communications Sub-Committee (100) which includes: |
| DCS | Distributed Computing Systems (50) and |
| STI | Software Technology Initiative Panels |
| JOINT COMPUTER BOARD COMMITTEES | |
| There are three joint bodies with the Computer Board : | |
| JNT | Joint Network Team. Responsible for University and Research Council Network Standards |
| NMC | Network Management Committee. Responsible for proposing the joint Universities/Research Council Academic Network. Subcommittees are: |
| CMSG | Common Management Study Croup |
| USWP | User Specification Working Party |
| DMC | DAP Management Committee. Responsible for coordinating the work done on QMC DAP. |
| COMPUTER BOARD | |
| The Computer Board (CB) has two main advisory bodies: | |
| CCC* | Computing Consultative Committee. Deals with general policy and funding. |
| IUSC | Inter-Universities Software Committee. Advises CB on software It is a subcommittee of: |
| IUCC | Inter-Universities Committee on Computing which had no formal links with CB. |
10 Nov 1982 - DECsystem-10 Users Committee meeting at 10.30 am
James Clerk Maxwell Building
King's Buildings
Edinburgh
Routine Preventative Maintenance will take place on the following days from 1800 - 2200 hours. Login messages on the ELECTRIC and CMS services will be issued prior to each maintenance session.
An intensive two-week residential Summer School will be held at The Cosener's House, Abingdon, from 11-22 April 1983, on the theme "Good Practices in the Production and Testing of Software". It is restricted to SERC staff, SO/HSO, who have a science degree or equivalent and who spend more than half their time computing. Application forms will be available through the Establishment later this year, but if you are interested please contact R E Thomas, Computing Division, Rutherford Appleton Laboratory and you will receive a form direct. Places are limited to 20.
