Since having complex diagnostics on GPUs is a big part of this package's scope, it'd be good to address this here.
Personally, in my simulations, diagnostics like RichardsonNumber don't compile when trying to do a reduction if the grid is an ImmersedBoundaryGrid and if there are background fields:
but that might be wasteful in terms of memory since we don't always need to create a whole new field (e.g. if we're just trying to calculate a slice). Ideally we'd find a solution that's conservative in that sense.
I wonder if passing the background fields to the kernel would decrease the parameter space used.
Based on https://github.com/CliMA/Oceananigans.jl/issues/3140, there seems to be non-trivial upper limit to the complexity of the abstract operations we can return that can be compiled on a GPU.
Since having complex diagnostics on GPUs is a big part of this package's scope, it'd be good to address this here.
Personally, in my simulations, diagnostics like
RichardsonNumberdon't compile when trying to do a reduction if the grid is anImmersedBoundaryGridand if there are background fields:https://github.com/tomchor/Oceanostics.jl/blob/33bc1dac1f05b7ba69efc1c9917914e6fd33861c/src/FlowDiagnostics.jl#L67-L87
One obvious solution would be to add an option to return the
u,v,w,b, plus their respective background fields asFields. That is, something likebut that might be wasteful in terms of memory since we don't always need to create a whole new field (e.g. if we're just trying to calculate a slice). Ideally we'd find a solution that's conservative in that sense.
I wonder if passing the background fields to the kernel would decrease the parameter space used.
CC @simone-silvestri @glwagner