Skip to content
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

Development of a "Field" abstraction for solutions in 1, 2, and 3 dimensions #129

Open
glwagner opened this issue Oct 23, 2019 · 1 comment

Comments

@glwagner
Copy link
Member

glwagner commented Oct 23, 2019

It'd be nice to have a (lightweight) abstraction for a "Field" in FourierFlows. The FourierFlows field could store either data in physical/grid space, or data in transform/coefficient space, or both (we should decide on semantics as well).

Type information can also be used to indicate whether the coefficient-space data is in "conjugate symmetric" form (currently we hack a fragile query into functions like parsevalsum that attempts to diagnose this fact from the size of the array with an if-statement, rather than using multiple dispatch on types).

Syntax could get a little nicer because we can define a function compute_grid_space!(field) and compute_coefficient_space!(field) functions that do fourier transforms (rather than requiring users / external packages like GeophysicalFlows to manually write FFTs).

Food for thought.

@navidcy
Copy link
Member

navidcy commented Dec 23, 2019

I like this; will try to do it.

In MultilayerQG module in GeophysicalFlows.jl we have something towards that direction...
https://github.com/FourierFlows/GeophysicalFlows.jl/blob/b15419e4fe093666c0b72cf1191328e631c5ed20/src/multilayerqg.jl#L258-L259
But what you suggest is better.

Will field though always carry along both physical space and Fourier space values?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants