Oceananigans.jl
Oceananigans.jl copied to clipboard
CliMA
Friendlier syntax for `KernelFunctionOperation`?
Wondering if it'd be nicer to write
Ri_op = KernelFunctionOperation{Center, Center, Center}(Riᶜᶜᶜ, grid, velocities, tracers.b)
rather than the current syntax
Ri_op = KernelFunctionOperation{Center, Center, Center}(Riᶜᶜᶜ, grid, computed_dependencies=(velocities, tracers.b))
I think we can document the fact that the "dependencies" (really, arguments to the kernel function) are computed. I'm actually not sure if it's so common to nest fields that require computation into a KernelFunctionOperation. It seems like that's maybe an edge case and most of the time we are just using ordinary numbers, fields, etc as "computed dependencies" and in that case it's silly to call them "computed dependencies".
@tomchor you have used this the most, what do you think?
most of the time we are just using ordinary numbers, fields, etc as "computed dependencies" and in that case it's silly to call them "computed dependencies".
My impression is that that's why the parameters argument existed (but please correct me if I'm wrong). In the current way computed_dependencies and parameters clearly indicate what's what (and what happens behind the scenes). So on that note, personally, I like that computed_dependencies keeps things explicit.
Also, I can't say for other people, but I frequently pass fields that require computation to KFO. (Usually passing u-U to calculate fluctuations, etc.)
What if we get rid of parameters and computed_dependencies, and call compute! on all the arguments?
What if we get rid of
parametersandcomputed_dependencies, and callcompute!on all the arguments?
That'd work for me. Would that have the same performance or would it add some overhead?
If it's the same, then I'm okay calling compute on everything and don't separate between parameters and computed_dependencies anymore. I think we gotta make that clear on the docstring though!