search

CliMA / ClimateMachine.jl

Climate Machine: an Earth System Model that automatically learns from data
https://clima.github.io/ClimateMachine.jl/latest/
Other
451 stars 78 forks source link

Using filters to effect overintegration / dealiasing #1762

Open glwagner opened 3 years ago

glwagner commented 3 years ago

Filters can be used to effect over-integration. This technique seems equivalent to the "2/3 deliasing" strategy used in some spectral codes, in which high aliased modes are "zeroed out" after calculating the products of terms (here we may need to dealias after both linear and nonlinear calculations).

Currently filters can be applied to the model state as callbacks (which can be run every time-step), or within functions like update_auxiliary_state! (which execute every RHS evaluation). For example, in HydrostaticBoussinesqModel, filters are applied in update_auxiliary_state!:

https://github.com/CliMA/ClimateMachine.jl/blob/4e317d42909bb31e535463aa13b83a4cc410058e/src/Ocean/HydrostaticBoussinesq/HydrostaticBoussinesqModel.jl#L656-L680

With this technique, the state is filtered prior to the RHS calculation:

https://github.com/CliMA/ClimateMachine.jl/blob/4e317d42909bb31e535463aa13b83a4cc410058e/src/Numerics/DGMethods/DGModel.jl#L141-L147

(Note that in HydrostaticBoussinesqModel, the filter is only applied during the first call to update_auxiliary_state! for realelems. Also, it's unclear whether only filtering the state can effect full overintegration. Two issues are 1. the filtered state may not be communicated correctly if filtering is implemented in update_auxiliary_state!, because communication is initiated prior to callingupdate_auxiliary_state! and 2. we may need to filter the state_gradient_flux; @jkozdon please advise).

An alternative strategy suggested by @jkozdon is to apply a cutoff filter both to to the state_gradient_flux after update_auxiliary_state_gradient!:

https://github.com/CliMA/ClimateMachine.jl/blob/4e317d42909bb31e535463aa13b83a4cc410058e/src/Numerics/DGMethods/DGModel.jl#L237

and after the tendency calculation is complete.

https://github.com/CliMA/ClimateMachine.jl/blob/4e317d42909bb31e535463aa13b83a4cc410058e/src/Numerics/DGMethods/DGModel.jl#L417

Presumably, this strategy ensures that the tendency used by time steppers to update the state vector does not have energy in high, aliased modes.

jkozdon commented 3 years ago

Two issues are 1. the filtered state may not be communicated correctly if filtering is implemented in update_auxiliary_state!, because communication is initiated prior to callingupdate_auxiliary_state!

update_auxiliary_state! and update_auxiliary_state_gradient! are assumed to either be local or involve the stack of dofs in a stacked mesh. This allows us to apply the update aux functions on the local / real elements and then after communication on communicated degrees of freedom.

If you want to filter the state, then you'd want to introduce an update_state! or something function which happens before communication (and leave update aux where it is for overlapping communication and computation).

  1. we may need to filter the state_gradient_flux; @jkozdon please advise).

There is an update_auxiliary_state_gradient! for this purpose

Zhengyu-Huang commented 3 years ago

Looking forward to the results!!!!

charleskawczynski commented 3 years ago

Just a reminder, we did add custom_filter!, which operates in the same way that update_auxiliary_state! does and updates the prognostic state

glwagner commented 3 years ago

@charleskawczynski where is custom_filter! invoked? I could not find it in the files linked above. Is it invoked twice, as it needs to be to act on both the state and the state gradient flux?

update_state! sounds right. And update_state_gradient_flux!?

glwagner commented 3 years ago

@thomasgibson @jkozdon do we still believe the approach outlined in this issue will work? Has it been tried?