Development of a physics application by a
geographically distributed team
John R. Cary
University of Colorado and Tech-X Corporation
for the
National 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)
1
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
2
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 welldefined 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
3
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
4
Modules accessible via the web
5
Modules page explains, permits access
6
Multiple types of modules available
7
Crucial for the Demo Code are the transport
coefficents
8
Modules must pass rigorous review
9
Review based on standards
Standard:
Standard:
Standard:
Standard:
Standard:
General Standards:
Provide source code for each physics module or code.
Provide test case(s) with driver program(s) with input and output data
and their documentation.
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.
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.
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
10
Standards also for documentation
Standard:
Standard:
Standard:
Standard:
Standard:
Standard:
Standard:
Goal:
Goal:
Goal:
Documentation Standards:
Provide Name of contact person for support.
Provide Date of last revision.
Provide at least comments describing module or code, citations to
publications (if any), and range of validity.
Specify the precision of floating point calculations.
Provide index of input-output variables for each module (include type
of variable, dimensions, units).
List dependencies -- names of external routines called.
Provide statement of known bugs.
Index of modules, routines, variables.
Publication of code or module in journal (such as Computer Physics
Communications).
Online hyper-text reference documentation.
11
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
12
Entry page permits access to data or
models
13
Data library and data server permit uniform
access to multiple data types
Requests
Data
DataClient
CORBA
NtdIdlDataSrvrImpl
libsrvimpl.a
libexpdata.a
UfileDataAcquirer
n
MasterDataAcquirer
n
Python Physics Server
PhysicsClient
MdsDataAcquirer
tcp/ip
(mdsip)
OtherDataAcquirer
C++ Physics Server
libexpdata.a usable as standalone C++ library
14
Java client allows interactive data
examination
15
Predictive transport code: model tester
• Web accessible
• Integrated
legacy code
• Flexible
communication
(CORBA)
16
Dynamically add plots
17
Follow evolution
18
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
19
Project requires extensive documentation
20
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)
21
Working platforms
aix-egcs1.1
decunix-cxx6.0
decunix-egcs1.1
hpux-egcs1.1
irix-CCn32
irix-egcs1.1
linux-egcs1.1
solaris-egcs1.1
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.
22
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, multiinstitutional team work together?
The Demo Project is answering these questions
23
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
24