1

Development of a physics application by ageographically distributed team

John R. CaryUniversity of Colorado and Tech-X Corporation

for theNational Transport Code Collaboration:

Glenn Bateman, Jon Kinsey, Arnold Kritz (Lehigh University) John Cary, Kelly Luetkemeyer (Tech-X Corporation) Ronald Cohen, Ray Jong, Lynda LoDestro, Brian Yang (Lawrence Livermore

National Laboratory) Tom Fredian, Martin Greenwald, Josh Stillerman (Massachusetts Institute of

Technology) Dave Greenwood, Wayne Houlberg (Oak Ridge National Laboratory) Doug McCune, Dave Mikkelsen, Alex Pletzer (Princeton Plasma Physics

Laboratory) Holger St. John (General Atomics Corporation) James Wiley (University of Texas)

2

The primary goal of the NTCC is reuse “A code for every institution” no longer practical

Resource limitations Increased complexity of coding (parallel, OOP, client-server)

Reuse within existing applications (well documented and tested subroutines)

Transport coefficient calculations System dependency routines

Reuse of installation work through web availability Reuse of data

Network data service Wrappers to many data formats

Reuse of people: involvement educates in OOP Modern languages: Java, C++, CORBA Team software development

3

Reuse requires modification of code development in the Fusion Community

Construct a Web-accessible library of transport code modules which are required to meet a set of well-defined standards

Produce a flexible framework based on modern computing techniques for rapidly assembling customized Web-invocable  transport codes

Develop a demonstration code using this framework for testing transport models

Hold a series of seminars and workshops on the use of  modern computing techniques

4

National Transport Code Collaboration

Modules Library: http://w3.pppl.gov/NTCC/

Fortran subroutines that calculate transport coefficients

Routines that analyze data and solve for equilibria

Demonstration Project: http://electrojet.colorado.edu/wwwntc/

Put experimental data on line Examine experimental data through web Put predictive physics application (code) on line

5

Modules accessible via the web

6

Modules page explains, permits access

7

Multiple types of modules available

8

Crucial for the Demo Code are the transport coefficents

9

Modules must pass rigorous review

10

Review based on standardsGeneral Standards:

Standard: Provide source code for each physics module or code.Standard: Provide test case(s) with driver program(s) with input and output data and their

documentation.Standard: Provide script to compile and link (e.g., makefile). The script should make at least some

provision for portability to multiple brands of Unix (at minimum). Provide clear documentation (possibly in the README file) on how to use the script or makefile.

Standard: Provide a README file giving (a) the name of the module and its authors, (b) the location and form of general module documentation, and (c) information (or pointer to more detailed documentation) enabling a user to build binaries from the source code.

Standard: Provide documentation about how the module should be used, for example, whether the module needs to be initialized or used sequentially. Important usability issues, such as the existence of state information in COMMON or other static memory, which persists between calls, must be described.+ many more

11

Standards also for documentation

Documentation Standards: Standard: Provide Name of contact person for support.Standard: Provide Date of last revision.Standard: Provide at least comments describing module or code, citations to

publications (if any), and range of validity.Standard: Specify the precision of floating point calculations.Standard: Provide index of input-output variables for each module (include type of

variable, dimensions, units).Standard: List dependencies -- names of external routines called.Standard: Provide statement of known bugs.Goal: Index of modules, routines, variables.Goal: Publication of code or module in journal (such as Computer Physics

Communications).Goal: Online hyper-text reference documentation.

12

The Demonstration Code: new paradigm for code development

New technologies Object oriented programming Client-server through object oriented protocol Scripted physics server

Multiple code developers CORBA experts Java experts Physics experts OOP experts

Geographically distributed team Assemble the experts Broad institutional buy in Implies need for

Remote code distribution Remote collaboration

13

Entry page permits access to data or models

14

Data library and data server permit uniform access to multiple data types

MasterDataAcquirer

UfileDataAcquirer

MdsDataAcquirerNtdIdlDataSrvrImpllibsrvimpl.a

Requests

Data

n tcp/ip(mdsip)

CORBADataClient

Python Physics Server C++ Physics Server

OtherDataAcquirern

CORBA

PhysicsClient

CORBA

CORBA

libexpdata.a

libexpdata.a usable as standalone C++ library

15

Java client allows interactive data examination

16

Predictive transport code: model tester

• Web accessible• Integrated

legacy code • Flexible

communication (CORBA)

17

Dynamically add plots

18

Follow evolution

19

Project requires multiple languages

Java for client: rich set of graphical user interface components

CORBA-IDL (Interface Definition Language) for object-oriented network communication

Fortran: reuse existing legacy scientific code C++: High-performance, object-oriented data

server Python: Object-oriented scripting language for

rapid development

20

Project requires extensive documentation

21

Cross-platform development relies on "rules" database

Server works on all major Unix platforms, multiple compilers

"Rules" files define flags (compilation, linking) and locations of installed software (compilers, CORBA libraries, linear algebra libraries, interpreters)

System permits local variations (usually installation locations)

Working platformsaix-egcs1.1

decunix-cxx6.0decunix-egcs1.1

hpux-egcs1.1irix-CCn32irix-egcs1.1

linux-egcs1.1solaris-egcs1.1

22

Maintenance of multiplatform capability requires upgrade policy

Project packages have changed in one year: Project started with JDK1.1. JDK1.2 (Java 2, with much enhanced

capability) now available on some platforms Project started with Fnorb 0.5 (Python CORBA library). Fnorb 1.0b1

now available and requires recoding for different file structure Project started with egcs1.0. Egcs1.1.1 (binary incompatible with

egcs1.0) now used. Policy

Upgrades automatically okay (do but inform) if they do not change the build or run process

Server software (e.g., Python) requirements that change build process require group consent. Typically only when several months in advance of any time deadlines

Client software (e.g., move to JDK 1.2) upgrades wait until clients can run in Netscape or Internet Explorer on Windows and Linux.

23

Project has spurred group learning about OOP, modern code design, reuse, teams

How does one build reusable code? How does on use OOP techniques for physics analysis? How does one reuse legacy code in modern

frameworks? How does a geographically distributed, multi-

institutional team work together?

The Demo Project is answering these questions

24

Demo Project More than just Demonstration

Data server providing access to multiple formats(Exists, being rewritten as stateful, access to multiple data

types through common network interface)Dec 99

Physics server provides transport code tester(exists for GLF23, Multi-Mode, IFS/PPPL, linear critical

gradient) C++ physics server in progress Data client currently providing data access Physics client currently providing access to

physics