Docs not building on main

[simone-silvestri]

Ok, now, once #176 was fixed, we have a new error on main:

[ Info: generating markdown page from `/storage5/github-action-runners/actions-runner-3/_work/NumericalEarth.jl/NumericalEarth.jl/examples/global_climate_simulation.jl`
ERROR: LoadError: LoadError: The following 1 direct dependency failed to precompile:

SpeedyWeather 

Failed to precompile SpeedyWeather [9e226e20-d153-4fed-8a5b-493def4f21a9] to "/storage5/github-action-runners/julia-depot/compiled/v1.12/SpeedyWeather/jl_HUDYvB".
ERROR: LoadError: UndefVarError: `SpeedyParameters` not defined in `SpeedyWeatherInternals`
Suggestion: check for spelling errors or missing imports.
Stacktrace:
 [1] top-level scope
   @ /storage5/github-action-runners/julia-depot/packages/SpeedyWeather/voHFE/src/SpeedyWeather.jl:48
 [2] include(mod::Module, _path::String)
   @ Base ./Base.jl:306
 [3] include_package_for_output(pkg::Base.PkgId, input::String, depot_path::Vector{String}, dl_load_path::Vector{String}, load_path::Vector{String}, concrete_deps::Vector{Pair{Base.PkgId, UInt128}}, source::Nothing)
   @ Base ./loading.jl:3024
 [4] top-level scope
   @ stdin:5
 [5] eval(m::Module, e::Any)
   @ Core ./boot.jl:489
 [6] include_string(mapexpr::typeof(identity), mod::Module, code::String, filename::String)
   @ Base ./loading.jl:2870
 [7] include_string
   @ ./loading.jl:2880 [inlined]
 [8] exec_options(opts::Base.JLOptions)
   @ Base ./client.jl:315
 [9] _start()
   @ Base ./client.jl:550
in expression starting at /storage5/github-action-runners/julia-depot/packages/SpeedyWeather/voHFE/src/SpeedyWeather.jl:1
in expression starting at stdin:
in expression starting at /storage5/github-action-runners/actions-runner-3/_work/NumericalEarth.jl/NumericalEarth.jl/docs/src/literated/global_climate_simulation.md:1
when executing the following code block from inputfile `/storage5/github-action-runners/actions-runner-3/_work/NumericalEarth.jl/NumericalEarth.jl/examples/global_climate_simulation.jl`

using Oceananigans, SpeedyWeather, XESMF, NumericalEarth
using NCDatasets, CairoMakie
using Oceananigans.Units
using Printf, Statistics, Dates

I think it has to do with #133

[maximilian-gelbrecht]

Yep, I think that's our fault. @milankl we have to be a bit more carful with setting compat entries for our submodules. NumericalEarth on main is restricted to an old SpeedyWeather version, but we didn't restrict that old version to not update our submodules. That's where this error comes from I think.

But I also just updated the PR #133 to include the new version we released an hour ago which should also fix this.

[milankl]

So the original problem was that I increased the SpeedyWeatherInternals version already to v0.2 without then actually releasing it? Meaning I should have done v0.2-DEV ?

[simone-silvestri]

With SpeedyWeather v0.19 documentation starts building, but then we hit this error
https://github.com/NumericalEarth/NumericalEarth.jl/actions/runs/25041877414/job/73346906368

@maximilian-gelbrecht @milankl do you know what it can be caused by?

[simone-silvestri]

I guess version 0.19 has disabled Hours for the output dt?

[maximilian-gelbrecht]

It's not really on purpose. We made more type parameters parametric (primarily for Reactant compatibility). I think it's a Julia quirk that I don't fully understand that disables the automatic convert once the type is parametric in some cases. This doesn't affect the constructor, so e.g. a SpeedyWeather.NetCDFOutput(spectral_grid; output_dt=Hour(3)) still works. This how we set the output_dt normally. This problem just occurs when setting a field of a mutable struct directly there. But I couldn't reproduce this in a simple example.

@milankl We should just add a set!(output; output_dt) for this case.

[maximilian-gelbrecht]

But wait. Did this ever actually work as intended? Because just setting the field after the Simulation is initialized doesn't actually change the output frequency anymore. Also not in the old version.

As a quick fix you could initialize the output correctly in the function that also inializes the Speedy simulation.

But we should def add a set!(output, output_dt).

I am actually off work a few days. So it'll have to wait a bit until I can look into it properly, but it should be an easy fix.

[simone-silvestri]

It was working here (although I am not necessarily sure it was correct)

[maximilian-gelbrecht]

It won't result in an error. It just might result in a wrong output frequency as you already initialize the Simulation, including the output when building the Speedy model.

I ll look into this in a few days, if Milan isn't faster.