| Risks |
| Parallelization techniques may become outdated within a few years. |
| Load balancing is difficult and ensuring optimality is |
| virtually impossible. |
| The PPF will be interfacing with BLUE's hardware which |
| is experimental and unproven in stability. |
| Misuse of the PPF will compromise its performance. |
| Simplifying the interface may compromise the library's |
| functionality. |
| The nature of the project requires facing problems which |
| have not been dealt with or mitigated in the past. |
| There is an uncertainty that the requirements requested |
| are doable. |
| Mitigation |
| The parallelization mechanism should be abstracted from |
| the functionality of the PPF so changes to a new technology will not be |
| difficult. |
| It should be understood by the developers who use PPF |
| that the load balancing may not be optimal. |
| Frequent comparison between builds on a proven system |
| such as the TERA cluster will help isolate errors caused by anomalous |
| behavior by BLUE. These problems can be brought to the attention |
| of Livermore Computing and/or IBM. |
| Careful and comprehensive documentation will help prevent |
| product misuse. |
| The priorities within the project must be analyzed prior |
| to design. If one decision compromises another the one with higher priority is chosen. |
| If a perfect algorithm cannot be developed to handle all |
| cases, a heuristic will have to do, and all shortcomings of the algorithm used |
| must be documented. |
| If the requirements prove to be to difficult a review of the |
| requirements must be brought before the clients and an acceptable compromise |
| must be reached. |