Multi-Site DIVIMP Development:

Some Organizational Suggestions

J.D. Elder

University of Toronto

Institute for Aerospace Studies

October 13th, 1998

 

 

 

 

 

Table of Contents: Multi-Site Code Development

Objectives

Solution Strategies

Conclusions

 

 

 

 

 

 

Multi-Site Code Development

The DIVIMP code is now being independently worked on at JET in the UK (combined with the EDGE1D, EDGE2D and NIMBUS codes), Juelich in Germany (KFA) (combined with B2 and EIRENE), Asdex Upgrade at Garching (Germany), DIIID in San Diego (USA), Tokamak de Varennes in Quebec, CMOD at MIT in Boston (USA) and at UTIAS in Toronto. The number of users and sites where this code is used may continue to grow, and as this occurs, the logistical problems in maintaining a base and reference version of the code will also grow.

This document is intended as a draft, proposing methods and simple procedures to make the development and maintenance of DIVIMP at multiple sites by multiple persons both easier and more efficient. With three or four numerical modeling codes which are becoming interoperable and whose source code is being modified in an independent fashion at a number of different sites, it would be valuable if consistency and compatibility between the codes could be maintained. The following are suggestions intended to reduce or eliminate difficulties that may arise in this regard. Further recommendations and suggestions on how to make the independent development and subsequent reconvergence of the resultant DIVIMP versions as quick and painless as possible are happily welcomed.

Objectives

1) Consistency

2) Portability

3) Software Engineering Issues

There are a number of strategies which can be employed to meet these objectives. The single drawback is that the time required for a specific code addition will be increased by a finite amount. However, in the long run, the information recorded about any code addition will increase the efficiency of later additions. Furthermore, such information will also make the codes much easier to understand for new people using and developing them. These advantages will overcome the cost of the additional time required to maintain the code.

Solution Strategies

Consistency:

A. Designate Primary Site

B. Keep track of Users

C. Periodic Updates from the Primary Site

Portability:

DIVIMP is now known to run on a variety of platforms. These include an IBM 3090 mainframe, a Cray YMP and XMP, as well as IBM RS6000, Sun, and SGI workstations, and even a test version on an IBM PC (Pentium 90). The reason this is possible is because system dependent code has always been as isolated as possible in the development process.

A. Bundling of Necessary Subroutines

B. System Specific Routines

C. Language Standardization

Software Engineering Issues:

A. Records of Changes

B. Documentation

C. Responsibility

D. Programming Practices

E. Programming Techniques

F. Interfaces

Conclusions:

These are just a few suggestions, any others would be appreciated. This document is intended to encourage organized cooperation without unduly interfering in any group's DIVIMP development activities. The ideas presented are aimed at making the development of this modeling code, especially when used in conjunction with other codes as consistent and unified as possible. If one considers that the current generation of Tokamaks will be operating for at least another two years and that ITER modeling may well be required for another 10, 15 or 20 years then keeping these codes in a form that can be made into a useful tool as our knowledge base increases is of paramount importance. This can only be done successfully if the people who work on the codes tomorrow understand what is being done today. This can be best accomplished by producing well-written modeling routines with in-line documentation that describes the processes and procedures utilized in the model and by structuring development in such a way that little is lost or wasted. The suggestions contained here are aimed at this goal.