Skip to content
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

Supporting non-zero or time-dependent wall-normal velocities #1156

Closed
glwagner opened this issue Nov 9, 2020 · 3 comments
Closed

Supporting non-zero or time-dependent wall-normal velocities #1156

glwagner opened this issue Nov 9, 2020 · 3 comments
Labels
bug 🐞 Even a perfect program still has bugs numerics 🧮 So things don't blow up and boil the lobsters alive

Comments

@glwagner
Copy link
Member

glwagner commented Nov 9, 2020

Wall-normal velocities can depend on model_fields:

@kernel function set_top_bottom_w_velocity!(w, k_boundary, bc, grid, clock, model_fields)
i, j = @index(Global, NTuple)
@inbounds w[i, j, k_boundary] = getbc(bc, i, j, grid, clock, model_fields)
end

and wall-normal velocities are updated after an RK3 substep, but before the pressure solve:

function calculate_pressure_correction!(model, Δt)
fill_halo_regions!(model.velocities, model.architecture, model.clock, fields(model))
solve_for_pressure!(model.pressures.pNHS, model.pressure_solver, model.architecture, model.grid, Δt, model.velocities)

Thus for some problems the wall-normal velocity fields are updated based on the predictor model fields (both the predictor velocity and the updated tracer fields) that result from an RK3 substep.

This devious bug can be avoided simply by not updating wall-normal velocity components on the boundary in the RK3 substep by changing the indexing in the rk3 substep as well as the worksize here:

substep_velocities_kernel! = rk3_substep_velocities!(device(model.architecture), workgroup, worksize)

Then we don't have to fill halo regions before performing the pressure correction. The resulting algorithm is both more correct and computationally less expensive.

Note that doing this could require a bit of gymnastics to get the indexing right in the rk3 substep kernel:

@kernel function rk3_substep_velocities!(U, Δt, γⁿ, ζⁿ, Gⁿ, G⁻)
i, j, k = @index(Global, NTuple)
@inbounds begin
U.u[i, j, k] += Δt * (γⁿ * Gⁿ.u[i, j, k] + ζⁿ * G⁻.u[i, j, k])
U.v[i, j, k] += Δt * (γⁿ * Gⁿ.v[i, j, k] + ζⁿ * G⁻.v[i, j, k])
U.w[i, j, k] += Δt * (γⁿ * Gⁿ.w[i, j, k] + ζⁿ * G⁻.w[i, j, k])
end
end

@glwagner glwagner added bug 🐞 Even a perfect program still has bugs numerics 🧮 So things don't blow up and boil the lobsters alive labels Nov 9, 2020
@glwagner
Copy link
Member Author

glwagner commented Nov 9, 2020

Some context: @kburns and I encountered this issue when trying to use an Ekman pumping boundary condition, which prescribes

w = k * om

at the bottom boundary, where om is the vertical vorticity and k is a constant:

""" Returns the vertical component of vorticity. """
@inline function ζᶠᶠᶜ(i, j, k, grid, u, v)
    ∂x_v = δxᶠᵃᵃ(i, j, k, grid, v) / grid.Δx
    ∂y_u = δyᵃᶠᵃ(i, j, k, grid, u) / grid.Δy
    return ∂x_v - ∂y_u
end

@inline pumping_velocity(ζ, κᵖ) = κᵖ * ζ 

@inline function pumping_velocity(i, j, grid, clock, model_fields, κᵖ) 
    ζʷ = ℑxyᶜᶜᵃ(i, j, 1, grid, ζᶠᶠᶜ, model_fields.u, model_fields.v)
    return pumping_velocity(ζʷ, κᵖ) 
end

pumping_bc = BoundaryCondition(NormalFlow, pumping_velocity, discrete_form=true, parameters=kp)

@glwagner glwagner changed the title Refilling halo regions prior to pressure solve can produce incorrect wall-normal velocities Supporting non-zero or time-dependent wall-normal velocities Mar 2, 2022
@glwagner
Copy link
Member Author

glwagner commented Mar 2, 2022

I changed the name of this issue; the real point here is that we can't support flow through a Bounded direction. If that flow is time-dependent, there are some details we need to fix regarding the pressure solve.

@glwagner
Copy link
Member Author

glwagner commented Mar 22, 2023

This is a hard problem so I'm going to close this since it's not a current priority.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐞 Even a perfect program still has bugs numerics 🧮 So things don't blow up and boil the lobsters alive
Projects
None yet
Development

No branches or pull requests

1 participant