development of a physics application by a geographically distributed team
DESCRIPTION
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) - PowerPoint PPT PresentationTRANSCRIPT
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