Skip to content

Commit

Permalink
Move paragraph
Browse files Browse the repository at this point in the history
  • Loading branch information
shuds13 committed Oct 19, 2023
1 parent 8f353fc commit af43cd8
Showing 1 changed file with 5 additions and 5 deletions.
10 changes: 5 additions & 5 deletions docs/papers/joss/paper.md
Original file line number Diff line number Diff line change
Expand Up @@ -52,11 +52,6 @@ design, decision, and inference studies on or across laptops and heterogeneous h

There are a growing number of packages aimed at workflows, and a sub-set of these focus on running ensembles of calculations on clusters and supercomputers. A dynamic ensemble refers to packages that automatically steer the ensemble based on intermediate results. This may involve deciding simulation parameters based on numerical optimization or machine learning techniques, among other possibilities. Other packages in this space include Colmena and the RADICAL-Ensemble Toolkit.

[***merge sim/gen with this?]
[***where communications?]

LibEnsemble stands out primarily through its generator-simulator paradigm, which eliminates the need for users to explicitly define task dependencies. Instead, it emphasizes data dependencies between customizable Python user functions. This modular design also lends itself to exploiting the large library of example user functions that are provided with libEnsemble, maximizing code re-use. For instance, users can readily choose an existing generator function and tailor a simulator function to their particular needs.

Some crucial considerations relevant to these packages include:

- Portability - running on different machines with different schedulers, hardware, MPI runners with minimal modification to user scripts.
Expand All @@ -69,6 +64,11 @@ Some crucial considerations relevant to these packages include:

- Ability to cancel simulations on on-the-fly.

[***merge sim/gen with this?]
[***where communications?]

LibEnsemble stands out primarily through its generator-simulator paradigm, which eliminates the need for users to explicitly define task dependencies. Instead, it emphasizes data dependencies between customizable Python user functions. This modular design also lends itself to exploiting the large library of example user functions that are provided with libEnsemble, maximizing code re-use. For instance, users can readily choose an existing generator function and tailor a simulator function to their particular needs.

To acheive portability, libEnsemble employs system detection beyond other packages. It detects crucial system information such as scheduler details, MPI runners, core counts, GPU counts (for different types of GPU), and uses these to produce run-lines and GPU settings for these sytems, without the user having to alter scripts. For example, on a system using "srun", libEnsemble will use srun options to assign GPUs, while on other systems it may assign via environment variables such as ROCR_VISIBLE_DEVICES or CUDA_VISIBLE_DEVICES, while the user only states the number of GPUs needed for each simulation. For cases where autodetection is insufficient the user can supply platform information or the name of a known system via scripts or an environment variable.

Check warning on line 72 in docs/papers/joss/paper.md

View workflow job for this annotation

GitHub Actions / Spellcheck release branch

"acheive" should be "achieve".

Check warning on line 72 in docs/papers/joss/paper.md

View workflow job for this annotation

GitHub Actions / Spellcheck release branch

"sytems" should be "systems".

By default, libEnsemble divides available compute resources amongst workers. However, when simulation parameters are created, the number of processes and GPUs can also be specified for each simulation. Combined with the portability features, this makes it very simple to transfer user scripts between platforms.
Expand Down

0 comments on commit af43cd8

Please sign in to comment.