-
Notifications
You must be signed in to change notification settings - Fork 24
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
Output grids #134
Comments
I agree. If the purpose of output is only visualization or casual post-processing, then the option 2) would be most preferable. |
Note to self: Data on an octahedral Clenshaw grid can also (for each of the 4 basepixels) be output like julia> A
7×7 Matrix{Int64}:
0 0 0 0 5 11 18
0 0 0 4 10 17 24
0 0 3 9 16 23 29
0 2 8 15 22 28 0
1 7 14 21 27 0 0
6 13 20 26 0 0 0
12 19 25 0 0 0 0 with the poles being 0s or NaNs or something else indicating missing. The octahedral Gaussian grid would need to double the diagonal though as there's no grid line directly on the equator julia> B
8×7 Matrix{Int64}:
0 0 0 0 5 11 18
0 0 0 4 10 17 25
0 0 3 9 16 24 31
0 2 8 15 23 30 36
1 7 14 22 29 35 0
6 13 21 28 34 0 0
12 20 27 33 0 0 0
19 26 32 0 0 0 0 |
Orography on the octahedral Clenshaw-Curtis grid O512 directly output as matrix (no interpolation), following the idea from above, but rotating every quadrant such that the North Pole sits in the middle
|
Wow, this is amazing! |
With #140 one can now choose between 2 and 3 from above (at least for those grids where things are implemented). Vorticity at T255 output directly on the octahedral clenshaw grid O256 (north pole view) |
@hottad With #140 merged, I just ran a T1023 simulation using the octahedral Clenshaw-Curtis grid O1024 but output is regridded on the fly onto a full Clenshaw-Curtis grid with 4096x2047 grid points (hence reusing the Legendre polynomials, but replanning the FFTs). Do you have a suggestions of how we should compare the grids? Like how would we determine whether HEALPix is better/worse than OctahedralClenshaw? Some idealised simulation and take, say, OctahedralGaussian as a reference? Or some power spectrum analysis? |
Thank you @milankl for the great job. Those figures are mesmerizing! I think the question of "ClenshawGrid better than HEALPix (or vice versa)?" cannot be answered purely by simulation results. That said, comparison with the tried-and-truth Gaussian simulation is very useful to examine at which resolution HEALPix solution becomes reasonable. Spectral transform on HEALPix should become increasingly accurate as the resolution increases, and checking its convergence property by comparison to Gaussian grid is a good idea. Besides comparison to Gaussian grid, we should check if there is any undesirable feature in the solutions, like
Examination of convergence is perhaps best done with idealized test cases (Williamson's tests or Galewsky for shallow-water, and Jablonowski and Williamson for 3D primitive equation, for example). To check the presence of undesirable features, we should use more realistic set up with realistic orography and physics (if already available). Power spectrum analysis is also interesting, but it is very sensitive to factors like choice of hyper diffusion, time step,... so interpretation is rather difficult. If the simulation results are close enough across the grids, we can then decide our preference based on aspects other than accuracy, like computational cost, model behavior with reduced precision arithmetic, ease of data handling, ease of semi-Lagrangian advection implementation, coupling with other component models (ocean, sea-ice, atmospheric composition etc)... |
Given that we have now the flexibility to use various grids, we need to think about how to output gridded data to netcdf. Several issues
So I see several possibilities
FullGaussianGrid
(currently), but that's expensive and considerably slows down the simulationOctahedralGaussianGrid
-FullGaussianGrid
,OctahedralClenshawGrid
-FullClenshawGrid
meaning we would need to define a full version to the HEALPix grid and create aS_output = SpectralTransform(S,output_grid=...)
which changes parameters likenlon
but points to the already precomputed Legendre polynomialsinterpolate!(grid::Grid,lat,lon)
function for everyGrid<:AbstractGrid
, which, however, we may need eventually anyway if we want semi-Lagrangian advection at some pointI don't like 1) what we currently do, hence this issue. I do like 2) and 3) and think that's the simplest to implement. 4) is possible but sounds more like a long-term solution. I reckon it's faster than 2) but not than 3) (which is just memory reordering)
@hottad do you agree?
The text was updated successfully, but these errors were encountered: