The PrimitiveWetModel example fails

[markmbaum]

I tried running the example in the readme:

spectral_grid = SpectralGrid(trunc=31, nlev=8)          # define resolution
orography = EarthOrography(spectral_grid)               # create non-default components
model = PrimitiveWetModel(; spectral_grid, orography)   # construct model
simulation = initialize!(model)                         # initialize all model components
run!(simulation, period=Day(10), output=true)           # aaaand action!

and it produces NaNs:

[milankl]

Thanks for the interest in this package 👋🏼 Which version do you use? I cannot reproduce this blowup. In general, if a simulation blows up the most helpful way to report this is

• version of SpeedyWeather you use
• model setup to reproduce (as you did)
• When it blew up (the nan detection tells you the time step)
• if you produce output the netcdf file is written even if it blows up, hence ideally go to the last time step before blowup and check which variable on which level has the strongest pre-blowup anomaly (is it in temperature, humidity, vorticity, which level?) and post a snapshot here

[markmbaum]

• I'm on v0.9.0
• The output indicates Warning: NaN or Inf detected at time step 1

[milankl]

On the first time step usually means you already started with NaNs somewhere in the initial conditions. Can you

• reinitialize the model (that resets all variables) and run again?
• if that doesn't work (it should though) also recreate the model. The model is independent of the variables but there is one exception (model.implicit and one more but that's resolved in #main) meaning no NaN could propagate into it.
• use the main branch

On the 2nd point maybe this helps https://github.com/SpeedyWeather/SpeedyWeather.jl/issues/350

[milankl]

@markmbaum did this get resolved?

[markmbaum]

It seems to be working now although I really can't explain why. Previously, I just copied that example snippet into a repl and it produced NaNs. Nevermind then!

The docs are generally extremely helpful, but it could be useful to have more indication of which model components are default and/or required. Relatedly, I'm getting an error when trying to use the tree function to look into simulations

julia> using SpeedyWeather

julia> SpeedyWeather.tree
ERROR: UndefVarError: `tree` not defined
Stacktrace:
 [1] getproperty(x::Module, f::Symbol)
   @ Base ./Base.jl:31
 [2] top-level scope
   @ REPL[3]:1

No idea why this is happening, as I can see the export clearly in the source and I'm using the latest version.

[milankl]

tree was only introduced after the latest release, so is only in the main branch not in v0.9 it works there

julia> using SpeedyWeather
julia> spectral_grid = SpectralGrid(trunc=31, nlev=1);
julia> model = ShallowWaterModel(;spectral_grid);
julia> simulation = initialize!(model);
julia> tree(simulation)
Simulation{ShallowWaterModel}
├┐prognostic_variables
│├ trunc
│├ nlat_half
│├ nlev
│├ n_steps
│├┐layers
││└┐timesteps
...

The docs are generally extremely helpful, but it could be useful to have more indication of which model components are default and/or required

none are required except for spectral_grid (not even that in v0.9, we made it only mandatory with #519) the defaults are usually best seen in the show of model

julia> model
ShallowWaterModel <: ShallowWater
├ spectral_grid: SpectralGrid
├ device_setup: SpeedyWeather.DeviceSetup{SpeedyWeather.CPUDevice, DataType}
├ geometry: Geometry{Float32}
├ planet: Earth{Float32}
├ atmosphere: EarthAtmosphere{Float32}
├ coriolis: Coriolis{Float32}
├ orography: EarthOrography{Float32, OctahedralGaussianGrid{Float32}}
├ forcing: NoForcing
├ drag: NoDrag
├ particle_advection: NoParticleAdvection
├ initial_conditions: InitialConditions{ZonalJet, ZeroInitially, ZeroInitially, ZeroInitially}
├ time_stepping: Leapfrog{Float32}
├ spectral_transform: SpectralTransform{Float32}
├ implicit: ImplicitShallowWater{Float32}
├ horizontal_diffusion: HyperDiffusion{Float32}
├ output: OutputWriter{Float32, ShallowWater}
├ callbacks: Dict{Symbol, SpeedyWeather.AbstractCallback}
└ feedback: Feedback

which shows all fields and their respective types that tell you what defaults are. You can then further inspect each of these, e.g.

julia> model.time_stepping
Leapfrog{Float32} <: SpeedyWeather.AbstractTimeStepper
├ trunc::Int64 = 31
├ Δt_at_T31::Second = 1800 seconds
├ radius::Float32 = 6.371e6
├ adjust_with_output::Bool = true
├ robert_filter::Float32 = 0.05
├ williams_filter::Float32 = 0.53
├ Δt_millisec::Dates.Millisecond = 1800000 milliseconds
├ Δt_sec::Float32 = 1800.0
└ Δt::Float32 = 0.0002825302

[milankl]

For more information always check the docstring (with ?) of the respective type (every model component is an instance of its own (struct) type), e.g.

help?> Leapfrog
search: Leapfrog

  Leapfrog time stepping defined by the following fields

    •  trunc::Int64: spectral resolution (max degree of spherical harmonics)

    •  Δt_at_T31::Second: time step in minutes for T31, scale linearly to trunc

    •  radius::AbstractFloat: radius of sphere [m], used for scaling

    •  adjust_with_output::Bool: adjust ΔtatT31 with the outputdt to reach outputdt exactly
       in integer time steps

    •  robert_filter::AbstractFloat: Robert (1966) time filter coefficeint to suppress
       comput. mode

    •  williams_filter::AbstractFloat: Williams time filter (Amezcua 2011) coefficient for
       3rd order acc

    •  Δt_millisec::Dates.Millisecond: time step Δt [ms] at specified resolution

    •  Δt_sec::AbstractFloat: time step Δt [s] at specified resolution

    •  Δt::AbstractFloat: time step Δt [s/m] at specified resolution, scaled by 1/radius

  ──────────────────────────────────────────────────────────────────────────────────────────────

  Leapfrog(spectral_grid::SpectralGrid; kwargs...) -> Leapfrog

  Generator function for a Leapfrog struct using spectral_grid for the resolution information.

[markmbaum]

Ok thank you!

tree was only introduced after the latest release, so is only in the main branch not in v0.9 it works there

Have you thought about a patch release when the docs get updated with things that are not yet in the latest version? Meaning 0.9.1. I could submit a PR.

[milankl]

Well that's why there are several version of the docs, /dev for the main branch, and then the various versions. I do agree we are due another release but I want to merge a few pull requests for that first!

[markmbaum]

Ah I see, that was my confusion as well. I thought I was on the stable docs.