1. Software Design for
Scientific
Applications
Priyanka Lal
10515

2. • Why distribute software?
• Challenges in software design and distribution
• Ideas for simplifying software design
–Component design
–Interface design
–Software quality practices
• Challenges that remain in the picture

3. Distributing Software:
Why??
• For the strength of your research program:
–Wider group of reviewers of efforts.
–Greater opportunity for collaboration.
• For altruistic reasons:
–Contribution to scientific community.
–Personal satisfaction in seeing your work being used.

4. • Successful applicants of Enabling Technologies
must ensure that source code is fully and freely
available for use and modification throughout
the scientific computing community via a
preapproved open source process.
• For enhancing scientific productivity and for
facilitating research and education
collaborations through sharing of
data, instruments, and computing.

5. Challenges of
Scientific Software Development
• Managing customer expectations.
–Many funding sources.
–Long-term vs. short-term goals.
• Users: a mixed blessing
–Unpaid testers and debuggers.
–Contribute to greater exposure.
–Have needs and their own deadlines.

6. Time Challenges
• Research vs. Software Development
–Need to publish to gain tenure, advance in career.
–Software development takes time, and production
quality development takes a lot of time.
• “It takes a year to get back up to speed after a student
graduates.”
–Students often have little experience working in team
environments
–Students need individual research achievements while
contributing to team.

7. Technology Challenges
• Developing high-quality software isn’t easy.
–Careful design needed.
–Maintainability is important.
–Robustness takes time.
–Portability to wide range of architectures.
–Extensibility to new architectures.

8. Component Design
• Construct applications from smaller software “parts.”
• Components provide …
–Services applications commonly need.
–Support for wide range of applications.
–Easy-to-use interfaces.
–Data abstraction.

9. Advantages of Component Design
• For users:
–Smaller learning curve is better than large
framework.
–Easy to add to existing applications.
–“Expert” implementations instead of your own
imagination.
–Enable comparisons of different algorithms.
–Time and cost saving.
• For developers:
–Reduced dependencies between components eases
effort of working in teams.
– Separation of efforts for team members also allows
individual contribution with reduced conflicts.

10. Connecting Components
• Connect either through a framework like CCA…
–Common Component Architecture
–Environment that facilitates software
interoperability, programming language interoperability, and
dynamic composability.

12. Interface Design
• Goals:
–Broad application support
–Interoperability
–Ease of use in new or existing applications
• Abstraction:
–Identification of required features
–Removal of details
–Management of complexity
–Important for usability, maintainability, backward
compatibility
• Implementation strategies:
–Callback functions
–Object-oriented design

13. Which interface design to use?
• Abstraction is most important step.
–Logical separations of data and operations.
–Implementation approach is less important.
• Callback:
–Simple to specify.
–Easy to use.
• Object-oriented:
–More elegant, robust abstraction mechanism.
–Greater flexibility.
• Interoperability and standardization:
–Always nice to have.
–Can be implemented with callback or object-oriented
approach.

14. Zoltan Toolkit
• The Zoltan library is a toolkit of parallel combinatorial
algorithms for unstructured and/or adaptive
computations.
• Its data-structure neutral design allows Zoltan to be
used by a wide range of applications, including adaptive
finite element methods, particle simulations, linear
solvers, crash and contact detection, and electrical circuit
simulations.
• Zoltan also has graph coloring and graph ordering
algorithms useful in, eg., task schedulers, parallel
preconditioners and linear solvers.

16. Zoltan Interface
• Zoltan data abstraction:
– “Objects” with unique names to be partitioned.
• – Objects can have (weighted) dependencies to other
objects.
• Zoltan: Data-structure neutral design.
– Supports wide range of applications and data
structures.
– Imposes no restrictions on application’s data
structures.
– Application does not have to build Zoltan’s data
structures.

17. Software Quality
for Research
• Industry standards can be difficult to apply in
research environments.
–Level of formality too high.
• But we do many things prescribed in formal
quality models.
–Project planning: Proposals
• Includes budget, staffing, project goals and
milestones, requirements, approach.

18. A Minimalist’s Approach
to Software Quality Engineering
• Seven Easy Steps to improved software development.
1. Source Code Control
2. Backup System
3. Automated testing
4. Bug Tracking
5. Mailing Lists
6. Documentation
7. Release Process

19. Thank you