Fix spelling and grammar

docs/papers/joss/paper.md

@@ -50,52 +50,52 @@ design, decision, and inference studies on or across laptops and heterogeneous h
 
 # Statement of need
 
-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 [@colmena21] and the RADICAL-Ensemble Toolkit [@ensembletoolkit16], and also packages that provide back-end dispatch and execution such as Parsl [@parsl] and Balsam [@Salim2019].
+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 [@colmena21] and the RADICAL-Ensemble Toolkit [@ensembletoolkit16] and also packages that provide back-end dispatch and execution such as Parsl [@parsl] and Balsam [@Salim2019].
 
 Some crucial considerations relevant to these packages include:
 
-- Ease of use - does the software require a complex setup.
+- Ease of use - whether the software requires a complex setup.
 
 - Portability - running on different machines with different schedulers, hardware, MPI runners with minimal modification to user scripts.
 
 - Scalability - working efficiently with large simulations and many concurrent simulations.
 
-- Interoperability - the modularity of the package and the abilitiy to interoperate with other packages.
+- Interoperability - the modularity of the package and the ability to interoperate with other packages.
 
-- Dynamic resources - ability to dyanmically assign machine resources to simulations.
+- Dynamic resources - the ability to dynamically assign machine resources to simulations.
 
-- Ability to cancel simulations on on-the-fly.
+- Ability to cancel simulations 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.
+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 reuse. For instance, users can readily choose an existing generator function and tailor a simulator function to their particular needs.
 
-libEnsemble is a complete toolkit that includes generator in-the-loop and backend mechanisms. Some other packages cover a sub-set of the workflow. Colmena, for example, has a front-end that uses components to create and co-ordinate tasks while using Parsl to dispatch simulations.
+libEnsemble is a complete toolkit that includes generator in-the-loop and backend mechanisms. Some other packages cover a sub-set of the workflow. Colmena, for example, has a front-end that uses components to create and coordinate tasks while using Parsl to dispatch simulations.
 
-libensemble takes the philosohpy of minimising required dependencies, while supporting various back-end mechanisms when needed. For example, the vast majority of users do not require to be running a database application or special run-time to use libEnsemble, but for those that do, Balsam can be used on the back-end by substituting the reguler MPI executor for the Balsam executor. This approach simplifies the user experience and reduces the initial setup and adoption costs when using libEnsemble.
+libEnsemble takes the philosophy of minimizing required dependencies while supporting various back-end mechanisms when needed. For example, the vast majority of users do not require to be running a database application or special run-time to use libEnsemble, but for those that do, Balsam can be used on the back-end by substituting the regular MPI executor for the Balsam executor. This approach simplifies the user experience and reduces the initial setup and adoption costs when using libEnsemble.
 
-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.
+To achieve 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 systems, 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.
 
 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.
 
-The close coupling between the libEnsemble generator and simulators enables the generator to perform tasks such as asynchronously receiving results, updating models, and cancelling previously initiated simulations. Simulations that are already running can be terminated and resources recovered. This is more flexible compared to other packages, where the generation of simulations is external to the dispatch of a batch of simulations.
+The close coupling between the libEnsemble generator and simulators enables the generator to perform tasks such as asynchronously receiving results, updating models, and canceling previously initiated simulations. Simulations that are already running can be terminated and resources recovered. This is more flexible compared to other packages, where the generation of simulations is external to the dispatch of a batch of simulations.
 
-libEnsemble supports persistent user functions.that run on workers, maintaining their memory, which prevents the storing and reloading of data required by packages that only support a fire-and-forget approach to ensemble components.
+libEnsemble supports persistent user functions that run on workers, maintaining their memory, which prevents the storing and reloading of data required by packages that only support a fire-and-forget approach to ensemble components.
 
-Examples of way in which libEnsemble has been used in science and engineering problems include:
+Examples of ways in which libEnsemble has been used in science and engineering problems include:
 
 - Optimization of variational algorithms on quantum computers [@Liu2022layer].
 - Parallelization of the ParMOO solver for multiobjective simulation optimization problems [@ParMOODesign23].
 - Design of particle accelerators [@Neveu2023] [@PhysRevAccelBeams.26.084601] [@Pousa22].
 - Sequential Bayesian experimental design [@Surer2023] and Bayesian calibration [@MCMPSW2022].
 
-libEnsemble's generators and simulators, commonly referred to as user-functions, are Python
+libEnsemble's generators and simulators, commonly referred to as user functions, are Python
 functions that simply accept and return NumPy structured arrays. Generators produce input for
-simulators, while simulators evaluate those inputs; any level of complexity is supported. 
-Multiple concurrent instances ("ensembles") of user-functions are coordinated by libEnsemble's
-worker processes. Workers are typically assigned/reassigned compute resources, and within 
-user-functions can launch applications, evaluate intermediate results, and statefully intercommunicate.
+simulators, while simulators evaluate those inputs; any level of complexity is supported.
+Multiple concurrent instances ("ensembles") of user functions are coordinated by libEnsemble's
+worker processes. Workers are typically assigned/reassigned compute resources, and within
+user functions can launch applications, evaluate intermediate results, and statefully intercommunicate.
 
 Additional details on the parallel features and scalability of libEnsemble can be found in Refs [@Hudson2022] and [@libensemble-man].