[Prev] [Up] [Next] Domain-Specific Metacomputing for Computational Science:
Achieving Specificity Through Abstraction
By Steven Hackstadt

Footnotes

Chapter 1

(1) According to corporate press releases, the first three systems delivered as part of the ASCI program cost $46 mil lion (Intel), $93 million (IBM), and $110 million (SGI/Cray), respectively; the entire ASCI budget is nearly $1 billion over the next ten years.



(2) The ASCI performance requirements are based on benchmark results rather than theoretical machine performance; even so, the performance of real applications will likely be less (and in some cases significantly so) than the bench mark performance figures.



(3) Pancake defines "success" based on the "frequency and significance of tool use" [Panc94].



Chapter 3

(1) The second testbed, Globus Ubiquitous Supercomputing Testbed (GUSTO), was scheduled to begin in late 1996, but no literature on the project has yet appeared. Foster and Kesselman [FK96] suggest that this testbed will focus more on the computer science problems of metacomputing, such as authentication, scheduling, communication, and information.



(2) More recently, Wolski [WSP97] has proposed an idea similar to the hierarchical information policy used by Zhou et al. [ZWZD92] in the Utopia system.



(3) A full comparison between Cheriton and Mann's scheme and URLs is somewhat irrelevant since URLs define only a name space and Cheriton and Mann describe a complete name service. The comparisons we have made rely pri marily on the nature of the name space defined by Cheriton and Mann.



Chapter 4

(1) The Intel Paragon used the NX message-passing library and the GNU g++ and Intel C++ compilers; the IBM machines used the MPL communications library and the IBM xlC compiler; and the T3D used a modified version of PVM and Cray C++ [NSD95].



(2) The practical reason that DSSA research has not yet targeted computational science domains is that funding has largely originated from the Defense Advanced Research Projects Agency (DARPA), whose focus is naturally on defense-related application areas [Trac94].



Chapter 5

(1) Our use of the term "domain-specific environment" is consistent with the apparent first application of the term in this way by Cuny et al. [CDHH96]. In the same work, Cuny et al. also propose these three requirements for DSEs, though little discussion of their general importance to DSEs is presented therein. We attempt to expand on these ideas here and later in this chapter.



(2) The creators of GEMS, Bruegge et al. [BRRM95], do not use the term "domain-specific environment" to describe their system.



(3) Since the description of TIERRA by Cuny et al. [CDHH96], the TIERRA environment has abandoned use of Viz. Future work will likely utilize easier to use and more stable visualization packages [Harr97]. In terms of nonfunc tional requirements, this suggests that programmability and extensibility in the visualization component proved to be less important than ease of use.



Chapter 6

(1) Additional viewpoints are undoubtedly possible.



(2) It is in this spirit that we have applied the term in our own research [BHMM94, HM97].



(3) Italics in the excerpts are ours.



(4) With only a couple exceptions, all of the excerpts about frameworks in this section are taken from sources cited elsewhere in this discussion.



(5) Figure 10 is based on ideas from Shaw and Garlan ([SG96], p. 4, 12-13) and Wiederhold et al. [WWC92]. The figure is a composite of their ideas but includes our own slight modifications and extensions.



(6) We do not discuss those techniques here since they are not unique aspects of domain-specific metacomputing for computational science.




[Prev] [Up] [Next] Domain-Specific Metacomputing for Computational Science:
Achieving Specificity Through Abstraction
By Steven Hackstadt

Last modified: Wed Nov 5 08:15:46 1997
Steven Hackstadt / hacks@cs.uoregon.edu
http://www.cs.uoregon.edu/~hacks/