-
Notifications
You must be signed in to change notification settings - Fork 191
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
Stabilizing forcing function arguments and boundary condition function arguments #682
Comments
A And yeah if I guess function signatures will become F(i, j, k, grid, time, state, parameters) which is quite nice. This change will break a lot of scripts that define custom forcing functions and boundary conditions so should probably mention this in release notes. |
I was thinking even simpler: F(i, j, k, grid, clock, state) Any 'parameters' that are needed for forcing functions can be introduced by defining a callable object that carries around its parameters. We can introduce something simple like (Now that I think of it, we should probably separate |
Hmmm, I'm not 100% sure how the callable object would work with Do you have some pseudocode about what the setup would look like for users? |
Yes: cool_forcing_function(i, j, k, grid, clock, state, parameters) = # something that uses the parameters argument
cool_forcing = ParameterizedForcing(cool_forcing_function, parameters=(a=1, b=2)) Pretty much the same way that it's used for |
The definition of struct ParameterizedForcing{F, P}
func :: F
parameters :: P
end
(F::ParameterizedForcing)(i, j, k, grid, clock, state) = F.func(i, j, k, grid, clock, state, F.parameters) easy peasy. |
Ah looks awesome then! |
Simple forcing is defined similarly here: https://github.com/climate-machine/Oceananigans.jl/blob/master/src/Forcing/simple_forcing.jl here's the docstring: """
SimpleForcing([location=(Cell, Cell, Cell),] forcing; parameters=nothing)
Construct forcing for a field at `location` using `forcing::Function`, and optionally
with `parameters`. If `parameters=nothing`, `forcing` must have the signature
`forcing(x, y, z, t)`;
otherwise it must have the signature
`forcing(x, y, z, t, parameters)`.
Examples
========
```julia
julia> const a = 2.1
julia> fun_forcing(x, y, z, t) = a * exp(z) * cos(t)
julia> u_forcing = SimpleForcing(fun_forcing)
julia> parameterized_forcing(x, y, z, t, p) = p.μ * exp(z/p.λ) * cos(p.ω*t)
julia> v_forcing = SimpleForcing(parameterized_forcing, parameters=(μ=42, λ=0.1, ω=π)) """
|
Suggestions are definitely welcome for streamlining everything! Note: in dedalus, this problem is handled by allowing users to accumulate parameters into something like Having a "global-like" variable (like |
I am strongly in favor of more localized parameters as it makes the code more modular and we can stop juggling around If users do want a global-like parameters object, they can define one big named tuple and pass it to all the |
I've realized that it doesn't make sense to include either the tendencies or pressures in so we just have This also means that we need a special solution for implementing predictor velocity boundary conditions. |
We currently allow users to implement custom forcing functions with the signature:
F(i, j, k, grid, time, U, C, parameters)
where
U
is a named tuple of velocity fields,C
is a named tuple of tracer fields, andparameters
is the object passed toIncompressibleModel
via theparameters
keyword argument.Boundary condition functions have the signature:
condition(i, j, grid, time, iteration, U, C, parameters)
To stabilize the API, we may want to get rid of
parameters
, includeclock
rather thantime
oriteration
, and add a named tuple container calledstate
that holdsU
,C
, and any other state variables that we want to add (now or in the future) as accessible to forcing functions or boundary condition functions.I'd propose that state be defined something like
If we form
state
within the time-stepping loop, it could also simplify the function signatures for time-stepping kernels.Related is #565.
The text was updated successfully, but these errors were encountered: