Merge pull request #7 from RuiApostolo/gh-pages

Small changes to lessons and exercises

_episodes/02-lammps-on-archer2.md

@@ -245,8 +245,8 @@ In your `sub.slurm` file, you can edit the number of tasks in the line:
 ```bash
 #SBATCH --tasks-per-node=64
 ```
-to run on more cores.
-An ARCHER2 node has 128 cores, so you could potential run on up to 128 cores.
+to run on a different number of cores.
+An ARCHER2 node has 128 cores, so you can run LAMMPS on up to 128 cores.
 
 
 > ## Quick benchmark
@@ -278,7 +278,7 @@ An ARCHER2 node has 128 cores, so you could potential run on up to 128 cores.
 
 > ## Note
 > Here we are only considering MPI parallelisation.
-> LAMMPS offers the option to run using joint MPI+OpenMP (more on that on the advanced course),
+> LAMMPS offers the option to run using joint MPI+OpenMP (more on that on the advanced LAMMPS course),
 > but for the exercises in this lesson, we will only be considering MPI.
 {: .callout}
 

_episodes/04-understanding-logfile.md

@@ -123,6 +123,39 @@ Each category shows a breakdown of the least, average, and most amount of wall t
 >   - `Comm`: as little as possible. If it's growing large, it's a clear sign that too many computational resources are being assigned to a simulation.
 {: .callout}
 
+The next session is about the distribution of work amongs the different threads:
+
+```
+Nlocal:         7.8125 ave          12 max           5 min
+Histogram: 6 21 22 0 37 29 0 11 1 1
+Nghost:        755.055 ave         770 max         737 min
+Histogram: 2 6 4 18 23 20 30 13 7 5
+Neighs:        711.773 ave        1218 max         392 min
+Histogram: 8 14 24 15 31 22 11 1 0 2
+```
+
+The three subsections all have the same format: a title followed by average, maximum, and minimum number of particles per processor,
+followed by a 10-bin histogram of showing the distribution.
+The total number of histogram counts is equal to the number of processors used.
+The three properties listed are:
+ - `Nlocal`: number of owned atoms;
+ - `Nghost`: number of ghost atoms;
+ - `Neighs`: pairwise neighbours.
+
+
+The final section shows aggregate statistics accross all processors for pairwise neighbours:
+
+```
+Total # of neighbors = 91107
+Ave neighs/atom = 91.107
+Neighbor list builds = 4999
+Dangerous builds = 4996
+```
+
+It includes the number of total neighbours, the average number of neighbours per atom, the number of neighbour list rebuilds, and the number of _potentially dangerous_ rebuilds.
+The _potentially dangerous_ rebuilds are ones that are triggered on the first timestep that is checked.
+If this number is not zero, you should consider reducing the delay factor on the `neigh_modify` command.
+
 The last line on every LAMMPS simulation will be the total wall time for the entire input script, no matter how many `run` commands it has:
 
 ```

_episodes/05-advanced-inputs.md

@@ -71,6 +71,42 @@ The lines with `ITEM:` let you know what is output on the next lines
 (so `ITEM: TIMESTEP` lets you know that the next line will tell you the time-step for this frame -- in this case, 100,000).
 A LAMMPS trajectory file will usually contain the time-step, number of atoms, and information on box bounds before outputting the information we'd requested.
 
+### Restart files
+
+To allow the continuation of the simulation (with the caveat that it must continue to run in the same number of cores as was originally used), we can create a restart file.
+
+This binary file contains information about system topology, force-fields, but not about computes, fixes, etc, these need to be re-defined in a new input file.
+
+You can write a restart file with the command:
+
+```
+write_restart  restart2.lj.equil
+```
+
+An arguably better solution is to write a data file, which not only is a text file,
+but can then be used without restrictions in a different hardware configuration, or even LAMMPS version.
+
+```
+write_data  lj.equil.data
+```
+
+You can use a restart or data file to start/restart a simulation by using a `read` command.
+For example:
+
+```bash
+read_restart restart2.lj.equil
+```
+
+will read in our restart file and use that final point as the starting point of our new simulation.
+
+Similarly:
+
+```bash
+read_data lj.equil.data
+```
+
+will do the same with the data file we've output (or any other data file).
+
 ### Radial distribution functions (RDFs)
 
 First, we will look at the Radial Distribution Function (RDF), _g_(_r_).
@@ -242,42 +278,6 @@ Then, we can plot the final output MSD using e.g. `gnuplot`:
 {: .challenge}
 
 
-### Restart files
-
-To allow the continuation of the simulation (with the caveat that it must continue to run in the same number of cores as was originally used), we can create a restart file.
-
-This binary file contains information about system topology, force-fields, but not about computes, fixes, etc, these need to be re-defined in a new input file.
-
-You can write a restart file with the command:
-
-```
-write_restart  restart2.lj.equil
-```
-
-An arguably better solution is to write a data file, which not only is a text file,
-but can then be used without restrictions in a different hardware configuration, or even LAMMPS version.
-
-```
-write_data  lj.equil.data
-```
-
-You can use a restart or data file to start/restart a simulation by using a `read` command.
-For example:
-
-```bash
-read_restart restart2.lj.equil
-```
-
-will read in our restart file and use that final point as the starting point of our new simulation.
-
-Similarly:
-
-```bash
-read_data lj.equil.data
-```
-
-will do the same with the data file we've output (or any other data file).
-
 ## Variables and loops
 
 LAMMPS input scripts can be quite complex, and it can be useful to run the same script many times with only a small difference (for example, temperature).

_episodes/06-extra-software.md → _episodes/06-gpu-and-extra-software.md

@@ -1,13 +1,16 @@
 ---
-title: "Additional software"
+title: "GPU Acceleration and Additional software"
 teaching: 30
 exercises: 0
 questions:
+- "How can I make my simulations faster using GPUs?"
 - "What other software can I use to prepare input files, and topology files?"
 - "How can I post-process my data?"
 objectives:
+- "Learning how to run LAMMPS simulations using GPU accelarators."
 - "Understand how to enhance the workflow around LAMMPS simulations."
 keypoints:
+- "LAMMPS has two packages (GPU and KOKKOS) that can make simulations run faster using accelerator cards."
 - "Packmol can be used to pack multiple of the same type of molecules into one topology file."
 - "MDAnalisys is a powerful python library to read, process, and create LAMMPS files."
 ---

exercises/3-advanced-inputs-exercise/in.lj_exercise

@@ -83,11 +83,10 @@ thermo        500
 dump          1 all custom 100 nvt.lammpstrj id type x y z vx vy vz
 dump_modify   1 sort id
 
-#compute       RDF all rdf 150 cutoff 3.5
-#fix           RDF_OUTPUT all ave/time 50 950 50000 c_RDF[*] file rdf_lj_${DENSITY}.out mode vector
-#
-#compute       MSD all msd
-#fix           MSD_OUTPUT all ave/correlate 1 50000 50000 c_MSD[4] file msd_lj.out ave running
+compute       RDF all rdf 150 cutoff 3.5
+fix           RDF_OUTPUT all      ave/time 50     950      50000 c_RDF[*] file    rdf_lj_${DENSITY}.out mode    vector
+#fix          ID         group-ID ave/time Nevery Nrepeate Nfreq value1   keyword arg                   keyword arg
+
 
 run_style     verlet
 

exercises/3-advanced-inputs-exercise/in.lj_rerun

@@ -81,6 +81,6 @@ thermo_style  custom step temp etotal pe ke press vol density
 thermo        500
 
 compute       RDF all rdf 150 cutoff 3.5
-fix           RDF_OUTPUT all ave/time 100 500 50000 c_RDF[*] file rdf_lj.out mode vector
+fix           RDF_OUTPUT all ave/time 100 500 50000 c_RDF[*] file rdf_lj_rerun.out mode vector
 
 rerun         nvt.lammpstrj dump x y z vx vy vz