-
Notifications
You must be signed in to change notification settings - Fork 186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Making all examples GPU-compatible #1863
Comments
I'm not sure whether that is a correct assumption or not. Some of them were designed to be used on the GPU: Oceananigans.jl/examples/ocean_wind_mixing_and_convection.jl Lines 157 to 158 in 6e39d3f
But I don't think anyone has ever tried to run the Kelvin-Helmholtz example on the GPU before (for example). Many of the others have been run on the GPU. But I think to really ensure this is the case in the long run we'll have to use CI. We actually used to do something like this (including altering selected lines in the test scripts to make them more amenable to CI) so someone could dredge up that testing code to use with our GPU CI to solve this. |
I think modifying the examples to run on GPUs easily is a good idea. After putting together the |
One thing that I was also thinking about is that defining (global) problem
parameters as constants might help out regardless. Every time I do that for
my scripts it speeds up compilation times and often also significantly
speeds up runtimes. Therefore there might be a benefit to using `const`
throughout, even without GPUs.
The downside to that is that if a user tries to run several examples in the
same REPL session they might be, without their knowing, trying to redefine
some constants and get some errors and warnings related to that.
…On Fri, Jul 16, 2021 at 8:05 AM Francis J. Poulin ***@***.***> wrote:
I think modifying the examples to run on GPUs easily is a good idea. After
putting together the ShallowWaterModel example I tried it on a GPU and
found out that it failed. I added a bunch of const and it then worked
easily enough. This would make it easier for the user to play with the two
architectures, which would be a big plus.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1863 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADEX5KUFT35UOWJSRKU2M5TTYBDCBANCNFSM5AOQEC5A>
.
--
Tomás L. Chor
Postdoctoral researcher
Atmospheric and Oceanic Science department
University of Maryland
https://tomchor.github.io/
|
In the examples I have developed I have tried to always declare variables that are referenced globally in forcing functions or boundary conditions as |
I see some stuff like P.S.: I'm not super clear on which cases defining things as a const helps or not. I just know that the general rule is use something as a |
I think if you want to run examples on GPUs you need to use I would suggest making a PR as the more versitile the examples are the better they could be helpful to the users. |
const a = 2
f(x) = a * x
When numbers are added to explicit data structures --- which is what happens when they are inserted into the |
We certainly should not use |
Also to be clear, declaring something as julia> mutable struct Test{T}
a :: T
end
julia> const b = 2
2
julia> t = Test(b)
Test{Int64}(2)
julia> t.a = 3
3
julia> t
Test{Int64}(3) |
Another non-function example is this piece of code from the wind mixing case: Qᵀ = Qʰ / (ρₒ * cᴾ) # K m s⁻¹, surface temperature flux
# Finally, we impose a temperature gradient `dTdz` both initially and at the
# bottom of the domain, culminating in the boundary conditions on temperature,
dTdz = 0.01 # K m⁻¹
T_bcs = FieldBoundaryConditions(top = FluxBoundaryCondition(Qᵀ),
bottom = GradientBoundaryCondition(dTdz)) This should work on the GPU. The reason is that @inline Qˢ(x, y, t, S, evaporation_rate) = - evaporation_rate * S # [salinity unit] m s⁻¹
nothing # hide
# where `S` is salinity. We use an evporation rate of 1 millimeter per hour,
evaporation_rate = 1e-3 / hour # m s⁻¹
# We build the `Flux` evaporation `BoundaryCondition` with the function `Qˢ`,
# indicating that `Qˢ` depends on salinity `S` and passing
# the parameter `evaporation_rate`,
evaporation_bc = FluxBoundaryCondition(Qˢ, field_dependencies=:S, parameters=evaporation_rate) because |
Here's the julia docs on constants for reference: https://docs.julialang.org/en/v1/manual/variables-and-scoping/#Constants This statement in the julia docs could maybe be clarified:
because its ambiguous what "code involving global variables" is. For Oceananigans, this almost always means "functions that capture global variables in their scope". So |
I tried running the @glwagner , I remember we talked about this but, sadly, I don't know if we had a solution. What would you recommend?
|
It looks like
|
Happy to help if you point me to where |
The linke is here but the function is copied below
|
I think you just need to use We define Oceananigans.jl/src/Fields/abstract_field.jl Lines 281 to 282 in 798b1ef
Though it's untested (but probably works, at least right now...) |
I am happy to try that. I have been using |
It looks like we need |
julia> import Statistics
julia> import LinearAlgebra
julia> Statistics.norm === LinearAlgebra.norm
true |
Ah, good to know. Thanks! PR has been created. |
I'm closing this issue because I'm judging that it's not of current, timely relevance to Oceananigans development. If you would like to make it a higher priority or if you think the issue was closed in error please feel free to re-open. |
@glwagner I am trying to run the Kelvin-Helmholtz instability example on a GPU; however, the model has failed, throwing some errors. Can someone help me to sort this error. Please find the attached error below: using Random, Statistics mean_perturbation_kinetic_energy = Field(Average(1/2 * (u^2 + w^2))) @info "Power iterations converged! Estimated growth rate: $(growth_rates[end])" Error: Scalar indexing is disallowed. If you want to allow scalar iteration, use |
I haven't had the chance to try all the examples in the docs on GPUs, but am I correct to assume that some of them won't compile on GPUs?
If that's the case, should make an effort to make all of those examples GPU-compatible?
The text was updated successfully, but these errors were encountered: