You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -34,7 +34,7 @@ Implemented features include:
34
34
-[Unitful.jl](https://github.com/PainterQubits/Unitful.jl) compatibility so numbers have physical meaning.
35
35
- Set up crystal systems using [SimpleCrystals.jl](https://github.com/ejmeitz/SimpleCrystals.jl).
36
36
- Automatic multithreading.
37
-
- GPU acceleration on CUDA-enabled devices.
37
+
- GPU acceleration on all backends supported by [KernelAbstractions.jl](https://github.com/JuliaGPU/KernelAbstractions.jl), with better performance on CUDA-enabled devices.
38
38
- Run with Float64, Float32 or other float types.
39
39
- Some analysis functions, e.g. RDF.
40
40
- Visualise simulations as animations with [Makie.jl](https://makie.juliaplots.org/stable).
As an important note, Metal/Apple Silicon devices can only run with 32 bit precision, so be sure to use `Float32` (for example) where necessary.
140
149
Simulation setup is similar to above, but with the coordinates, velocities and atoms moved to the GPU.
141
150
This example also shows setting up a simulation to run with `Float32`, which gives much better performance on GPUs.
142
151
Of course, you will need to determine whether this level of numerical accuracy is appropriate in your case.
152
+
Here is an example script for an NVIDIA GPU using CUDA:
143
153
```julia
144
154
using Molly
145
155
using CUDA
@@ -168,6 +178,7 @@ sys = System(
168
178
simulate!(deepcopy(sys), simulator, 20) # Compile function
169
179
simulate!(sys, simulator, 1_000)
170
180
```
181
+
To use another GPU package, just swap out `CUDA` for your desired package and `CuArray` for your desired array type.
171
182
The device to run on can be changed with `device!`, e.g. `device!(1)`.
172
183
The GPU code path is currently designed to be compatible with differentiable simulation and runs slower than related software, but this is an active area of development.
173
184
Nonetheless, GPU performance is significantly better than CPU performance and is good enough for many applications.
@@ -352,7 +363,7 @@ Residue patches, virtual sites, file includes and any force types other than `Ha
352
363
353
364
Some PDB files that read in fine can be found [here](https://github.com/greener-group/GB99dms/tree/main/structures/training/conf_1).
354
365
355
-
To run on the GPU, set `gpu=true`.
366
+
To run on the GPU, set `array_type=GPUArrayType`, where `GPUArrayType` is the array type for your GPU backend (for example `CuArray` for NVIDIA or `ROCArray` for AMD).
356
367
You can use an implicit solvent method by giving the `implicit_solvent` keyword argument to [`System`](@ref).
357
368
The options are `"obc1"`, `"obc2"` and `"gbn2"`, corresponding to the Onufriev-Bashford-Case GBSA model with parameter set I or II and the GB-Neck2 model.
358
369
Other options include overriding the boundary dimensions in the file (`boundary`) and modifying the non-bonded interaction and neighbor list cutoff distances (`dist_cutoff` and `dist_neighbors`).
@@ -1017,10 +1028,10 @@ function Molly.simulate!(sys::ReplicaSystem,
1017
1028
end
1018
1029
```
1019
1030
1020
-
Under the hood there are two implementations for the [`forces`](@ref) function, used by [`accelerations`](@ref), and for [`potential_energy`](@ref): a version geared towards CPUs and parallelism, and a version geared towards GPUs.
1021
-
You can define different versions of a simulator for CPUand GPU systems by dispatching on `System{D, false}` or `System{D, true}` respectively.
1031
+
Under the hood there are multiple implementations for the [`forces`](@ref) function, used by [`accelerations`](@ref), and for [`potential_energy`](@ref): a version geared towards CPUs and parallelism, a CUDA version, and a version for other GPU backends.
1032
+
You can define different versions of a simulator for CPU, CUDA and generic GPU systems by dispatching on `System{D, Array}` or `System{D, CuArray}` and `System{D, AT} where AT <: AbstractGPUArray` respectively.
1022
1033
This also applies to coupling methods, neighbor finders and analysis functions.
1023
-
You do not have to define two versions though: you may only intend to use the simulator one way, or one version may be performant in all cases.
1034
+
You do not have to define different versions though: you may only intend to use the simulator one way, or one version may be performant in all cases.
1024
1035
1025
1036
## Coupling
1026
1037
@@ -1321,7 +1332,7 @@ The available neighbor finders are:
1321
1332
-[`DistanceNeighborFinder`](@ref)
1322
1333
-[`TreeNeighborFinder`](@ref)
1323
1334
1324
-
The recommended neighbor finder is [`CellListMapNeighborFinder`](@ref) on CPUand [`GPUNeighborFinder`](@ref) on GPU.
1335
+
The recommended neighbor finder is [`CellListMapNeighborFinder`](@ref) on CPU, [`GPUNeighborFinder`](@ref) on NVIDIA GPUs and [`DistanceNeighborFinder`](@ref) on other GPUs.
1325
1336
When using a neighbor finder you should in general also use an interaction cutoff (see [Cutoffs](@ref)) with a cutoff distance less than the neighbor finder distance.
1326
1337
The difference between the two should be larger than an atom can move in the time of the `n_steps` defined by the neighbor finder.
1327
1338
The exception is [`GPUNeighborFinder`](@ref), which uses the algorithm from [Eastman and Pande 2010](https://doi.org/10.1002/jcc.21413) to avoid calculating a neighbor list and should have `dist_cutoff` set to the interaction cutoff distance.
0 commit comments