Closed glwagner closed 2 days ago
A few other things:
ECCORestoring
should use the rate
of restoring as input, not timescale. This brings it inline with how Oceanangians.Forcing.Relaxation
is used --- we want to minimize the cognitive dissonance between Oceananigans and ClimaOcean.
struct Relaxation{R, M, T}
rate :: R
mask :: M
target :: T
end
I also think the property names can be improved. Probably data
instead of ecco_fts
and grid
instead of ecco_grid
.
Note that variable_name
isn't even a name, its a type:
This is also rather surprising to read:
until you realize that getindex
has been extended... but it's not an expected or usual pattern for getindex...
Also what is the purpose of oceananigans_fieldname
:
@simone-silvestri
I guess in Oceananigans we decided to call this kind of thing Relaxation
. If we prefer Restoring
I think that's ok... we should change it in Oceananigans too though.
Also what is the purpose of
oceananigans_fieldname
:@simone-silvestri
The purpose of having a type is that symbols and strings are not isbits so they cannot be passed to the GPU. Originally, I thought of having indices that specify the field that we need to retrieve, but that requires us to assume the position of model fields, so I think a new type with the variable name is cleaner.
Right! But should we have users invoke the types directly? Generally its nice for the user interface to be as close as possible to the source code. It could get out of hand if there are lots of fields in the future. Also if you need to do something like convert units, it's useful to use Temperature(Kelvin())
which is not possible when using :temperature
Right now,
ECCORestoring
is abstract as the forcing "function", which must then be further wrapped inForcing
byECCO_restoring_forcing
:https://github.com/CliMA/ClimaOcean.jl/blob/b3b44b709c70b296adb63cf7b2f4552334dcfd1b/src/DataWrangling/ecco_restoring.jl#L276-L279
There's no barrier to using
ECCORestoring
directly as a forcing though, provided the appropriate functionality within Oceananigans is extended correctly. And this would be much better, not just for syntax but also because the implementation will be less complicated and easier to understand.