More coriolis options

[suyashbire1]

This pull request adds Fplane(omega, lat) and \betaPlane(f_0, \beta) functionality.

What does the T(0.5) term do in the following snippet? Does it translate to Float64(0.5)? In that case, I'm not sure it should be there. I have kept it for now.

@inline fu(i, j, k, grid::RegularCartesianGrid{T}, f, u) where T =
    T(0.5) * f * (avgx_f2c(grid, u, i,  j-1, k) + avgx_f2c(grid, u, i, j, k))

[glwagner]

Looks great! Just some pending questions about docstrings, terminology (β versus Beta, and lat versus latitude), and some @inbounds annotations.

[ali-ramadhan]

Agree with Greg's comments. Otherwise looks good!

Can we also have a BetaPlane(T=Float64; Ω, latitude)?

[ali-ramadhan]

What does the T(0.5) term do in the following snippet? Does it translate to Float64(0.5)?

Yeah exactly, it's there so we don't mix precisions when running with e.g. Float32. That can slow down the code as you have to convert between Float32 and Float64 to do operations.

Could do / 2 which gets converted to the correct float type, but division is more expensive than multiplication and not sure if x / 2 will get optimized to 0.5 * x in all cases.

[codecov]

Codecov Report

Merging #438 into master will increase coverage by 0.37%.
The diff coverage is 76.19%.

@@            Coverage Diff             @@
##           master     #438      +/-   ##
==========================================
+ Coverage   73.46%   73.83%   +0.37%     
==========================================
  Files          27       27              
  Lines        1515     1525      +10     
==========================================
+ Hits         1113     1126      +13     
+ Misses        402      399       -3

Impacted Files	Coverage Δ
src/Oceananigans.jl	62.5% <ø> (ø)	⬆️
src/coriolis.jl	76.19% <76.19%> (+16.19%)	⬆️
src/TurbulenceClosures/closure_operators.jl	68.53% <0%> (+4.09%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 27493f3...88427a6. Read the comment docs.

[glwagner]

Yeah exactly, it's there so we don't mix precisions when running with e.g. Float32. That can slow down the code as you have to convert between Float32 and Float64 to do operations.

Just to expand on what @ali-ramadhan said: in writing numbers, we adopt a mixed approach -- in some cases we use integers and rely on promotion to obtain the correct floating point precision. In other cases, we explicitly impose the precision of a number. For fractions, we typically impose precision. For multiplication by integers, we just use the integer and promotion.

Also, I don't think its actually the floating point conversation that is costly here. Rather I think the added cost is doing the arithmetic at higher precision. Also, due to promotion rules, I think if a single kernel operator outputs the wrong floating point type, we could end up performing much of an entire kernel's computation at the wrong precision. This appears to have a negligible effect on a Tesla V100 --- but it may have more important effects on other machines, especially if we try to run at half precision on machines especially designed for half precision calculations.

[suyashbire1]

BetaPlane(T=Float64; Ω, latitude)

@ali-ramadhan Added this but we also have to specify the radius for this one to work.

[ali-ramadhan]

This PR might be of interest to @masonrogers14

[glwagner]

@suyashbire1 is this ready to be merged? We need this for our work with @masonrogers14. I noticed, however, that some commits for the new NetCDF output writer made their way into this PR. Does that mean we should merge the two PRs together? This is fine with me.

[suyashbire1]

Yes, this one's good to go. I'm sorry I let it marinate for so long. Feel free to make you changes and merge @glwagner .

About the netcdf commits, yeah, I must have created this branch off of the netcdf branch. Yeah, lets merge the two together.

[ali-ramadhan]

Awesome! Just one minor comment but otherwise looks good to merge.

[ali-ramadhan]

Ah sorry merging PR #496 introduced a tiny merge conflict, just fixed it.