free ODE

[b-r-hamilton]

TMI and TMItransient are no longer compatible because TMItransient is pinned at ODE@v6.33.3 and this causes a conflict at StatsBase

TMItransient also conflicts with DimensionalData because of this

[ggebbie]

PR #27 may allow ODE to be updated. It may be a sign that the upstream problem in DifferentialEquations.jl has been fixed. Someone should try out updating the environment and testing to see if #17 is a problem again.

[b-r-hamilton]

Tried following process

1. free ODE
2. remove [compat] entry from Project.toml so ODE can update
3. update all packages
4. kill julia, restart
5. Project looks like this

   (TMItransient) pkg> st
   Project TMItransient v0.1.8
   Status `~/Code/TMItransient.jl/Project.toml`
   [13f3f980] CairoMakie v0.12.10
   [8bb1440f] DelimitedFiles v1.9.1
   [cd3eb016] HTTP v1.10.8
   [a98d9a8b] Interpolations v0.15.1
   [85f8d34a] NCDatasets v0.14.5
   [b946abbf] NaNStatistics v0.6.41
   ⌃ [1dea7af3] OrdinaryDiffEq v6.87.0
   [d236fae5] PreallocationTools v0.4.24
   [295af30f] Revise v3.5.18
   ⌃ [c3572dad] Sundials v4.24.0
   [582500f6] TMI v0.2.17 `https://github.com/ggebbie/TMI.jl#main`
   [37e2e46d] LinearAlgebra
   [10745b16] Statistics v1.10.0
   Info Packages marked with ⌃ have new versions available and may be upgradable.

6. runtests.jl: then gives following error

   
   julia> include("../test/runtests.jl")
   A
   0.328616 seconds (313.92 k allocations: 50.401 MiB, 91.61% compilation time)
   Alu
   1.423963 seconds (5.53 k allocations: 681.558 MiB, 4.31% gc time, 0.33% compiltion time)
   L=
   0.816682 seconds (2.24 M allocations: 70.660 MiB, 33.29% gc time, 61.34% compiation time)
   B=
   0.149732 seconds (27.08 k allocations: 3.500 MiB, 89.77% compilation time)
   dry point, try again
   ┌ Warning: At t=2.056198140995793, dt was forced below floating point epsilon 4.440892098500626e-16, and step error estimate = 0.4634330513422522. Aborting. There is either an error in your model specification or the true solution is unstable (or the true solution can not be represented in the precision of Float64).
   └ @ SciMLBase ~/.julia/packages/SciMLBase/j8jQg/src/integrator_interface.jl:600
   410.762136 seconds (22.41 M allocations: 39.915 GiB, 2.62% gc time, 1.84% compilation time: <1% of which was recompilation)
   watermass_stepresponse: Test Failed at /home/brynn/Code/TMItransient.jl/test/runtests.jl:36
   Expression: sum(diff(D̄) .≥ 0) == length(D̄) - 1
   Evaluated: 2 == 3

Stacktrace: [1] macro expansion @ ~/.julia/juliaup/julia-1.10.0+0.x64.linux.gnu/share/julia/stdlib/v1.10/Test/src/Test.jl:672 [inlined] [2] macro expansion @ ~/Code/TMItransient.jl/test/runtests.jl:36 [inlined] [3] macro expansion @ ~/.julia/juliaup/julia-1.10.0+0.x64.linux.gnu/share/julia/stdlib/v1.10/Test/src/Test.jl:1577 [inlined] [4] macro expansion @ ~/Code/TMItransient.jl/test/runtests.jl:21 [inlined] [5] macro expansion @ ~/.julia/juliaup/julia-1.10.0+0.x64.linux.gnu/share/julia/stdlib/v1.10/Test/src/Test.jl:1577 [inlined] [6] top-level scope @ ~/Code/TMItransient.jl/test/runtests.jl:8

So I think the answer is, no, ODE is still not agreeeable with TMItransient... 

[ggebbie]

I interpret these results the same way. Do we know if the boundary condition is instantaneously prescribed or whether it is relaxed to some value? Relaxation would be more stable.

[b-r-hamilton]

It looks like the error is being generated in globalmean_stepresponse, which my understanding is an instantaneously prescribed BC.

[ggebbie]

correct, the ocean is initialized with all zeroes except ones in the mixed layer. It is a sharp discontinuity that is difficult to model.

Alternatives: 1. relaxation boundary conditions e.g. https://github.com/ggebbie/TMI.mat/blob/368d1fd39a1f75309735539b106ae261a67acb0f/src/get_tendency.m#L10

2. Set boundary conditions to be a linearly increasing ramp for t > 0, zero for t < 0. Then add an extra differentiation to the diagnostics, because the derivative of the above function is the Heaviside step function.