1. 1 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)

2. 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. 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. 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. 5 Modules accessible via the web

6. 6 Modules page explains, permits access

7. 7 Multiple types of modules available

8. 8 Crucial for the Demo Code are the transport coefficents

9. 9 Modules must pass rigorous review

10. 10 Review based on standards General 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. 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. 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. 13 Entry page permits access to data or models

14. 14 Data library and data server permit uniform access to multiple data types MasterDataAcquirer UfileDataAcquirer MdsDataAcquirer NtdIdlDataSrvrImpl libsrvimpl.a Requests Data n tcp/ip (mdsip) CORBA DataClient Python Physics ServerC++ Physics Server OtherDataAcquirer n CORBA PhysicsClient CORBA libexpdata.a libexpdata.a usable as standalone C++ library

15. 15 Java client allows interactive data examination

16. 16 Predictive transport code: model tester Web accessible Integrated legacy code Flexible communication (CORBA)

17. 17 Dynamically add plots

18. 18 Follow evolution

19. 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. 20 Project requires extensive documentation

21. 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 platforms aix-egcs1.1 decunix-cxx6.0 decunix-egcs1.1 hpux-egcs1.1 irix-CCn32 irix-egcs1.1 linux-egcs1.1 solaris-egcs1.1

22. 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. 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. 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