Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Available Potential Energy #1297

Closed
francispoulin opened this issue Jan 8, 2021 · 33 comments
Closed

Available Potential Energy #1297

francispoulin opened this issue Jan 8, 2021 · 33 comments

Comments

@francispoulin
Copy link
Collaborator

Do we want to be able to compute Available Potential Energy (APE) to get an idea as to the energtics of a flow?

@ali-ramadhan
Copy link
Member

Just pasting this definition (approximation?) of APE from Vallis' textbook (2nd edition):

image

Should be possible to compute/diagnose with a KernelComputedField (#1293).

Also found this paper on oceanic convective available potential energy (CAPE) but it looks pretty complicated and not sure if it's immediately useful: https://doi.org/10.1175/JPO-D-14-0155.1

cc @sandreza since APE might be a useful diagnostic for your mesoscale simulations?

@jklymak
Copy link
Contributor

jklymak commented Jan 9, 2021

There was a recent JPO paper on APE, I want to say by Timor Radko, but not 100% sure

@navidcy
Copy link
Collaborator

navidcy commented Jan 10, 2021

The definition in Winters et al 2006 is very different (at least at first glance)
https://doi.org/10.1017/S002211209500125X

@francispoulin
Copy link
Collaborator Author

Thanks @jklymak .

I looked at this paper and the APE for the incompressible Boussinesq model is defined explicitly in section 2.4. The APE is defined in equation 3.6 as

APE     =     \int_V E_a dV 
        =     \int_V \rho g (z - z_R) dV,                                                               (1)

where E_a is the APE density. This is exact and to compute this one needs to find the reference depth, z_R, which is I presume where the sorting comes in.

Then, it says that one can show that the APE density can be written as

E_a       =     - \int_0^\zeta g \tilde \zeta \rho_R' (z - \tilde \zeta) d \tilde \zeta               (2)
   
E_a   \approx   \rho_0 N_r^2 \zeta^2/2                                                                (3)

where N_R^2 = - g/\rho_0 \rho_R' is the Brunt-Vaisala frequency based on the reference density.

Equations (1) and (2) are exact and (3) is approximate, but I believe (3) is exact in the case of constant stratifiation.

I wonder whether using equation (1) is the simplest?

(If anyone can tell me how to make equations in markdown I am happy to change this to make it prettier.)

@glwagner
Copy link
Member

I think it's probably a good idea to (cautiously) add diagnostics that are important yet difficult to write, such as this one. Note that this would be the first!

As a historical note, we have resisted adding diagnostics to the code base so far because we believed that a more generic solution would make it "easy" for users to define their own diagnostics (eg, as simple as writing the mathematical expression), and because long lists of diagnostics impose a maintenance burden.

But I think there are some examples (such as APE) for which we probably can't define simply via abstractions like those provided by AbstractOperations. And as the code becomes more stable (and we have more contributors), maintaining a list of difficult-to-code but commonly-used diagnostics is more feasible.

@francispoulin
Copy link
Collaborator Author

I agree that most diagnostics like total tracer and total kinetic energy are pretty easy to compute and if it is a one liner, then we probably don't need to do anything special.

Computing the APE could be a oneliner as well, after we compute the reference depth and density. So maybe that's something we could add somewhere?

I have not done this before but I know it's pretty standard. I presume the MITgcm does and we could maybe borrow from their weather of knowledge?

@jklymak
Copy link
Contributor

jklymak commented Jan 12, 2021

I'm not aware of an APE calculation in the MITgcm. Its actually pretty rare because it is quite expensive - you need to do a global sort on the density field!

@francispoulin
Copy link
Collaborator Author

Ah, thanks @jklymak for pointing that out.

Kevin Lamb has a paper that uses a slightly different way of computing APE that looks like

APE = \int_V (\rho - \bar \rho_L) g z dV

where \rho_L is the adiabatically arranged density field.

His paper also has some links to other works that do sorting to compute \rho_L.

@tomchor
Copy link
Collaborator

tomchor commented Jan 12, 2021

As a historical note, we have resisted adding diagnostics to the code base so far because we believed that a more generic solution would make it "easy" for users to define their own diagnostics (eg, as simple as writing the mathematical expression), and because long lists of diagnostics impose a maintenance burden.

I agree that some diagnostics would be important, but I also agree with the above philosophy of Oceananigans.

In cases like this wouldn't it be good to consider adding a companion repo to oceananigas that has all these diagnostics rather than putting them in Oceananigans by default? Much like LESbrary.jl does, it would be someting that (hopefully) can use KernelComputedFields, but it wouldn't be dedicated only to LES (so I guess it can't be LESbrary.jl).

@navidcy
Copy link
Collaborator

navidcy commented Jan 13, 2021 via email

@francispoulin
Copy link
Collaborator Author

From what I understand, we need to go through the entire domain and find out how much volume (or area in 2D) of each density we have. Then find the basic state where we have the different densities layed out flat, with the heaviest on the bottom. It sounds like the hard part is looking through the density profile to see how much of each density we have.

I have read, and believe, that it gets more complicated if you have geostrophic balance, which we typically would, but starting off with a 2D non-rotating example would be a reasonable first step. Is this what other people understand?

During non-covid times, I could walk down two doors and ask Kevin Lamb for help on how to do this. Even though I can't ask him in person I can email him questions, when they arise.

@glwagner
Copy link
Member

In cases like this wouldn't it be good to consider adding a companion repo to oceananigas that has all these diagnostics rather than putting them in Oceananigans by default? Much like LESbrary.jl does, it would be someting that (hopefully) can use KernelComputedFields, but it wouldn't be dedicated only to LES (so I guess it can't be LESbrary.jl).

I think this is a nice approach. I think it could also encourage more community contributions.

@jklymak
Copy link
Contributor

jklymak commented Jan 13, 2021

I have read, and believe, that it gets more complicated if you have geostrophic balance, which we typically would, but starting off with a 2D non-rotating example would be a reasonable first step. Is this what other people understand?

I think APE can still be unambiguously defined, even in the case of a geostrophic balance. If you want to decompose your flows in various ways to identify energy reservoirs associated with different classes of motion, that is even more specialized. I'm sure you can do it, but I expect the global sort is still necessary.

This all said, I think a reasonable approximation could be made to calculate the APE on a much coarser timestep to the full physics of the model. If you put such an expensive piece of code in, you would probably want a knob to twiddle to allow it to be coarsened, and then some tuning would be necessary.

@francispoulin
Copy link
Collaborator Author

I agree with you @jklymak , you can certainly compute APE in a rotating fluid, which will require a global sort. I wonder if the issue is how to pick the angle of the pycnoclines in the state of least potential energy? I am sure there are ways of doing these, and we can learn how when needed.

It would be good to give the user an option as to whether they want to compute it and how often. Given what is set up in the time stepping wizard, I don't imagine this will be a concern, and would be nice to give the user the power to control this.

@glwagner
Copy link
Member

This all said, I think a reasonable approximation could be made to calculate the APE on a much coarser timestep to the full physics of the model. If you put such an expensive piece of code in, you would probably want a knob to twiddle to allow it to be coarsened, and then some tuning would be necessary.

Not sure I understand the comment but I believe what's being recommended is currently a feature of Oceananigans. Output / diagnostics can be "scheduled" in various ways, either on time intervals, iteration intervals, wall time intervals, or custom criteria designed by the user.

@tomchor
Copy link
Collaborator

tomchor commented Jan 28, 2021

I'm sure you can do it, but I expect the global sort is still necessary.

Every source that I've read so far that mentions how to compute it says sorting needs to be done. Everything else seems to be an approximation. The hard part is, of course, to compute the "unavailable potential energy", which is the minimum PE of the system. The canonical way to do it apparently is to flatten the array, sort it, and then put it back into the original shape. In Python this can be easily done with (using b instead of ρ)

PE_min = np.sort(b.data.flatten()).reshape(*b.shape)

(disclaimer: I haven't tested if the result is exactly correct, but it should be along those lines.)

I will have to program this diagnostic very soon and I'm thinking of doing it using KernelComputedFields (and then putting it up on a repo). My question is: what's the sorting/reshaping method that works for GPUs?

@francispoulin
Copy link
Collaborator Author

Great to know that python can do this in one line! Maybe it will turn out to be as simple in Julia for both CPUs and GPUs.

@ali-ramadhan
Copy link
Member

Reshaping a CuArray should work just like reshaping a regular Array but sorting on GPUs is pretty non-trivial since it has to be made parallel across thousands of little threads.

Looks like CUDA.jl has a quicksort implementation as of 9 days ago though! JuliaGPU/CUDA.jl#431

@francispoulin
Copy link
Collaborator Author

Luckily we are not having this discussion two weeks ago!

@glwagner
Copy link
Member

@tomchor if KernelComputedField doesn't work (I suspect it won't, since this problem may require more than one kernel), remember that you can also define your own field that subtypes AbstractField and defines an appropriate compute! method.

@hdrake
Copy link
Contributor

hdrake commented May 11, 2021

Great to know that python can do this in one line! Maybe it will turn out to be as simple in Julia for both CPUs and GPUs.

Just wanted to point out that APE calculations are only this simple with simple for Cartesian grids with a flat bottom and a linear equation of state. Otherwise, the hard part is actually finding the depths/pressure associated with the sorted profile density profile (see Huang 2005). I've been working on implementing this in an MITgcm simulation with a linear equation of state but complicated topography, and it has been a mess (and very slow).

@francispoulin
Copy link
Collaborator Author

Thanks @hdrake for sharing both the reference and your insights. I guess Oceananigans does not have topography yet but it would be nice to dl thi sfor different equations of state and stratifications.

Please let us know how it goes an dmaybe when you have something you can share we can try and do something similar here?

@glwagner
Copy link
Member

@hdrake can you clarify specifically what is difficult about the calculation? If we know the specific calculations we need to make we might be able to support / facilitate them with abstractions.

For example, it may be possible to sort abstract operations --- like the product of a field and a grid metric like cell area or volume, or another multiplicative factor that represents the effect of bathymetry on cell interface area / volume.

@hdrake
Copy link
Contributor

hdrake commented May 11, 2021

@glwagner I think you're probably right that this can still be done, but the real problem has to do with the fact that density sorting is not unique due to non-linear pressure effects, and so you have to do some kind of iteration with different reference pressures. Maybe that just means an outer loop around the sorting of abstract operations though.

@glwagner
Copy link
Member

Ah, I understand. No abstraction can help with that.

This sounds similar to the problems that motivate the formulation of neutral density?

@tomchor
Copy link
Collaborator

tomchor commented May 12, 2021

Thanks, @hdrake, for bringing up this important point. I guess we should also remember that the sorting procedure is only an approximation to the actual calculation of background potential energy. It's super useful and easy in most cases, so most people jump straight to that, but the more "proper" calculation of BPE involves calculating the quantity z_*:

Screenshot from 2021-05-11 18-44-11

from Winters et alia, (1995).

I think calculating BPE this way still has some complications, but at least I believe the calculation is unique. It might be the preferred for cases with topography, stretched grids, etc.

@tomchor
Copy link
Collaborator

tomchor commented May 12, 2021

Also I'll post here my implementation of the sorting just in case it's useful for some people.

    function flattenedsort(A, dim_order::Union{Tuple, AbstractVector})
        return reshape(sort(Array(permutedims(A, dim_order)[:])), (grid.Nx, grid.Ny, grid.Nz))
    end

    function sort_b(model; average=false)
        b = model.tracers.b
        sorted_B = flattenedsort(interior(b), [3,2,1])
        if !average
            return sorted_B
        else
            return dropdims(mean(sorted_B, dims=(1,2)), dims=(1,2))
        end
    end
    mean_sort_b = (mod)->sort_b(mod; average=true)

I bet this can be done more elegantly but here it is. Thanks to @glwagner for pointing me in the right direction for this.

Note: Right now I have to explicitly transform b into an Array before sorting because the version of CUDA that Oceananigans currently uses doesn't have sort implemented. After we upgrade to Julia 1.6 we'll be able to use the most recent CUDA version and that transformation won't be necessary anymore (I think).

@glwagner
Copy link
Member

glwagner commented May 12, 2021

@hdrake's point references Huang (2005), who point out that a reference state (associated with z* in Winters et al 1995) may not be easily or uniquely definable for seawater with a nonlinear equation of state that depends on salinity, temperature, and pressure:

image

In practical terms I think the issue here is determine the "adiabatic rearrangement" mentioned by Winters et al. 2005. For a nonlinear equation of state like TEOS-10 where the buoyancy field b in the code depends on depth / hydrostatic pressure, the adiabatic rearrangement of the water column may not be obtained simply by sorting. However, @hdrake points out that an iterative procedure in which parcels are sorted, their buoyancy recalculated at the new depth, and then sorted again, may eventually converge to an adiabatic reference state.

@tomchor
Copy link
Collaborator

tomchor commented May 15, 2021

@glwagner thanks for clarifying. Coming from an atmospheric sciences background, I'm a bit unclear on the details of TEOS-10 and the nuances associated with it. In particular it seems counter-intuitive to me how an equation of state that depends on depth fits in a Boussinesq fluid (where adiabatic rearrangement of parcels shouldn't change their buoyancy). But this probably isn't the best place to have a long discussion about it.

Using the more fundamental definition of z_* does circumvent some of the issues mentioned by @hdrake, no? (Like topography.)

@glwagner
Copy link
Member

glwagner commented May 15, 2021

I think the difficult part is finding z*; this is what Huang 2005 seems to be discussing.

I'm hazy on the details (maybe @hdrake can chime in) but I think the point is that while an adiabatic rearrangement into a stable density profile may exist, it may not be obtainable by a single sorting procedure due to the pressure dependence of the equation of state. Some of the subtleties of the Boussinesq approximation for seawater are discussed in http://pordlabs.ucsd.edu/wryoung/reprintPDFs/SeawaterBoussinesq.pdf

@hdrake
Copy link
Contributor

hdrake commented May 20, 2021

@tomchor

Using the more fundamental definition of z_* does circumvent some of the issues mentioned by @hdrake, no? (Like topography.)

Somewhat, but even with the "fundamental" definition below there are some implicit assumptions. Winters et al. assume the area A is constant with depth. It's not clear to me that this formula still holds if A=A(z). Also not clear how to calculate a continuous A(z) from a discrete grid in a consistent way, especially with unstructured grids / or partial cells.
img

@glwagner
Copy link
Member

I'm converting this to a discussion!

@CliMA CliMA locked and limited conversation to collaborators Mar 22, 2023
@glwagner glwagner converted this issue into discussion #3001 Mar 22, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants