Comments (21)
@glwagner, am I correct that this warning is only needed when 1)
hydrostatic_pressure_anomaly = nothing
and 2) immersed boundaries are being used?
The pressure solver is incorrect even with hydrostatic_pressure_anomaly = CenterField(grid)
, just that apparently only the nonhydrostatic part is incorrect so the error is smaller than with hydrostatic_pressure_anomaly = nothing
.
#3188 should solve this issue
from oceananigans.jl.
I've just been playing around with immersed boundaries and found that with hydrostatic_pressure_anomaly = nothing
I wasn't able to maintain an ocean at rest. It's almost like buoyant fluid was erupting out of the immersed boundary. T and S being zero inside the immersed boundary are probably causing huge gradients to show up somewhere?
I haven't dug into why this issue is so bad in my case, but I definitely second @tomchor's suggestion to make hydrostatic_pressure_anomaly = CenterField(grid)
the default!
hydrostatic_pressure_anomaly = nothing
without_hydrostatic_pressure_anomaly.mp4
hydrostatic_pressure_anomaly = CenterField(grid)
with_hydrostatic_pressure_anomaly.mp4
from oceananigans.jl.
@xkykai so you're saying the fix for the instability exists already and it's just a matter of implementing it in #3188? Is that right?
Yes, and itβs here at Yixiao-Zhang@c7983b8
This should work and fix the numerical issues, but has not been extensively validated yet.
from oceananigans.jl.
It's hard to imagine buoyancy is globally conserved in the first of Isba's movies above, although I guess a divergent velocity field could create a widespread tracer extrema like that while still technically conserving buoyancy...
We'll run some simulations with flux BCs and check conservation.
from oceananigans.jl.
It's almost like buoyant fluid was erupting out of the immersed boundary.
Wow, this looks like a much more egregious version of the spurious buoyancy sources that @ikeshwani was seeing! I think it probably has to specifically do with buoyancy gradients across the boundary. @ikeshwani's initial condition happened to be b=0
, which is the same as the fill value inside the immersed boundary, so the gradients only show up over time as the system adjusts.
from oceananigans.jl.
Right and that's a good succinct description. We could even have two warnings: (i) it's wrong and (ii) it's catastrophically wrong.
#3188 doesn't solve the problem, it actually introduces a totally new solver. After #3188, someone doing simulations in complex domains will have the choice of using an iterative solver with adjustable tolerance / iterations, or the old "incorrect" solver (which will be cheaper, and it seems that some people have been able to get mileage out of it).
from oceananigans.jl.
Yes I will work on it.
Would you like any help?
I will take a look at the state of it and see what is required to complete it, and will let you know when I need any help! Thanks a lot.
from oceananigans.jl.
Likely introduced by #3574.
@tomchor recommends changing the default setting of NonHydrostaticModel
to hydrostatic_pressure_anomaly = CenterField(grid)
(at least until issue has been addressed).
from oceananigans.jl.
Could the false tracer extrema be due to the advection scheme, which exhibits more errors in the case that the pressure is not separated? Note that the pressure solver is approximate in either case. But when the pressure is separated, I think the pressure solver may be more accurate.
I'm not sure there is any way that the pressure separation could directly impact the conservation of tracer, so I'm hypothesizing that the effect is indirect and occurs through the differences in the emergent dynamics.
from oceananigans.jl.
Sounds like a good idea to change the default for sure!
from oceananigans.jl.
I'm not sure there is any way that the pressure separation could directly impact the conservation of tracer, so I'm hypothesizing that the effect is indirect and occurs through the differences in the emergent dynamics.
Yes, I think the tracer errors must be arising due to differences in the emergent dynamics. Isn't there something about the errors in the pressure solver meaning that the velocity field is partially divergent and that the no-normal-flow boundary condition is not perfectly satisfied?
from oceananigans.jl.
@xkykai can answer more thoroughly I think but in general yes, because the pressure solver is only approximate, we are left with a choice between 1) a divergent velocity field or 2) leakage through the boundary.
I believe though that we have selected option (1), which means that tracer advection is also approximate but also that tracers are conserved (unlike option 2, where tracers would leak through the boundary but, because the velocity is non-divergent as our advection formulation assumes, tracer advection is "accurate").
Might be good to check whether tracer is globally conserved.
from oceananigans.jl.
Another test that reveals a problem with non-separated pressure is a simple horizontal wall in a 2D setup.
from oceananigans.jl.
I'm not sure this is a bug by the way. The code is correct -- it may simply be that the pressure solver numerical method itself is wrong (or "approximate" if you want to be generous).
A pressure solver that is at least theoretically correct for complex domains is/was being developed here: #3188
from oceananigans.jl.
Indeed the choice of divergent boundary flow has been made so that there is no tracer leakage through the boundary. One can try using #3188 which satisfies both no divergent flow and tracer leakage conditions, but is slower than using the FFT solver itself. Numerical instability has been observed in this solver occasionally due to numerical errors of the conjugate gradient solver occasionally giving zero eigenvalues which creates the instability. I was trying to find the fix for it but I think it's in @Yixiao-Zhang 's fork of Oceananigans.
from oceananigans.jl.
@xkykai so you're saying the fix for the instability exists already and it's just a matter of implementing it in #3188? Is that right?
from oceananigans.jl.
@xkykai would you like help with #3188 ?
It seems that we should also change the default treatment of hydrostatic pressure. I also think it would be appropriate to add a warning remarking about the approximate nature of the current pressure solver (at least until #3188 is merged). Would anyone like to take the lead on this?
from oceananigans.jl.
I also think it would be appropriate to add a warning remarking about the approximate nature of the current pressure solver (at least until #3188 is merged).
@glwagner, am I correct that this warning is only needed when 1) hydrostatic_pressure_anomaly = nothing
and 2) immersed boundaries are being used?
from oceananigans.jl.
Yes I will work on it.
from oceananigans.jl.
Yes I will work on it.
Would you like any help?
from oceananigans.jl.
I made a PR that adds a warning and changes the default for immersed boundary grids: #3692
I don't think this issue can really be closed. There will continue to be errors on immersed boundary grid for non-separated pressure.
Perhaps, once we have a new solver that we are confident reduces the chance of egregious errors, we can convert this to a discussion.
from oceananigans.jl.
Related Issues (20)
- `Mem.free` is deprecated HOT 1
- Add in documentation for user defined vertical diffusivity profile in the hydrostatic model HOT 3
- Error in AveragedTimeInterval Output HOT 32
- Documentation 2.0 HOT 3
- `cell_advection_timescale` (and CFL) does not account for `Flat` topologies HOT 1
- Support passing keyword arguments to `jldopen` when using `FieldTimeSeries` HOT 1
- `PartialCellBottom` needs to be adapted correctly for the GPU when using a `HydrostaticFreeSurfaceModel` HOT 4
- Performance benchmarks section of the README is super out of date HOT 3
- `view` fails on a `Field` indexed from `FieldTimeSeries`
- Ocenanigans license HOT 5
- Reducing parameter space usage by `LatitudeLongitudeGrid` HOT 3
- Why do we need 4 halo points in the vertical for `VectorInvariant(vertical_scheme=Centered())`? HOT 2
- `xspacings` is broken for `ImmersedBoundaryGrid`
- Change free surface displacement name from `Ξ·` to `displacement` for `HydrostaticFreeSurfaceModel`
- Docstring for `WENOVectorInvariant` is too terse and does not have examples
- Bottom drag on immersed boundaries may differ if implemented with `Forcing` vs `ImmersedBoundaryCondition`
- Convert code blocks documenting `ImmersedBoundaryCondition` to doctests HOT 10
- Re-licensing Oceananigans under Apache 2.0
- Do `intrinsic_vector` and `extrinsic_vector` belong in `Operators`?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from oceananigans.jl.