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.

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.

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.

 

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.