Skip to content

Divergent initial velocity fields cause tracer and buoyancy non-conservation with zstar #4412

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

Open
NoraLoose opened this issue Apr 17, 2025 · 5 comments

Comments

@NoraLoose
Copy link
Collaborator

While working on #4395 and #4403, we tested initializing simulations with random velocity fields using the zstar vertical coordinate. This resulted in tracer and buoyancy non-conservation due to the barotropic velocity field being divergent at the start. The divergence causes non-zero vertical velocities at the surface, which immediately breaks conservation.

Proposed Solutions

  • Short-term: Emit a warning if the user attempts to initialize a zstar simulation with a divergent horizontal velocity field.
  • Long-term: Develop a strategy to correct arbitrary initial velocity fields to ensure they are exactly divergence-free if zstar is used. This would be helpful in all cases where users don't spin up from rest, for example if they:
    • initialize with random velocities
    • initialize with velocities regridded from other simulations (which are unlikely to be perfectly divergence-free)
@glwagner
Copy link
Member

glwagner commented Apr 17, 2025

Is it also possible that there is some inconsistency between the free surface and the velocity field divergence?

There is a similar issue with the NonhydrostaticModel which is why we subtract out the divergent part of the initial condition:

if enforce_incompressibility
FT = eltype(model.grid)
calculate_pressure_correction!(model, one(FT))
pressure_correct_velocities!(model, one(FT))
update_state!(model; compute_tendencies = false)
end

Possibly we need to do something similar involving a free surface spin up / fake time-step to ensure consistency there before starting a simulation, not sure.

@NoraLoose
Copy link
Collaborator Author

The problem seems to be specific to the SplitExplicitFreeSurface, see this comment.

@NoraLoose
Copy link
Collaborator Author

Great, we can probably just do what is done for the NonhyrdostaticModel.

@glwagner
Copy link
Member

Great, we can probably just do what is done for the NonhyrdostaticModel.

Ah perhaps, but note that the divergence in the nonhydrostatic model is 3D whereas (I think) you may be referring to 2D divergence here (which is valid, but there is a vertical velocity implied). I wonder if the right solution is not to do exactly the same thing but some kind of analog, eg compute the free surface displacement consistent with the horizontal divergence / vertical velocity, or something...

@simone-silvestri
Copy link
Collaborator

Yeah, I think we can compute ∂t_σ such that

           δx(Δy U) + δy(Δx V)       ∇  U
∂t_σ = - --------------------- = - --------
                  Az  H               H 

(where U and V are the barotropic velocities), and then the corresponding η associated with ∂t_σ.
Note that the continuity equation reads

  wᵏ⁺¹ - wᵏ      δx(Ax u) + δy(Ay v)     Δr ∂t_σ
 ---------- = - --------------------- - ----------
     Δz                 vol                 Δz

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants