Assignment 2

InterComm

Not so fine print: The requirements for this assignment are intentionally vague.

This assignment will be partitioned into very small sub-assignments with tight deadlines to help the students manage their time effectively throughout the semester.
  • Assignment 2.1: Due date: Feb. 10, 2007: Rewrite the problem described in this assignment so that it is no longer vague. Hand-deliver it to your TA and make sure that the TA agrees with your interpretation of the requirements. Finally, e-mail your final problem description to the TA. SUBJECT of the e-mail should be "CMSC 433 -- Assignment 2.1". (10% of Assignment 2 grade.)
  • Assignment 2.2: Due date: Feb. 20, 2007: Devise an algorithm to compute the number of ways to compile InterComm, keeping in mind the constraints. E-mail your solution to the TA. SUBJECT of the e-mail should be "CMSC 433 -- Assignment 2.2". (10% of Assignment 2 grade.)
  • Assignment 2.3: Due date: Mar. 26, 2007: Once you are sure that your above algorithm is correct, implement it in Java. Remember that the dependency DAG can change -- it is better not to hard-code it in your program. Also remember to write JUnit tests and JavaDoc for all methods/classes. E-mail your solution to the TA. SUBJECT of the e-mail should be "CMSC 433 -- Assignment 2.3". (20% of Assignment 2 grade.)
  • Assignment 2.4: Due date: Apr. 17, 2007: Use the above implementation to output build-sequences in a standard notation (agreed upon by entire class). Write a program that processes each build sequence and determines if it is valid with respect to the InterComm graph, package versions, and constraints; filter out the incorrect sequences; count the remaining valid sequences; ensure that your count matches the other counts computed by your classmates. Remember that the dependency DAG can change -- it is better not to hard-code it in your program. Also remember to write JUnit tests and JavaDoc for all methods/classes. E-mail your solution to the TA. SUBJECT of the e-mail should be "CMSC 433 -- Assignment 2.4". (60% of Assignment 2 grade.)

    Description

    As stated in its User's Manual, "InterComm is a framework for coupling distributed memory parallel components that enables efficient communication in the presence of complex data distributions. In many modern scientific applications, such as physical simuations that model phenomena at multiple scales and resolutions, multiple parallel and/or sequential components need to cooperate to solve a complex problem. These components often use different languages and different libraries to parallelize their data. InterComm provides abstractions that work across these differences to provide an easy, efficient, and flexible means to move data directly from one component's data structure to another.

    The two main abstractions InterComm provides are the distribution, which describes how data is partioned and distributed across multiple tasks (or processors), and the linearization which provides a mapping from one set of elements in a distribution to another."

    InterComm supports programs written in C, Fortran77, Fortran90, and C++/P++. InterComm may be compiled on different types of systems, each with different underlying operating systems, native libraries, compilers, etc. The final choice of the underlying system configuration depends on the application domain, availability of resources, and expertise of the programmers. The hope is that InterComm compiles correctly on many varieties of systems.

    The InterComm build package dependencies may be viewed as a DAG. Each oval represents a package; directed edges represent dependencies. A rectangle with "+" represents an OR dependency, e.g., the package AP may be compiled using either MCH OR LAM. A rectangle with "*" represents an AND dependency, e.g., the package GF is compiled using GCR AND MPFR AND GMP.

    We will limit our scope to the following versions of each package:

  • ic 1_5
  • ezxml 0_7 0_8
  • nf 5_0 5_1
  • pf 6_1
  • gf 4_0_3 4_1_1
  • gmp 4_2_1
  • mpfr 2_2_0
  • pxx 6_1
  • gxx 3_3_6 3_4_6 4_0_3 4_1_1
  • pc 6_1
  • gc 3_3_6 3_4_6 4_0_3 4_1_1
  • gcr 3_3_6 3_4_6 4_0_3 4_1_1
  • pvm 3_2_6 3_3_11 3_4_5
  • mch 1_2_7
  • lam 6_5_9 7_0_6 7_1_2
  • ap 0_7_2 0_7_5 0_7_9
  • fc 4_0

    The following constraints must be satisfied:

  • A package cannot appear with different version numbers.
  • A package version cannot appear with different building sequences.
  • GCR,GC,GXX,GF must have same version if they appear in a build. This constraint is subject to change; the package names/versions might change.