-
Notifications
You must be signed in to change notification settings - Fork 195
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
Field
major refactor: one Field
to rule them all
#2121
Conversation
This sounds like a great idea, and a big step forward. One question: Considering that we use |
Well, we distinguish between topologies ( Are you suggesting that we introduce a new location called |
No, sorry, my silly mistake. |
It still might make sense to come up with a better location than |
How about |
Field
to rule them all [WIP]Field
major refactor: one Field
to rule them all [WIP]
Field
major refactor: one Field
to rule them all [WIP]Field
major refactor: one Field
to rule them all
…ananigans.jl into glw/one-field-rule-all
This PR resolves #2052 by consolidating
Field
to encompass:Field
ComputedField
ReducedField
AveragedField
In addition, it gets rid of
KernelComputedField
since that functionality is now covered byKernelComputedOperation
+Field
.Field
will no longer explicitly keep track ofarchitecture
, becausearchitecture
belongs togrid
now.This PR also change the API for constructing fields:
There are also convenience constructors that take a tuple of locations:
AveragedField
functionality is now wrapped intoField
. Rather than writingc_sq_avg = AveragedField(c^2, dims=(1, 2))
, we now writeThere is also an interface for generic reductions, so another possibility is
It was already possible to compute
maximum!
with aReducedField
and anAbstractField
; this interface simply provides a way to compute these things on the fly for diagnostics purposes while running simulations.In summary, this PR is meant to reduce the amount of code we have to maintain, significantly declutter our
Field
implementations, clean up the API, and hopefully make it easier to extendField
implementations in the future, especially regarding reductions of operations such asSummedField
,SlicedField
, etc.