Jump Over Left Menu
The EMR Programme
M A Sabin
FEGS Ltd, Oakington, Cambridge
An Independent Review of the Transputer Initiative that was published as part of the Proceedings of the Closing Symposium at the University of Reading in March 1992 (IOS Press).
The original working party, which set out in its report the argument for having a transputer initiative, and which made first suggestions for how the initiative should be set up and run, envisaged that there would be tools required by many of the loan pool projects and saw that considerable effort could be saved if these tools were funded once and then distributed, so that the individual loan pool projects need not duplicate that work.
It therefore included in its recommendations a budget for EMR projects which should be funded on a development rather than a learning or research ticket.
This recommendation was accepted. This document reviews the way that budget was spent and identifies some lessons for future initiatives.
1 The original proposal
I was privileged to be a member of the working party which put together the report which made the case, first to the Engineering Board Computing Facilities Committee and then to Engineering Board, Council and the Department of Trade and Industry, that there should be a Transputer Initiative.
While making the case we thought very hard about what a good initiative should be like, and what components it should have. The experience of members of the working party was that in their own previous transputer work they had had to build a lot of basic software which was necessary for their work, but not central to their interests, and we foresaw that the same would be true for many of the recipients of loan pool equipment unless we made sure that those common needs were addressed promptly, and the common solutions made available with the loan pool equipment itself.
There is a mechanism available through RAL for the funding of work which is development-like rather than research-like. It is perversely called the EMR, for Extra Mural Research contract, (i.e. work done outside the Rutherford Appleton Lab. on a RAL budget) but matched exactly the needs we saw. Projects funded under this mechanism need not have research content in the way that projects funded by subject committee research grants do.
We therefore included in our recommendations that
2.7 The objectives of the proposed Programme are: (a) ... (b) provide coordination for more effective use of resources (c) ... 2.8 The basic elements of the proposed programme are: (a) ... (b) ... (c) ... (d) a budget to enable Extra Mural Research Contracts to be let to ensure vital developments are undertaken.
Although we saw the need, we did not have the time (the working party met only three times, between June and September 1986) to identify the exact list of items of development which needed to be provided. Furthermore, the working party was small and we did not believe our experiences spanned the whole range of transputer application, and we expected new requirements to become visible as time went by.
We knew that there would have to be a group set up to oversee the operation of the Initiative, and felt that the task of choosing an appropriate programme of developments should be left in the hands of that group rather than preempted.
e therefore recommended
6.8 The Computing Facilities Committee (CFC) should be responsible for any EMR contracts let as part of the proposed Programme. 6.17 The TAMG (Transputer Applications Management Group) should recommend appropriate EMR contracts to CFC associated with the needs of the Programme and report on these regularly to CFC.
We wrote in a budget line
Item 87/88 88/89 89/90 90/91 TOTAL EMR CONTRACTS 150K 100K 50K 10K 310K
within our 3M budget recommendations.
This was a reducing line because the main need was up front. The actual level was arrived at mainly as a reasonable proportion of the budget, rather than by detailed assessment of need.
All this was summed up in the SUMMARY OF MAIN RECOMMENDATIONS as
9 Extra Mural Research Contracts should be let to ensure vital developments, particularly software developments, take place. These Contracts should be approved by the Computing Facilities Committee following recommendations by the Transputer Applications Management Group.
As may be seen from the above, we expected that the EMRs would provide software needed on an early basis by many of the loan pool projects. We also expected that the software exchange library, which we saw as a complementary part of the initiative activity, would be primed by the first EMR software, encouraging others to contribute, too.
3 The contracts
The material to hand consists of the reports resulting from the funded projects. Some of these have a contract number, some a contract date, but most have only a title and a publication number. Some don't even have a publication number. This is rather unsatisfactory for a reporter, since closely related projects tended to get widely spaced publication numbers.
As well as reading what each had to say, I noted the length of each report as a very crude measure of content, and the number of references as an even cruder measure of scientific method.
I then allocated totally subjective marks on each of the two criteria which are used for assessment of research grant final reports.
3.1 N2A BR 0751
P2 Software Migration Aids for Transputer Systems
The first project created a harness for a Fortran Farm, an environment in which a (user-written) root Fortran process partitions a suitable problem into pieces which are dispatched by the harness to a number of instances of a (user-written) worker Fortran process. Each such instance works on its own transputer in parallel with all the other instances. The results from the individual workers are recollected through the harness and provided to the root for collation and output.
P2 also notes the possibility of a more general message router, identifies the important properties which such a router must have, and reports the implementation of an initial version.
The extension project took the general router implementation much further.
This was clearly creative. The general router was the archetypical example envisaged by the working party of necessary software.
The first report (P2) contains 8 pages of report plus 13 pages of documentation for the Fortran Farm. There were no references. The second report (Pl5) contains 34 pages of report (with 14 references) plus 19 pages of user guide for the general router.
This work was also reported in the proceedings of both the TA89 and TA90 conferences.
Scientific Merit: Very Good
Value for Money: Very Good
3.2 N2A BR 0746
P3 Feasibility Study into a Parallel Extracting Fortran Compiler
This solid piece of work contains three main sections within which are found scholarly surveys of the existing literature, experiments into aspects not covered in the literature and analysis of the collected information. The only criticism I could find to make was the absence of a contents page.
The report contains 80 pages, making 68 references
Scientific Merit: Outstanding
Value for money: Excellent
3.3 N2A BR 0775
P4 Numerical Libraries for Transputer Arrays
The first report (P4) is a slim but very perceptive document. I believe, with the authors, that the provision of libraries is a much more effective way of achieving high performance for much application code than diving in at the original detailed code, even if it does mean making transplants which replace significant amounts of the original software. This work sets out the ways in which it can be approached.
The second report describes a solid piece of development work, building on the first library, and extending its technology.
The first report contains 19 pages and makes 17 references, almost all of which are to working papers presumably available from the authors.
The second report contains 24 pages including figures, with 13 references, again mostly local.
Scientific Merit: Very Good
Value for money: Very Good.
3.4 N2A 8R 0747
P5 Finite Element Software for Transputer based Parallel Processors
It is not clear to me whether this EMR was intended as a simple demonstrator, or as software to be used by others. I find the idea of an FE program operating only on a fixed simple geometry rather limited; my own work in the same area started from the assumption that FE users needed to be able to solve differential equations over complicated geometries, and that there was no alternative to reading in lists of nodes and elements. This work focusses on the solution process, using a geometric partitioning over the transputers, an interesting approach, made artificially easy by the choice of domain.
However, I understand that the components the software was built from were strongly influenced by the (serial) FE library which has been available through RAL for many years and is widely used. This work is probably directly applicable to the users of that package.
The report contains 6 pages of report, 6 of theory and 36 of subroutine specifications, and makes 6 local references.
Scientific Merit: Good
Value for Money: Good
3.5 N2A. BR 0748
P6 OCCAM binding for GKS (level 0a implementation)
GKS was the first internationally standardised set of graphics system calls. The standard identifies functions, but each language then needs a binding to actual procedure names. This detailed piece of work identifies a number of conventions and then applies them systematically to the working out of an Occam binding. The title of the project indicates that a partial implementation was also included, but I do not see any evidence that such an implementation exists, and have no information about what actual graphics devices are supported if so.
The usual SERC criterion of scientific merit is not relevant here. This kind of work does not create new science, it helps to speed others' scientific activity. To my thinking it is exactly what EMRs are for.
Value for money: Good, (Very good if there really was an implementation.)
3.6 N2A BR 1342
P7 Evaluation of the Meiko Multi-user Transputer environment
The authors were responsible for supplying a multi-user computing service resource using a Meiko system. This report tells of that experience, and is thus far from a paper evaluation exercise. It is not, therefore, a traditional piece of scientific research, but very valuable to the community (particularly I imagine to Meiko ). Easy to read, but not woolly. I did find it infuriating that the report contained no date, as the authors must have realised how rapidly both the capabilities and the robustness of such systems change with time.
The report contains 44 pages and 7 references
Scientific Merit: Very Good
Value for Money: Excellent
3.7 N2A BR 1344
P8 Feasibility Study into a Distributed Supercomputer.
This is a real fun study of an idea which was doing the rounds at the time this work was commissioned (though again the date is missing). The report takes seriously the idea of joining the larger academic transputer installations together through some networking medium to form a very large computing resource, and by analysing various options quantitatively comes to the clear conclusion that the numbers don't stack up, and that the idea should be forgotten. Since I have heard no more of it, I assume that this report's arguments convinced others as well as me. In the event it turned out to be a thoroughly workmanlike demolition job, though it is obvious that the authors did not start with that pre-conceived idea.
It is interesting to compare this analysis with stories of graphics projects distributing their frames for overnight raycasting over all the SUN 3's on the east coast of the USA, using ARPAnet. To the extent that the academic transputer machines are actually accessible through JANET, the decision not to make special arrangements does not preclude similar activity here.
While I do not feel that this project was what we had in mind when proposing the EMR budget, I would have been very tempted to fund it had I been on TAMG at the time, and I would have regarded the resulting report as vindicating that decision.
The report contains 55 pages but no references that I could find, even to the sources listing PTT services and prices.
Scientific Merit: Very good
Value for Money: Excellent
3.8 N2A 8R
P9 Application of Parallel Processing to Design Reasoning
A short report from a small project, assessing the problem of applying multiple processors to an AI software in which the main computation follows chains of deduction through a plex of design rules.
The conclusions are mainly negative, but I find this valuable. If there are applications which are not suitable for parallel implementation it is useful to know that fact. In view of the tiny amount of funding required to make this happen, one wonders whether the EMR contract was the right funding mechanism. The actual activity was mainly thoughtful study rather than the action learning more typical of loan pool projects, and so use of the EMR route can be defended.
The report contains 16 pages, and makes 11 references
Scientific Merit: Good
Value for Money: Excellent
3.9 N2A 9R 0933
P10/P18 Parallel Language facilities for Transputer arrays
This contract was let to a consortium of three universities, Queens University Belfast, Liverpool and Brunel.
It is not obvious why the work done in this project was funded as one EMR instead of three, as the three participating institutions carved the work up so well that each could focus on their own part with almost no dependence on the other two.
The bulk of the material consists of sound surveys of the state of the art
I understand that the work done under this contract has led to further projects funded by other agencies, and may well lead in due course to the creation of a parallelising compiler directly relevant to transputer-style parallelism.
P10 contains 16 pages of the three executive summaries and 44 pages of report from QUB (including another copy of their executive summary). P18 contains 45 pages of report from Brunel (again including a copy of the executive summary)
Scientific merit: Very Good
Value for money: Good
3.10 N2A 9R 1842
Pl4 A Study in Multilevel Image processing
Although this report has a title about image processing it is actually about the issues of parallelising existing Fortran programs for image segmantation and analysis in a particular application. This particular port may be characterised as of difficult, non-portable Fortran but with the full cooperation of the owners (in contrast to the project described in Pl9). I was sad that there was relatively low ambition in terms of number of transputers, but that can probably be justified in terms of target performance for a real-time system.
The report contains 15 pages but no references.
Scientific Merit: Good
Value for Money: Very Good.
3.11 N2A R 1842
P19 Parallelisation of the Phoenics CFD code.
Phoenics is one of the more widely used finite difference codes for solution of Computational Fluid Dynamics problems. This report should definitely be read in conjunction with Pl4 mentioned above. Although Phoenics is presumably reasonably clean and portable since it is available commercially on a wide range of machines, the absence of adequate direct active involvement by the owners of the code caused a whole new set of problems. I got the impression that the project was not regarded as a successful parallelisation by anybody. Never mind, the lesson that the owners of a piece of code have to take an active part in its parallelisation is an important one, with implications for parallelising compilers as well as for human parallelisers.
The report contains 29 pages but no references.
Scientific merit: Good
Value for Money: Good
3.12 N2A 2R 0557
P20 Application of Fourier Transforms
Although the objectives of the project were claimed to be the development of a library of Fourier routines, the bulk of the report focusses on the application, which is the image analysis of micrographs of turned components to determine the effects of tool wear. I was delighted to see that the basic numerical libraries developed in an earlier EMR were taken as the starting point. However, this project does not seem to me to have been appropriate for EMR funding. It should have been a subject committee grant or a loan pool project.
I find it useful to compare the work done here with the explicit parallelisation projects Pl4 and Pl9. Presumably the authors were starting from some existing Fourier transform routines and application programs to which they had full access.
Scientific Merit: Competent
Value for money: Good
3.13 N2A 9R 0551
P21 Port of GRAIL to a PC.
GRAIL is a visualisation package developed in the Alvey Parsifal project as a tool for tuning software running on multiple transputers. It was originally written using the proprietary SUN graphics, and this project created a version running on PCs.
The suggestions that the YACC LEX front end should be used for other tools is one I would like to see followed up. The sharpness of the OCCAM compiler in finding programming errors indicates the basic soundness of the underlying language, and I feel that a development of full static analysis facilities would give a language highly suitable for safety critical programming even if no parallelism were involved.
The report contains 56 pages including 36 of appendix and makes 4 references.
Scientific Merit: Very Good
Value for money: Excellent
3.14 N2A 9R 0967
Port of some NAG packages.
This is an honest report about three proposed pieces of work of which one and a half had been done by the time of the report with delays outside the control of the contractor.
Two useful packages (the NAG graphics chapter and GLIM) were ported to single transputer implementations, good reasons being found why they were not suitable for parallel implementation. Difficulties of access prevented work on the third (GENSTAT) in the originally planned timescale. The lesson must again be that full active commitment from the owner of software must be present before any parallelisation can be really successful.
This report has not been published in the P series, presumably because it was felt at the time that a further, more complete version would arrive in due course. Instead it was included in full in the September 1989 Mailshot.
The report contains 11 pages but no references
Scientific merit: Competent
Value for money: Good
3.15 N2A 9R
Occam Transformation System Project
The transputer initiative provided a small tranche of funding for the completion of a project at the Oxford Programming Research Group into machine transformations of OCCAM programs. This work was used by INMOS in the development of the T800, and contributed to the earning of a Queen's Award for Technological Achievement.
The report in front of me contains 4 pages and makes 4 references.
It is clearly an administrative report identifying what has been done when, rather than a scientific paper. I do not recommend that the Initiative publish it, but that a pointer be made to the fuller publications which describe the work in more detail.
Scientific Merit: Excellent
Value for money: Very Good
3.16 N2A 9R
This document, was the original P1, which has been withdrawn from publication as, after an initial surge of interest, with over 100 copies distributed, requests dropped to zero. It has now been superseded by the OUG bibliography
It contains some 84 references, with occasional value comments, to papers and books relevant to transputer use. It does not include those papers in the major transputing conferences, whose lists of presentations should be treated as complementary.
Despite being dated January 1988 it contains many 1989 and even 1990 references.
4 Other Outcomes
The first level of outcomes are the reports themselves. These have received sufficient comment above.
The other outcomes are the software created by the projects, and scientific papers reaching a wider audience.
I looked through the list of items in the software exchange library, as published in the August 1991 Mailshot, and found very few which could clearly be identified with EMR projects. Only P2/Pl5 and P4/P11 seemed to have got through. The extent to which even these reached the intended beneficiaries is reported elsewhere in these proceedings.
This is disappointing.
If this benefit did not really emerge, did the EMR programme result in lots of good work which has been getting out of the initiative in other ways? I looked through the contents lists of the Initiative's own conferences, and found that the work appearing there was again P2/Pl5 and P4/P11.
I asked each of the contractors to let me know if they had been able to exploit the work done by publishing through other routes. A couple had, but I heard nothing from the majority. I hope this only means that they didn't tell me, but I fear that the excellent work done may not be getting exposed in the ways it should be.
5 Summary Table
In this table I have tried to provide some factual detail about the projects, and also my subjective assessments. The latter have no official standing at all and are not being recorded and used in the way that the assessments of research grants are. This is a pity, as they indicate the high quality of the work done.
The columns are:
- Publ no
- the reference number of the report in the Initiative's list
- the contract price
- the number of requests made for the report between Sept90 and Oct91
- my subjective marking for scientific merit Competent/Good/Very Good/Excellent/Outstanding
- my subjective marking for value for money
- my subjective view of the alignment of this project with the original purposes of the EMR line in the Initiative budget
Publ no cost (£K) requests ScM VfM Alignment P2 10.5 16 V V perfect Pl5 22.0 14 P3 13.5 30 O E good P4 27.0 34 V V excellent P11 20.0 29 P5 8.0 21 G G OK P6 16.0 11 G excellent P7 14.0 18 V E OK P8 7.0 8 V E questionable P9 1.0 10 G E questionable P10 32.0 37 V G doubtful P18 9.0 12 Pl4 6.5 31 G V P19 31.5 9 G G P20 10.0 7 C G inappropriate P21 18.5 4 V E excellent NAG port 16.5 C G excellent transforms 8.0 E V excellent TOTALS 281.0 301
6.1 Scientific Merit
I am extremely impressed by the overall quality of the work done. In a collection this size, one would have expected some proportion of the projects to turn out less than competently carried out. There were none. I hope not to lose friends whose work I have marked as merely good. Good does mean good, even if other projects deserved Excellent or Outstanding accolades.
6.2 value for money
So, 281K got spent, and during the comparatively recent period when records were kept of how many copies were requested (September 1990 onwards) 301 copies have been sent out. Counts were not kept from earlier, but allowing for the progressive coming available of the reports a guess that the same number were distributed in the previous period is not likely to be far out. The cost per distributed copy is thus well under 1K each in the monitored period, and probably about half that altogether. This is actually quite good value when one thinks of commercial reports copies of which may easily bear a 2K price tag.
By my subjective rating of the projects by their final reports, the average is a great deal higher than for SERC research grants as a whole.
6.3 alignment with original objectives
Some of the projects were exactly what the working party had in mind in its original recommendations. Notably the Southampton harnesses and the Liverpool libraries.
Some of the projects should really have been centre projects for clients covered by the normal funding arrangements for the centres. The examples here are the parallelisation jobs (Phoenics and the image processing application), and the application of Fourier transforms.
It would be very interesting to add examples of parallelisation projects funded by other mechanisms to see what can be learnt of how to go about such work in future, but this is outside the scope of this report.
Others were studies which I recognise the value of, but which have not led to tools for others to use within the timescale of the Initiative.
I hope that the decision to widen the EMR remit was a conscious one by TAMG.
I fear it may have been just tactics as good proposals came forward. My worry is that if only a third or less of the EMR budget was spent on the originally intended remit, a lot of developments which could have made loan pool recipients' life easier may have had to be foregone.
7 Technical lessons
I shall not repeat here all that I learnt by my (multiple) readings of all these reports individually. You can determine from the list of titles what might be of interest to you, and read them for yourself.
What is useful here is to pull out the lessons which have come from putting projects side by side.
The most interesting of these for me was the comparison of the parallelising jobs (which I don't think should have been funded this way, but which I shall take advantage of nonetheless).
The Phoenics port was of commercially supported software. Almost certainly good portable code, far from the mythical dusty deck, and yet as far as I can read between the lines the parallelisation was unsatisfactory. Certainly we don't hear of Phoenics being offered commercially on all the transputer based machines.
Compare this with the image processing project, where poor, strongly non-portable code was none the less brought to a state where an implementation worked to the satisfaction of those involved, with useful speedups. The difference was the strong involvement of the customers whose code it was.
Reading a little between the lines of the Camborne project, I guess that they already had interests in and even serial code for their application. Acting as their own customers they achieved successful parallelisation.
It would be very interesting during this meeting to hear whether this is a general experience of parallelisation projects carried out by the centres with other funding. It is certainly true of other projects in my experience.
7.2 How many processors?
What I found disappointing about many of the projects was their lack of ambition in terms of large numbers of processors. So many took the line that as the implementors only had five transputers the technique chosen to be applied was that which worked well at that level, even if it could be predicted that such a choice would strongly limit the later extension to much larger numbers.
All three of the parallelisation projects suffered from this, as did the FE project.
Block cyclic reduction is an interesting and theoretically significant technique, but its obvious implementation works best when the number of processors is equal to the diameter of the adjacency graph of freedoms. A typical industrial FE problem is a piston which has a stiffness matrix with 10000 degrees of freedom and a bandwidth of 500; a diameter of only 20. Other parallel solution techniques can apply a number of processors proportional to the square of the bandwidth. Even with the constant of proportionality derived from the block sizes you need for the T800's computation to communication ratio the limit can be as high as 1000, and for the larger problems which having many transputers will encourage, the available parallelism in the more conventional solution techniques goes up much faster.
If currently preferred routes towards general purpose architectures are followed we shall need extremely fine partitioning of tasks to make use of even medium high numbers of processors, and so this may become even more important than it is now.
Almost all the work focussed on Occam and Fortran. The earlier reports reflected the fact that the TDS was the only practical way of building real software at the time (I understand that one or two of the earliest projects depreciated fairly rapidly due to the changes between Occam versions, there being no supplementary contracts to update them), but I do not detect in the tone of the later ones any feeling that Occam is going away.
I recently had to do some Fortran development, having worked primarily in Occam for some time, and I really missed the security of the Occam environment, where the compiler checks for so many of my silly mistakes. It was therefore heartening to note that several of the authors were also aware of the benefits of a well-designed language, in which the parallelism features, if not the data structures, were really high level ones, saving the software writer from worry about low level details like synchronisation and blocking.
Perhaps now is the time to float the idea of taking the base of the transformation system and/or the YACC/LEX Occam parser, and building a full static analyser. The one loophole which I have fallen into in writing Occam is the absence of detection of the use of unassigned variables. If any language can support the automatic finding of such cases, Occam can.
It may also be sensible to enquire as to whether the automatic finding of parallelism in a serial program would be easier in a strongly structured language like Occam, where there are far fewer mechanisms for side-effects than in the conventional procedural languages. As Occam has turned out to be a delightfully simple language to generate by software, a serial Occam to parallel Occam translator could be an excellent environment for exploration of the inherent problems in automatic recognition of parallelism.
The individual projects ranged in their execution from competent via outstanding to excellent. None were particularly expensive by research grant standards, and even those reporting negative results nailed down what the difficulties were, in a way that definitely added to our knowledge. If re-publication of the P series as a single volume would significantly expand the readership, I would strongly support it.
However, the programme as a whole would have been much more effective in meeting the original objectives if
(i) there had been a serious procedure to formulate a list of essential tools, and find the right team to address each one.
In fact the contracts did go to competent teams; the problem was in the coverage of the needs. I understand that the bulk of the projects were proposals from the regional centres (the decision to use these contracts to pump prime the centres was a totally justifiable tactic), and therefore reflected their interests rather than being considered together as a programme.
It does not appear to me that TAMG did an adequate job of thinking about needs and designing a programme to cover them.
The supplier representatives on the original working party could have played a useful part in this. I guess that they perceived the initiative more as an immediate market than as a lubricator for the medium term market. In view of the state then of the transputer box market that would be totally understandable.
In the event the proposals for EMR contracts were largely made by the teams which carried them out. They could also have been looking on the initiative more as a market for their research ability than as a customer with a programme of needs. This again carries no blame.
The initiative should have lain with TAMG to think through and set out a programme of requirements.
(ii) there had been a more solid mechanism from the outset, for the provision of the software that was built by the EMR projects as a matter of course with all loans from the pool.
The job wasn't done when the deliverables arrived at Rutherford. Just advertising a list of bits of somebody else's software, that you can get a report about if you write in for it, is not actually an effective way of getting common software used by people who are themselves competent programmers, and who don't know, when they start, what they need. By the time they find out what they need they will already have implemented initial versions of harnesses etc. and will not want to change.
In assessing the EMR programme as a whole we are faced with two conflicting indicators. On the positive side there is the excellent work done. None of the money was wasted, even in hindsight.
On the negative side is the feeling that the portfolio is less than coherent, and that the work done has not been effectively exploited.
The only way out of this is to allocate a middling mark, the Satisfactory which the majority of SERC grants earn.
 Engineering Applications of Transputers; the report of a Working Party Computing Facilities Committee of the Engineering Board, SERC. October 1986
 P2 EMR report: Software Migration Aids for Transputer Systems A.G.Hey, J.S.Reeve, M.Surridge, University of Southampton.
 P3 EMR report: Feasibility Study into a Parallel Extracting Fortran Compiler. S.K.Robinson, P.van Santen, Brunel University.
 P4 EMR report: Numerical Libraries for Transputer Arrays N.G.Brown, L.M.Delves, University of Liverpool.
 P5 EMR report: Finite Element Software for Transputer based Parallel Processors. R.Wait, University of Liverpool.
 P6 EMR report: Definition of Occam Binding for GKS and Level 0a Implementation. D.B.Arnold, M.R.Hinds, University of East Anglia.
 P7 EMR report: Evaluation of the Meiko Multi-user Transputer Environment. P.H.Welch, Computing Laboratory, University of Kent.
 PB EMR report: Feasibility Study into a Distributed Super-Computer P.F.Linnington, G.E.W.Tripp, P.H.Welch, University of Kent.
 P9 EMR report, The Application of Parallel Processing to Design Reasoning K.J.MacCallum, A.Craig, The CAD Centre, University of Strathclyde.
 P10 EMR report: Parallel Language Facilities for Transputer Arrays. L.M.Delves, University of Liverpool, RH.Perrott, Queens University Belfast, S.K.Robinson, Brunel University.
 P11 EMR report, Numerical Libraries for Transputer Arrays (Extension). L.M.Delves, University of Liverpool
 P 14 EMR report: A Study in Multi-level Image Processing. D.Crookes, P.J.Morrow, Northern Ireland Regional Transputer Centre.
 P15 EMR Report, Software Migration Aid, for Transputer Systems (Extension). A.G.Hey, J.S.Reeve, M.Surridge, University of Southampton.
 P18 EMR report, Parallel Language Facilitie, for Transputer Arrays, 'Concurrentisation Techniques and Granularity Effects' S.K.Robinson, P.van Santen, Brunel University.
 P 19 EMR report: Parallelisation of the Phoenics CFD Package. A.J.Reid, National Engineering Laboratory.
 P20 EMR report, Development of Fourier Transform based Algorithm, for the Transputer and An Investigation into the use in the Processing and Analysis of Digitized Images of Single Point Steel Surfaces. J.A.Sominka and A.D.Lamb, Camborne School of Mines.
 P21 EMR report, Port of the Grail Transputer Performance Monitoring Package to a colour PC. M.R.Hinds and R.Sleep, University of East Anglia
 Porting Nag Packages to Transputer Arrays: Draft Final Report L.M.DeJves, S.Downing and T.Oliver, University of Liverpool.
 Final Report on Transputer initiative funded OCCAM Transformation System project. Oxford University Computing Laboratory Programming Research Group.
 Transputer Bibliography A.J.G.Hey and M.R.Sleep
 Applications of Transputers 1 ed L Freeman and C Phillips; IOS Press 1990
 Applications of transputers 2 ed D J Pritchard and C.J Scott; IOS Press 1990
 Applications of transputers 3 ed T S Durrani et a.1; IOS Press 1991
 Transputer Initiative Mailshot, August 1991.
 Transputer Initiative Mailshot, September 1989.
[26-29] private communications from: R.Perrott, K.MacCallum, R.Wait, A.Lamb
[30-34] private communications from: D.Arnold, D.Crookes, M.Delves, A.J.G.Hey, M.Jane
This report was written under contract N2A 3R 0663 of the SERC/DTI Transputer Initiative for the Transputer Initiative Symposium to be held on March 30 and 31, 1992.
Since submitting the above report on the original deadline, I have received further clarification and information from the original EMR contractors, and from the Initiative Coordinator.
Particular points worthy of note are:
- that in some cases Initiative funding enabled the completion and reporting of work already started on some other basis. In at least one case, other funds were used to subsidise the completion of the EMR work. While these effects go some way to explaining my high value-for-money ratings, I do not want to revise those ratings down. What was produced was good value for the Initiative funding, and deserves recognition as such.
- that the P10/P18 project was in fact the subject of three separate EMRs. My comments on it being effectively separable still apply at the project level.
- that the work of P14 was reported in TA91 and that of P6 in Computer Graphics Forum. I apologise to any other authors whose publications I have missed.