Oceananigans.jl: Better user API for interacting with fields

[glwagner]

We should define functions like

set!(u, a::AbstractArray) = u.data .= a
set!(u::Field{A}, a::AbstractArray) where A <: CuArray = u.data .= CuArray(a)

(for example)

and also

function set!(u, a::Function)
    set!(u, a.(xnodes(u), ynodes(u), znodes(u))
end

(this also requires us to define xnodes, etc to return the correct x-points on which u is defined)

and also

setproperty!(φ, U::FieldSet, a) = set!(φ, a)

which will allow syntax like

softstep(z, d) = 0.5*(tanh(z/d) + 1)
T0(x, y, z) = 20 - 0.01 * z + 0.001 * softstep(z+H/2, H/10) * rand()
model.tracers.T = T0

that works generically on the GPU or CPU... etc.

[glwagner]

We also need to add the array type and grid type as parameters to the abstract type Field.

[ali-ramadhan]

This would make the API much nicer! Would be especially nice to rewrite the examples when this is implemented so users won't have to juggle Arrays and CuArrays.

[glwagner]

Any other ideas / wish list items ?

[glwagner]

This could make it so the user doesn’t even have to import CuArrays!

[vchuravy]

Note that .= between different arrays is copyto! and convert(CuArray, A) tends to be better written as adapt(CuArray, A). The former will lose structure if you have A==Transpose{CuArray}

[ali-ramadhan]

Just some ideas from browsing the examples:

• set!(::Field, ::Number)
• set!(::Field, ::Array or ::Field)
• set!(::Field, ::Function)
• set_slice!(::Field, ::Array, indices
• set_profile!(::Field, ::Number)
• set_profile!(::Field, ::Vector)
• set_profile!(::Field, ::Function)
• set_surface!(::Field, ::Number)
• set_surface!(::Field, ::Matrix)
• set_surface!(::Field, ::Function)
• add_random_perturbations!(::Field, indices, ϵ)

[glwagner]

@ali-ramadhan See the code above. With

xnodes(c::CellField) = reshape(c.grid.xc, c.grid.Nx, 1, 1)
ynodes(c::CellField) = reshape(c.grid.yc, 1, c.grid.Ny, 1)
znodes(c::CellField) = reshape(c.grid.zc, 1, 1, c.grid.Nz)

plus the above abstractions, then we can just do

T0(x, y, z) = 20 - 0.01*Tz*z + rand()
model.tracers.T = T0

Which will generate a 3D field on the appropriate device.

No need for functions like set_profile! --- the above is easy enough in my opinion.

[glwagner]

My code literally works out of the box. I'll copy and paste and make a PR.

[johncmarshall54]

Greg, can we get your 1-d model integrated in to oceananigans? Doesn't
make sense to me to develop a 1-d model separately. So much ought to be and
could be common. Thoughts? John

On Thu, Apr 25, 2019, 11:09 AM Gregory L. Wagner [e-mail]
wrote:

My code literally works out of the box. I'll copy and paste and make a PR.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/climate-machine/Oceananigans.jl/issues/174#issuecomment-486714424,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKXUEQSTKSK54435JPSZCRLPSHCR5ANCNFSM4HE7436Q
.

[glwagner]

@johncmarshall54 that would be nice I agree! But not super easy. I've concentrated on tools in OceanTurb that allow us to quickly develop new models (abstractions for time-stepping, PDEs, macros for declaring the prognostic variables in a PDE, etc).

These tools could be implemented in Oceananigans (I'd love to, in fact) but it's not copy and paste. Not only would they require substantial changes to Oceananigans (more abstraction, decoupling of the time stepper from equation specification, etc), there there will likely be some challenges adapting OceanTurb ideas to the GPU.

We will need to start using Oceananigans.jl eventually to develop parameterizations for the mesoscale problem. For that, we will probably want to use Oceananigans as both our 'data' (high-res model) and as 'model' (low-res model with parameterization). For this effort we will need some of the abstractions developed for OceanTurb to easily change the underlying PDE implemented in Oceananigans.jl and develop/implement new and radical paramterization ideas.. So this process may begin soon, but it will be gradual.

That said, hopefully it can begin in a few months after I have wrapped up the column modeling work and (with everyone's blessing) turned my attention to the mesoscale problem.

It's been nice to keep them separate so far --- I've made a lot of drastic and breaking changes to OceanTurb in my quest to prototype and refine abstraction techniques.

I think the current PR #210 is an example of what we should do with increasing frequency in the next few months --- take ideas that have been developed in OceanTurb (in 1D) and reimplement them in 3D in Oceananigans.

[glwagner]

probably also want

parent(u::Field) = u.data.parent

and

parentdata(u::Field) = # returns a view over interior indices of u.data.parent

[ali-ramadhan]

Seems like this issue has been resolved by PR #343.

@glwagner should we close it?

[glwagner]

Probably. Do we want the setproperty! sugar? Would not be hard to implement. We may also want to add plotting recipes and operators for arithmetic operations between different fields. But maybe we should revisit in a more major PR that overhauls the field abstraction, which I think will be due at some point.

[ali-ramadhan]

setproperty! might be nice for later but I think set!(model; ...) works great for now, and seems to hit everything in your original post.

More major rethinking of the Fields abstraction also has its own issue #298.