Archetypes
The archetypes define common types of projects. They can offer some clarification on the kind of services we offer, as well as give some inspiration on what to improve. Each archetype is defined by a problem statement, which describes in very general terms a situation a user can find themselves in, and by an expected out-come, which describes, again very generally, the solutions we can offer and how they could affect user software.
Portable Build System
Problem Statement: Your software runs (or has been run) on different clusters. However, getting it to run on a new cluster requires a lot of manual work. For example, build scripts have to be changed manually, otherwise it can't even be installed.
Expected Out-Come: Your software is equipped with a simple and easy-to-use setup that adapts to each new system. Getting your software to run on new systems is trivial, and in the ideal case it is an automated setup that requires just a single line in the terminal. One realization could be a containerized setup, e.g. a Docker image that bundles all requirements and provides the software in a ready-to-use state.
Language Bindings
Problem Statement: Your existing software is implemented in a lower level language, such as C/C++/Fortran/etc. It has a high value, perhaps in terms of performance, or provided functionality, but it also has a high entry barrier due to the complexities from the low level programming language. As a consequence, your software is not as widely used by application scientists.
Expected Out-Come: Your code has an interface through a higher level language, such as Python/Julia/Matlab/etc. It is easy to use for non-developers and scientists unfamiliar with the underlying lower level language, while providing the same performance and functionality as the original software.
Prototype Development
Problem Statement: You are interested in trying out new methods, but adding them to the mainline code is too complex. The new method might be too different compared to existing methods, such that adding it would require too many changes, while, due to the explorative nature of it, the expected gain is unclear. Thus, spending so much effort is not reasonable.
Alternative: You want to create a completely new code for a specific problem or method.
Expected Out-Come: We will provide you a mini app that covers the minimal scope of the current code, i.e. it solves a simplified version of the original problem. This app implements the new method in addition. A qualitative comparison between the existing and new methods is now possible to decide, if the effort to add the new method into the mainline code is worth it. The mini app is build with extensibility in mind, so that in the future new methods can be added again.
Performance Optimization
Problem Statement: The performance of your code is not satisfactory, typically regarding the time spend for running interesting (or larger) cases. You may already have identified the offending pieces, although this is not required.
Expected Out-Come: If not done before, we will identify the critical performance bottlenecks. Those could contain, among others:
- limited use of parallelization; or
- inefficient synchronization in parallel code; or
- inherent overhead of high level programming languages; or
- inefficient IO.
After the identification, the bottlenecks will be removed through, for example:
- increasing parallelization, both within a single node, or across multiple nodes; or
- offloading compute intensive parts to GPUs; or
- implementing more efficient data structures and algorithms; or
- rewriting critical sections in lower level programming language; or
- using efficient libraries.
Problem Statement: Your code works well on CPUs, but it doesn't run on GPUs. Running on CPUs, however, is not enough, since they don't provide the necessary compute or memory throughput (or both) for interesting cases, especially in terms of energy consumption. Additionally, the code can't utilize effectively modern clusters, which are build around accelerators.
Expected Out-Come: We analyze which parts of your code are suitable for porting to GPUs immediately, and which require more work. The suitable code parts are, of course, also ported to GPUs. We will also provide suggestions on how to achieve full GPU utilization if large-scale changes are required.
Problem Statement: Your existing code works reasonably well on a single CPU or GPU. However, a single CPU or GPU provides too little resources for more interesting cases. This could, for example, mean that too little memory is available, or that larger and more complex cases require too much time to solve.
Expected Out-Come: Your code runs on multiple CPUs or GPUs. It performs as well as before on a single CPU or GPU, but now the runtime (or memory requirements) scale inversely with the number of CPUs or GPUs used. This means that cases, which were infeasible to solve before, can now be solved in a reasonable time frame.