More pedagogical computation of continuity equation #1321
Conversation
blallen
added
Ocean 🌊
|
bors try |
|
@jm-c and @christophernhill, take a look and let me know what you think. This method is kinda half-way between what is in @jm-c branch and in master. |
tryBuild succeeded: |
|
@blallen how does this map to should we get in sync using |
In terms of the math, the only difference is that between calculating a divergence directly and calculating it from the trace of the gradient tensor, e.g. none. Algorithmically, this uses more memory than JMC's way (altho I just realized I can make a fix to make it use the same or less (will push it soon)) but saves us the step of having to do another iteration across all the elements. Seeing as we currently only do two of those per time step, adding a third is an ~50% increase in compute time. The main advantage of JMC's method is that we can choose the numerical flux for the continuity equation separately from that of the rest of the gradients calculated. Currently, this just means we can do central or Rusanov fluxes with JMC's method, but only central with mine. In the future, this might be a bigger difference, but I also hope/expect that we will have more flexibility in specifying the numerical fluxes for gradients by the time we have the more complicated numerical fluxes. |
|
Can we mark it WIP for now? I think we want to be able to check reference
numbers for things we merge?
…On Tue, Jul 7, 2020 at 09:23 Brandon Allen ***@***.***> wrote:
@blallen <https://github.com/blallen> how does this map to
https://github.com/jm-c/CLIMA/blob/jmc/split_explicit_draft/src/Ocean/SplitExplicit01/Continuity3dModel.jl
should we get in sync using Continuity3dModel.jl before changing to
another new way?
In terms of the math, the only difference is that between calculating a
divergence directly and calculating it from the trace of the gradient
tensor, e.g. none.
Algorithmically, this uses more memory than JMC's way (altho I just
realized I can make a fix to make it use the same or less (will push it
soon)) but saves us the step of having to do another iteration across all
the elements. Seeing as we currently only do two of those per time step,
adding a third is an ~50% increase in compute time.
The main advantage of JMC's method is that we can choose the numerical
flux for the continuity equation separately from that of the rest of the
gradients calculated. Currently, this just means we can do central or
Rusanov fluxes with JMC's method, but only central with mine. In the
future, this might be a bigger difference, but I also hope/expect that we
will have more flexibility in specifying the numerical fluxes for gradients
by the time we have the more complicated numerical fluxes.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1321 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA27DYA5GF6M6TJYPZV7WX3R2MNODANCNFSM4OPIUTOQ>
.
|
This is marked as a draft PR :) But this change doesn't change any of the state values in the state check. I simply turned off the gradient check for now, as I am adding new gradient variables so the order changes and the state check fails. We can still check reference numbers for PRs on top of this one. |
blallen
force-pushed
the
bla/ocean_continuity
branch
5 times, most recently
from
2f891a5
to
5ba1ce7
Compare
blallen
force-pushed
the
bla/ocean_continuity
branch
from
5ba1ce7
to
f72c4e4
Compare
|
bors r+ |
1280: Add types and unify functions in BalanceLaws r=charleskawczynski a=charleskawczynski # Description - Adds types to balance law (I have no strong opinions about the names here) ```julia abstract type AbstractStateType end struct Prognostic <: AbstractStateType end struct Auxiliary <: AbstractStateType end struct Gradient <: AbstractStateType end struct GradientFlux <: AbstractStateType end struct GradientLaplacian <: AbstractStateType end struct Hyperdiffusive <: AbstractStateType end struct UpwardIntegrals <: AbstractStateType end struct DownwardIntegrals <: AbstractStateType end ``` - Unifies `vars_state` (BalanceLaws) into a single function - Unifies `number_states` (BalanceLaws) into a single function - Unifies `create_state` (DGMethods) into a single function - Unifies `extract_state` (Diagnostics) into a single function 1321: More pedagogical computation of continuity equation r=blallen a=blallen # Description @jm-c pointed out that our current method for computing the continuity equation `∇u = 0` is a little counterintuitive. Here is one possible change we can make to improve the clarity while maintaining computational efficiency at the cost of some extra memory usage. 1359: Yt/boyd vandeven r=thomasgibson a=slifer50 # Description Addition of the Boyd-Vandeven filter. Co-authored-by: Charles Kawczynski <kawczynski.charles@gmail.com> Co-authored-by: Brandon Allen <ballen@mit.edu> Co-authored-by: yassine <yassinetissaoui@gmail.com>
|
Build failed (retrying...): |
Description
@jm-c pointed out that our current method for computing the continuity equation
∇u = 0is a little counterintuitive. Here is one possible change we can make to improve the clarity while maintaining computational efficiency at the cost of some extra memory usage.I have
tests/runtests.jljulia .dev/climaformat.jl .For review by CLIMA developers
julia .dev/format.jlhas been run in a separate commit.