This issue brings the launch of a competition to design a new, more modern, Newsletter heading. This coloured band, originating from the standard RAL in-house publications, is very different to other newsletters dropping in our in-trays today. In these days of endeavouring to minimise the greenhouse effect we wish to stay with the green aspects of our fact-packed, non-glossy and simply-produced product, but with a revised heading reflecting Engineers in the fast-moving world of IT, supported by EASE. Please submit your ideas, on paper or computer, to me by 31 October 1989.
This issue starts with an article from the SERC/DTI Engineering Applications of Transputers Initiative surveying the current software situation. The message is that engineers can now seriously consider using Transputer systems in their research activities.
Remember this Newsletter is for your interest and benefit - articles are always welcome.
When the SERC/DTI Engineering Applications of Transputers Initiative started in 1987 the T800, floating point, transputer was not yet available. It was possible to buy off-the-shelf transputer arrays with T414s (a tribute to the ease with which the design of complete hardware systems can be achieved), but it was not possible to buy much off-the-shelf software. Application codes were written in Occam or not at all, and we all loved to learn (or was it learned to love?) Inmos's Transputer Development System (TDS). We stepped into the unknown of parallel programming like Victorian explorers, that is, with very little equipment to help us. The resulting macho image was perhaps satisfying and, for some of us, perhaps it still is. But most users do not want to be macho - they want to be helped, helped to use their existing codes and existing skills, and helped with high level tools which provide performance at minimum effort. There is no doubt that a year or eighteen months ago, potential transputer users were put off by the lack of tools.
Luckily, the transputer market has proven to be big enough to encourage firms to provide tools, and the situation has changed rapidly over the past year. This article attempts to summarise the current situation realistically and to look a few months into the future (it seems impossible to see further ahead than that with any reliability).
Most users still have small arrays hosted by a PC; for these there was no operating system a year ago, but TDS provided what was (and is) a very usable closed environment, with an idiosyncratic user interface commendable for its brevity (single key depressions for everything) rather than its memorability (key assignments failed to survive version upgrading). We also got the Folding Editor, which most of us actually like a lot. However Inmos soon found why a closed environment is hard to maintain; it is difficult to port to new environments, hence the Standalone Toolkit, which deals with host (eg MSDOS) format files and provides an unbundled compiler, loader and configurer. The new Inmos Toolkit (TDT) is very usable indeed, with much better multi-language capabilities; we would reckon it is fairly mature.
Larger systems need a full-blooded operating system and that has to have a Unix user interface (because the market-place says so). Manufacturers are not blind, and the necessary work has been going on with severed alternatives now being marketed:
Other operating systems are known to be under development, eg the Esprit-funded Supernode 2 project has a start-from-scratch OS as part of its development programme. Hence, once the current offerings mature (ie, go from beta release to usable - probably only a few months), we will be faced by too many rather than too few operating systems. Given the quite similar architecture of all systems, we expect to see a shakedown over the next few years, with one or more players retiring hurt.
There has been similar progress with the provision of compilers. There are now multiple vendors of reliable C and Fortran compilers, with 3L being probably the most widely used. The 3L parallel compilers are self-supporting (ie do not need TDT), robust and provide explicit support for parallelism. They are not however optimising compilers and do not generate code as good as that given by Occam (the speed factor can be two or higher). Meiko Fortran is similar in robustness and efficiency, and is also available under Helios. Inmos is understood to have an optimising Fortran compiler almost ready, which should produce. better code, but already the situation for applications programmers is much more satisfactory than it was a year ago. You can write applications in standard Fortran77 or C (plus, as a minimum, calls to system routines to pass data to other processors), without even hearing the word Occam.
There is also a surprisingly wide spread of other languages available. We list the most important:
All of the above serial languages can be used to code for a transputer array, provided that the programmer arranges to send and receive data between processors via library routine calls. We look here at which higher-level aids arc currently available:
By general agreement the most tedious feature of coding for current arrays is the need to explicitly route messages intended for a remote processor, using explicit message passing on intervening processors. This need is inherent in the current Occam implementation (though not in the language definition) and in all other languages if these are coded for bare arrays. Several suppliers now can manage the through-routing for you, provided you program within their environment:
On a vector processor we have become used to coding primarily in a standard serial language with no vector syntax, and letting the compiler (perhaps with a bit of help from loop re-arrangements or compiler directives) vectorise the code by itself; vectorising compilers have indeed become quite good. So far, no parallelising compiler for transputer arrays exists; there is a project within Supernode 2 to produce one (by System Software Factors), but this is several years away from fruition.
The simplest route to parallelism, in the absence of automatic parallelisation , is to make calls to a library of parallel routines. Two general purpose libraries have reached the market so far, from TopExpress and from Liverpool University (marketed by NA Software Ltd). They arc not yet very extensive in their coverage. Liverpool, with NAG, are extending the latter library as part of Supemode 2 (Mark 2 is scheduled for about the end of the year).
An Image Processing Library is now being marketed by Quintek Ltd.
There is a place for software able to speed up single processor code. The simplest such aid is a library of assembler routines. Both TopExpress and NA Software market such libraries, which can show speedups compared to the equivalent Fortran code of factors of 3 or more (factors of over 20 in isolated cases). Significant speedups (factors of about 1.5 to 2) are even obtainable compared with Occam.
System Software Factors also markets FLOLIB. This is a source to source translator, which will analyse and (where it can) restructure a Fortran program, inserting calls to a library of assembler routines to achieve painless speedups. A library from Liverpool is marketed with the 3L Fortran version of FLOLIB, and speedups of a factor of 3 for a complete program have been measured in favourable cases (and no speedup at all in other cases). There should be a steady development of FLOLIB towards a fully autoparallelising tool.
Both Helios and MeikOS provide software tools to make producing at least simple parallel programs easy. In particular, the processor farm paradigm (single server, multiple client is an alternative jargon) lends itself to automation, and is well supported. Surprisingly many applications can make use of this technique effectively.
There is a dichotomy between those who want to use a conventional language, with as few (preferably zero) additions as possible, and those who would like explicit parallel constructs in the languages provided. As noted above, Meiko Fortran and most versions of C provide no new syntax; support for message passing is via library routines. Occam of course provides one mechanism which supports the full range from fine to coarse grained parallelism. With 3L Fortran, the description of the parallelism is provided by the user in a separate file using a configuration language. Should we use it? Unless the configuration language becomes standard, and widely implemented, it also reduces portability.
Other products also support parallelism via different routes:
No software development environment is complete without good debugging facilities. TBUG, from 3L, Express and GENESYS II all provide useful debugging aids. We are also aware of a number of other activities which will greatly improve the current situation.
Another problem with transputer arrays has been the lack of applications software available, which is a problem with all new processors, of course. But an encouraging amount is now reaching the market. We mention some of the useful packages of which we are aware, with apologies to those we omit through ignorance:
This is available for a single Transputer under Inmos (3L) Fortran (all 750+ routines) and represents an extremely useful adjunct to the parallel libraries. For the Occam user, a set of 50+ high level Occam-callable routines is marketed by TopExpress.
GKS, the NAG Graphics Library, Xwindows and WFS (from Nexus) are all now available, in addition to the widely used BOO7-compatible primitives provided by Inmos. Quintek also markets a graphics library aimed at producing graphics on a PC screen for those who do not have a transputer graphics board.
These are statistics packages from NAG; a single transputer port of Glim (Generalised Linear Modelling) has been completed, while the general statistical package Genstat should be available with six months.
Transputer arrays are well suited to fast Finite Element calculations. This is a broad field, and no one package is yet available which will cover all Finite Element needs, but commercial Finite Element Method (FEM) software is available from Rockfield Software for some classes of problem, while at least two suppliers of general purpose FEM packages are known to be studying full ports. Supemode 2 also contains a Finite Element software component.
Here we degenerate to listing a few products known to be available:
The software situation for transputer arrays has been transformed over the past year.
There is now a reasonable level of support for programmers and a growing level of applications software. We expect this growth in support to continue. Known commercial UK and EEC funded projects make this certain. This must be good news for users, whether current or potential; as the market expands everyone benefits.
If you require more information on the software mentioned in this article, on any other aspects of Transputers or the SERC/DTI Engineering Applications of Transputers Initiative, contact the Coordinator in the Informatics Department at Rutherford Appleton Laboratory .
This is the first of a series of articles which summarise the programme of work on engineering data exchange and databases at RAL. This article reviews the achievements of the ESPRIT CAD Interfaces project (CAD*I), which was described in Engineering Computing Newsletter 3, May/June 1987. Three more articles will appear in subsequent issues of the Newsletter.
CAD*I, which has involved twelve partner organisations from six member states of the European Community, started in November 1984 and will end in October this year. The organisations range from a large industrial company (BMW, Munich), through national laboratories and universities, to small software companies. The tasks were divided between eight working groups, each group consisting of three or four partners. Those groups to which RAL belongs finished their work in October 1988, although we still participate in standards activities arising from the project The main achievements have been:
The interim results of the project have been published in Status Reports. The final reports are being published in book form by Springer-Verlag. In addition a large quantity of software has been developed and tested in order to verify the work. This software remains the property of those partners involved in its development; much of it is in use for industrial purposes, and some is being actively marketed either as stand-alone products, or incorporated into other programs.
The NAG/SERC Image Processing Algorithms Library (IPAL) is a collaborative Alvey supported project which was established to develop an open and portable library of standardized image processing software. This project is now drawing to a conclusion which means that you may soon be seeing a new image processing library distributed by NAG Ltd.
The library will have components written in Fortran and C. This in effect gives two libraries since the design considerations have been different for the two languages. However both versions have aimed to isolate input and output from the library routines. Although some simple I/O routines will be provided as part of the library so that test images can be read, it is recognised that this is an area where efficiency considerations and local image capture and display hardware mean that locally written routines will normally be used.
The Fortran version is the more advanced and should be available next year. This version treats images as simple two dimensional arrays and the area to be processed as a rectangle. The results are returned in a separate array with its own rectangle defining the area for which the results are to be trusted. This may be smaller than the input area of interest and in this case library utilities can be used to recreate an area of the required size. The library is broken up into chapters and the main chapter headings are as follows:
Additional chapters may be included as resources and demand dictate.
The 'C' language library makes extensive use of structures to simplify the calling of library functions. The information defining the image and the area to be processed is passed as one address: the address of a structure. Low level routines are provided to create and manipulate the structures, so that the details of the structure definitions are hidden from the users. Use of the structures allows restrictions on the shapes of images and areas of interest to be relaxed.
Although the C library will be released later than the Fortran, it should become available sometime in 1990. On most machines it is not difficult to call the Fortran library routines from inside C programs so for the C user the two libraries may be regarded as complementing each other.
IPAL will provide an accessible and inexpensive resource for research and teaching in the many application areas and disciplines where image processing techniques are used. The library will be distributed and fully supported by NAG Ltd, and will be tested and documented to the high standard of all NAG products.
Every year as part of the IPAL Alvey Project, an IPAL advisors' meeting is held to guide the future direction of the product. Additional topics at the next meeting being planned will include standardisation of image processing.
As one of the tasks of EASE is to integrate IPAL into the environment and respond to the image processing needs of engineering users, potential EASE users of image processing are particularly welcome to the meeting. If you would like to give a short talk on the requirements of your application, please let one of the authors know.
Details of the meeting will appear in a subsequent issue of this newsletter.
A trial release of the Fortran library has been prepared. If you believe that you could work with us on the trial release, please contact one of the authors.
X Windows Version 11 Release 3 is now available in binary form for Sun3s running OS3.4 and OS4 for EASE users.
Anyone with access to a Sun3 wanting to run X Windows and having access to JANET can now pick up a version of the X distribution file from the software distribution machine at RAL.
The software is X 11 Release which has been modified to give significant performance enhancements over the "vanilla distribution from MIT when running on monochrome Sun machines. These enhancements have been realised by modifying the server with the addition of many calls to the Sun pixrect graphics library which is far more optimal than the generic mfb code used by the vanilla server. The so called PURDUE speedups have also been applied.
The README file gives instructions on how to FTP the files required for the distributions and how to assemble a distribution.
The code available has been compiled for use in Sun3 machines running versions of SunOS releases 3 and 4.
There is a shell script front end which can be used with X windows for performing various operations and reporting the locations of important files. This script is called xr3 and has a corresponding manual page (xr3.I).
The size of each distribution is about ten megabytes but this can be reduced slightly if all distributions are installed as manual pages, include files and so on, and can be shared.
Source for the X distribution is not included in this service.
Issue 11 of the Engineering Computing Newsletter provided information on the Stellar and Ardent superworkstations and the evaluation and development at RAL.
As part of the EASE evaluation programme of superworkstations, we now wish to place the Ardent Titan in an HEI engineering department on a temporary basis and therefore invite outline bids to that effect.
The primary purpose of the placement is for a group to gain experience of superworkstation technology for engineering research and for that experience to be disseminated to the EASE community. There will be a requirement to provide an evaluation report and to make software available for future evaluations by EASE.
The configuration is a single processor Titan, 32 MBytes main memory, 32 planes for graphics, 380 MBytes disk, and mouse and dials.
An outline bid should not exceed two sides of A4 and should include:
Computer Aided Acquisition and Logistics Support (CALS) is a major initiative taken by the US Department of Defence (DoD) whose aim is to apply computer technology to the process of specifying, ordering, operating, supporting and maintaining the weapons systems used by the US armed services. The main output is a set of standards (MIL-STD-1840A, "Automated Interchange of Technical Information", December 22,1987.), conformance to which will soon be mandatory for any supplier bidding for a military contract. Apparently the in thing to be in the military world is CALS compliant.
The first stage of CALS specifies standards for use in the exchange of Technical Publications and Product Data. Future phases will look into using Office Document Architecture and Office Document Interchange Format (ODA/ODIF) for office document exchange, Electronic Design Interchange Format (EDIF), VHSIC Hardware Description Language (VHDL) and Integrated Printed Circuit (IPC) for electronic product data definition exchange, Information Resource Dictionary System (IRDS) for data models and Structured Query Language (SQL) for data access.
CALS specifies the use of Standard Generalised Markup Language (SGML) for the text source of technical publications with illustration files in Initial Graphics Exchange Specification (IGES), CGM or raster format. Separate MIL standards developed by CALS specify the Raster Illustration Data File Format, an Application Profile for CGM Illustration Data Files and the use of SGML.
At present, CALS specifies the use of IGES (ANSI Y.14.26M) for exchange of product data but a future phase is expected to address the use of STandard for Exchange of Product model data//product Data Exchange Specification (STEP/PDES).
The IGES standard is, in many ways, imprecise and is open to misuse. Therefore, CALS has developed a standard(MIL-D-28000, "Digital Representation for Communication of Product Data: IGES Application Subsets", December 22 1987) which defines subsets of IGES to be used for various applications. The ones specified so far are:
IGES is used widely simply because it is one of only a few standards which are available and supported. It is recognised that there are many problems with it. The application subsets are an attempt to solve some of the problems.
These application subsets define which entities may be used and start to define how the entities should be used but, unfortunately, they do not go far enough along this path.
CAD-CAM Data Exchange Technical Centre (CADDETC) believes that CALS is going to be very important and already has software which tests IGES files for conformance to the CALS application subsets.
STEP/PDES is attempting to cover a much wider area of application than IGES and is based on the latest developments in information modelling. It also has the support of all the countries participating in ISO TCI84/SC4. The DoD recognise the importance of this emerging International Standard and have been encouraging its development. I understand that their official view is that STEP/PDES should be included into CALS as soon as possible but that it should at least cover all the areas that are covered by IGES. There is already a placeholder for STEP/PDES in the CALS documents.
STEP/PDES will not be available as an International Standard for several years and commercial implementations will, of course, not come onto the market until after then.
In spite of this, however, several vendors have already written CAD systems based on the current documents. They are also investigating both migration paths from IGES and the clear possibilities of generating large parts of such CAD systems automatically from the formal description language used to define STEP schemas.
Because of CALS and the delay in STEP, IGES is going to be a very widely used standard for many years. IGES translators are optional extras with many CAD vendors but having two CAD systems with the accompanying IGES processors rarely means that transfer of drawings is completely successful. Errors almost invariably occur until the users of the sending system tailor their use of that system to exclude the use of entities which are not transferred correctly.
CADDETC provide assistance in this area, to their membership, by providing software to forecast compatibility of two systems and to validate IGES processors. They also hold seminars and publish newsletters. CADDETC was set up with pump-priming funds from the Department of Trade and Industry and also industrial sponsorship in order to assist UK industry in its short and long term efforts to exchange product data.
Some of CADDETC's software and documents, particularly that developed as part of a further DTI grant to contribute to the development of STEP, is in the public domain in order that the national and international community may use it.
Model based reasoning is an inference procedure which exploits a structural description of a device and know1cuge of underlying mechanisms to compute values at various points in the model given partial information about values elsewhere. This inference procedure is applicable to many engineering problems.
The Summer School on Model Based Reasoning in Engineering took place at the Artificial Intelligence Applications Institute (AIAI), University of Edinburgh, from 31st July to 4th August Altogether there were twenty participants, eight were supported by the EASE Programme.
The activities of the Summer School were divided into two parts:
The Summer School was very successful with active involvement from the participants.
AIAI has two report series: the project report series and the technical report series. The project reports (AIAIPR) are written by visitors, or others, concerning project work undertaken while at the Institute. A number of these reports are by academic engineers from other universities in the UK who made use of the visitor scheme operating under the AI Support for Engineers project funded by CFC. The technical reports (AIAI- TR) are authored or co-authored by members of the Institute. They are papers which have been published, presented to a conference or workshop, or submitted to be refereed for publication. Many of these are relevant to engineering applications.
There are over forty AIAI-PRs and sixty AIAI-TRs. They are all publicly available at a nominal cost to cover the printing and postage. We list some of them below.
Copies of these reports and a full list of publications can be obtained by contacting us.
Our short courses for the fourth quarter of 1989 are:
Object-Oriented Programming (OOP) & UIMS Seminars at UMIST , Monday & Tuesday, 18 & 19 September 1989
London & SE Regional Transputer Support Centre Programme for September to November i989, Exploiting the Transputer 13 September & 16 November; Transputer Awareness 26 September & 2 November
Computer Integrated Process Engineering Conference (CIPE '89), Leeds, 25-28 September 1989
Real-Time Systems - Theory and Applications, University of York, 28/29 September 1989.
Eurographics '90 Conference, Montreux, 3-7 September 1990.
Applications of Transputers, SERC/DTI Transputer Initiative's 2nd International Conference on the Applications of Transputers will be held at Southampton University on 11-13 July 1990.
