diff --git a/Manifest.toml b/Manifest.toml
index 544374801..0dd105fc2 100644
--- a/Manifest.toml
+++ b/Manifest.toml
@@ -1,8 +1,8 @@
 # This file is machine-generated - editing it directly is not advised
 
-julia_version = "1.11.8"
+julia_version = "1.11.9"
 manifest_format = "2.0"
-project_hash = "2294ed99ca36fd3146a910892cadcb05f17b53a2"
+project_hash = "e1514f1c2f1d0ee5cb42fcae104797660088ebbe"
 
 [[deps.ADTypes]]
 git-tree-sha1 = "f7304359109c768cf32dc5fa2d371565bb63b68a"
@@ -34,9 +34,9 @@ version = "0.5.24"
 
 [[deps.AbstractMCMC]]
 deps = ["BangBang", "ConsoleProgressMonitor", "Dates", "Distributed", "FillArrays", "LogDensityProblems", "Logging", "LoggingExtras", "ProgressLogging", "Random", "StatsBase", "TerminalLoggers", "Transducers", "UUIDs"]
-git-tree-sha1 = "b08a913be28a195574d0f9e87b6372709f696e4e"
+git-tree-sha1 = "511d0d8cbf38045be05188ae26880afb57342a88"
 uuid = "80f14c24-f653-4e6a-9b94-39d6b0f70001"
-version = "5.13.0"
+version = "5.14.0"
 
     [deps.AbstractMCMC.extensions]
     AbstractMCMCOnlineStatsExt = "OnlineStats"
@@ -47,14 +47,14 @@ version = "5.13.0"
     TensorBoardLogger = "899adc3e-224a-11e9-021f-63837185c80f"
 
 [[deps.AbstractPPL]]
-deps = ["AbstractMCMC", "Accessors", "DensityInterface", "JSON", "LinearAlgebra", "Random", "StatsBase"]
-git-tree-sha1 = "66aed89871b6a8458bb407327fa997d980ea894f"
+deps = ["AbstractMCMC", "Accessors", "BangBang", "DensityInterface", "JSON", "LinearAlgebra", "MacroTools", "OrderedCollections", "Random", "StatsBase"]
+git-tree-sha1 = "cc74854881ab9531bde1ecc624ef3f9821497717"
 uuid = "7a57a42e-76ec-4ea3-a279-07e840d6d9cf"
-version = "0.13.6"
+version = "0.14.1"
 weakdeps = ["Distributions"]
 
     [deps.AbstractPPL.extensions]
-    AbstractPPLDistributionsExt = ["Distributions"]
+    AbstractPPLDistributionsExt = ["Distributions", "LinearAlgebra"]
 
 [[deps.AbstractTrees]]
 git-tree-sha1 = "2d9c9a55f9c93e8887ad391fbae72f8ef55e1177"
@@ -87,9 +87,9 @@ version = "0.1.43"
 
 [[deps.Adapt]]
 deps = ["LinearAlgebra", "Requires"]
-git-tree-sha1 = "7e35fca2bdfba44d797c53dfe63a51fabf39bfc0"
+git-tree-sha1 = "35ea197a51ce46fcd01c4a44befce0578a1aaeca"
 uuid = "79e6a3ab-5dfb-504d-930d-738a2a938a0e"
-version = "4.4.0"
+version = "4.5.0"
 weakdeps = ["SparseArrays", "StaticArrays"]
 
     [deps.Adapt.extensions]
@@ -118,9 +118,9 @@ version = "0.8.3"
 
 [[deps.AdvancedMH]]
 deps = ["AbstractMCMC", "Distributions", "DocStringExtensions", "FillArrays", "LinearAlgebra", "LogDensityProblems", "Random", "Requires"]
-git-tree-sha1 = "c9be6a2d91cfe681f2cf454749c00ea5ceb8f07e"
+git-tree-sha1 = "62ddbccf0ce5c26f8ef3cebe4bedef6b1599d616"
 uuid = "5b7e9947-ddc0-4b3f-9b55-0d8042f74170"
-version = "0.8.9"
+version = "0.8.10"
 weakdeps = ["DiffResults", "ForwardDiff", "MCMCChains", "StructArrays"]
 
     [deps.AdvancedMH.extensions]
@@ -157,12 +157,6 @@ git-tree-sha1 = "9876e1e164b144ca45e9e3198d0b689cadfed9ff"
 uuid = "66dad0bd-aa9a-41b7-9441-69ab47430ed8"
 version = "1.1.3"
 
-[[deps.AlmostBlockDiagonals]]
-deps = ["ConcreteStructs"]
-git-tree-sha1 = "743abe5e5fe8cff96dad4123f263c0d8eee281c0"
-uuid = "a95523ee-d6da-40b5-98cc-27bc505739d5"
-version = "0.1.10"
-
 [[deps.ArgCheck]]
 git-tree-sha1 = "f9e9a66c9b7be1ad7372bbd9b062d9230c30c5ce"
 uuid = "dce04be8-c92d-5529-be00-80e4d2c0e197"
@@ -192,11 +186,12 @@ version = "3.5.2+0"
 
 [[deps.ArrayInterface]]
 deps = ["Adapt", "LinearAlgebra"]
-git-tree-sha1 = "d81ae5489e13bc03567d4fbbb06c546a5e53c857"
+git-tree-sha1 = "78b3a7a536b4b0a747a0f296ea77091ca0a9f9a3"
 uuid = "4fba245c-0d91-5ea0-9b3e-6abc04ee57a9"
-version = "7.22.0"
+version = "7.23.0"
 
     [deps.ArrayInterface.extensions]
+    ArrayInterfaceAMDGPUExt = "AMDGPU"
     ArrayInterfaceBandedMatricesExt = "BandedMatrices"
     ArrayInterfaceBlockBandedMatricesExt = "BlockBandedMatrices"
     ArrayInterfaceCUDAExt = "CUDA"
@@ -211,6 +206,7 @@ version = "7.22.0"
     ArrayInterfaceTrackerExt = "Tracker"
 
     [deps.ArrayInterface.weakdeps]
+    AMDGPU = "21141c5a-9bdb-4563-92ae-f87d6854732e"
     BandedMatrices = "aae01518-5342-5314-be14-df237901396f"
     BlockBandedMatrices = "ffab5731-97b5-5995-9138-79e8c1846df0"
     CUDA = "052768ef-5323-5732-b1bb-66c8b64840ba"
@@ -224,16 +220,6 @@ version = "7.22.0"
     StaticArraysCore = "1e83bf80-4336-4d27-bf5d-d5a4f845583c"
     Tracker = "9f7883ad-71c0-57eb-9f7f-b5c9e6d3789c"
 
-[[deps.ArrayLayouts]]
-deps = ["FillArrays", "LinearAlgebra", "StaticArrays"]
-git-tree-sha1 = "e0b47732a192dd59b9d079a06d04235e2f833963"
-uuid = "4c555306-a7a7-4459-81d9-ec55ddd5c99a"
-version = "1.12.2"
-weakdeps = ["SparseArrays"]
-
-    [deps.ArrayLayouts.extensions]
-    ArrayLayoutsSparseArraysExt = "SparseArrays"
-
 [[deps.Artifacts]]
 uuid = "56f22d72-fd6d-98f1-02f0-08ddc0907c33"
 version = "1.11.0"
@@ -268,25 +254,11 @@ git-tree-sha1 = "4126b08903b777c88edf1754288144a0492c05ad"
 uuid = "39de3d68-74b9-583c-8d2d-e117c070f3a9"
 version = "0.4.8"
 
-[[deps.BandedMatrices]]
-deps = ["ArrayLayouts", "FillArrays", "LinearAlgebra", "PrecompileTools"]
-git-tree-sha1 = "02fa77c70ba84361b9bc9ff28523bd9d78519265"
-uuid = "aae01518-5342-5314-be14-df237901396f"
-version = "1.11.0"
-
-    [deps.BandedMatrices.extensions]
-    BandedMatricesSparseArraysExt = "SparseArrays"
-    CliqueTreesExt = "CliqueTrees"
-
-    [deps.BandedMatrices.weakdeps]
-    CliqueTrees = "60701a23-6482-424a-84db-faee86b9b1f8"
-    SparseArrays = "2f01184e-e22b-5df5-ae63-d93ebab69eaf"
-
 [[deps.BangBang]]
 deps = ["Accessors", "ConstructionBase", "InitialValues", "LinearAlgebra"]
-git-tree-sha1 = "7edecc3b90af8373014393e98e8fcfbdf3b52543"
+git-tree-sha1 = "308d82aa3d83140909590aa5a7824540944f110f"
 uuid = "198e06fe-97b7-11e9-32a5-e1d131e6ad66"
-version = "0.4.7"
+version = "0.4.8"
 
     [deps.BangBang.extensions]
     BangBangChainRulesCoreExt = "ChainRulesCore"
@@ -314,21 +286,27 @@ uuid = "9718e550-a3fa-408a-8086-8db961cd8217"
 version = "0.1.1"
 
 [[deps.Bijectors]]
-deps = ["ArgCheck", "ChainRulesCore", "ChangesOfVariables", "Distributions", "DocStringExtensions", "Functors", "InverseFunctions", "IrrationalConstants", "LinearAlgebra", "LogExpFunctions", "MappedArrays", "Random", "Reexport", "Roots", "SparseArrays", "Statistics"]
-git-tree-sha1 = "52f3f101c0c541145da25fba9805f3ef076f2d96"
+deps = ["AbstractPPL", "ArgCheck", "ChainRulesCore", "ChangesOfVariables", "DifferentiationInterface", "Distributions", "DocStringExtensions", "EnzymeCore", "Functors", "InverseFunctions", "IrrationalConstants", "LinearAlgebra", "LogExpFunctions", "MappedArrays", "Random", "Reexport", "Roots", "SparseArrays", "Statistics", "Test"]
+git-tree-sha1 = "e876fd33fef2708270d8f72b4491af71fed12ec6"
 uuid = "76274a88-744f-5084-9051-94815aaf08c4"
-version = "0.15.16"
-weakdeps = ["ChainRules", "DistributionsAD", "EnzymeCore", "ForwardDiff", "LazyArrays", "Mooncake", "ReverseDiff"]
+version = "0.15.18"
 
     [deps.Bijectors.extensions]
     BijectorsDistributionsADExt = "DistributionsAD"
-    BijectorsEnzymeCoreExt = "EnzymeCore"
     BijectorsForwardDiffExt = "ForwardDiff"
     BijectorsLazyArraysExt = "LazyArrays"
     BijectorsMooncakeExt = "Mooncake"
     BijectorsReverseDiffChainRulesExt = ["ChainRules", "ReverseDiff"]
     BijectorsReverseDiffExt = "ReverseDiff"
 
+    [deps.Bijectors.weakdeps]
+    ChainRules = "082447d4-558c-5d27-93f4-14fc19e9eca2"
+    DistributionsAD = "ced4e74d-a319-5a8a-b0ac-84af2272839c"
+    ForwardDiff = "f6369f11-7733-5829-9624-2563aa707210"
+    LazyArrays = "5078a376-72f3-5289-bfd5-ec5146d43c02"
+    Mooncake = "da2b9cff-9c12-43a0-ae48-6db2b0edb7d6"
+    ReverseDiff = "37e2e3b7-166d-5795-8a7a-e32c996b4267"
+
 [[deps.BitFlags]]
 git-tree-sha1 = "0691e34b3bb8be9307330f88d1a3c3f25466c24d"
 uuid = "d1d4a3ce-64b1-5f1a-9ba4-7e7e69966f35"
@@ -340,59 +318,11 @@ git-tree-sha1 = "f21cfd4950cb9f0587d5067e69405ad2acd27b87"
 uuid = "62783981-4cbd-42fc-bca8-16325de8dc4b"
 version = "0.1.6"
 
-[[deps.BoundaryValueDiffEq]]
-deps = ["ADTypes", "BoundaryValueDiffEqAscher", "BoundaryValueDiffEqCore", "BoundaryValueDiffEqFIRK", "BoundaryValueDiffEqMIRK", "BoundaryValueDiffEqMIRKN", "BoundaryValueDiffEqShooting", "DiffEqBase", "FastClosures", "ForwardDiff", "LinearAlgebra", "Reexport", "SciMLBase"]
-git-tree-sha1 = "d6ec33e4516b2e790a64128afdb54f3b536667a7"
-uuid = "764a87c0-6b3e-53db-9096-fe964310641d"
-version = "5.18.0"
-
-    [deps.BoundaryValueDiffEq.extensions]
-    BoundaryValueDiffEqODEInterfaceExt = "ODEInterface"
-
-    [deps.BoundaryValueDiffEq.weakdeps]
-    ODEInterface = "54ca160b-1b9f-5127-a996-1867f4bc2a2c"
-
-[[deps.BoundaryValueDiffEqAscher]]
-deps = ["ADTypes", "AlmostBlockDiagonals", "BoundaryValueDiffEqCore", "ConcreteStructs", "DiffEqBase", "DifferentiationInterface", "FastClosures", "ForwardDiff", "LinearAlgebra", "PreallocationTools", "RecursiveArrayTools", "Reexport", "SciMLBase", "Setfield"]
-git-tree-sha1 = "47c833c459738a3f27c5b458ecf7832a4731ef4d"
-uuid = "7227322d-7511-4e07-9247-ad6ff830280e"
-version = "1.8.0"
-
-[[deps.BoundaryValueDiffEqCore]]
-deps = ["ADTypes", "Adapt", "ArrayInterface", "ConcreteStructs", "DiffEqBase", "ForwardDiff", "LineSearch", "LinearAlgebra", "Logging", "NonlinearSolveFirstOrder", "PreallocationTools", "RecursiveArrayTools", "Reexport", "SciMLBase", "Setfield", "SparseArrays", "SparseConnectivityTracer", "SparseMatrixColorings"]
-git-tree-sha1 = "b7b4d8cc80f116eab2eb6124dba58ea7aef31b85"
-uuid = "56b672f2-a5fe-4263-ab2d-da677488eb3a"
-version = "1.11.1"
-
-[[deps.BoundaryValueDiffEqFIRK]]
-deps = ["ADTypes", "ArrayInterface", "BandedMatrices", "BoundaryValueDiffEqCore", "ConcreteStructs", "DiffEqBase", "DifferentiationInterface", "FastAlmostBandedMatrices", "FastClosures", "ForwardDiff", "LinearAlgebra", "PreallocationTools", "PrecompileTools", "Preferences", "RecursiveArrayTools", "Reexport", "SciMLBase", "Setfield", "SparseArrays"]
-git-tree-sha1 = "325e6981a414cfa5181218936c23f0e16dee8f08"
-uuid = "85d9eb09-370e-4000-bb32-543851f73618"
-version = "1.9.0"
-
-[[deps.BoundaryValueDiffEqMIRK]]
-deps = ["ADTypes", "ArrayInterface", "BandedMatrices", "BoundaryValueDiffEqCore", "ConcreteStructs", "DiffEqBase", "DifferentiationInterface", "FastAlmostBandedMatrices", "FastClosures", "ForwardDiff", "LinearAlgebra", "PreallocationTools", "PrecompileTools", "Preferences", "RecursiveArrayTools", "Reexport", "SciMLBase", "Setfield", "SparseArrays"]
-git-tree-sha1 = "da6ae5e564ad06ced4d7504929c58130558007dd"
-uuid = "1a22d4ce-7765-49ea-b6f2-13c8438986a6"
-version = "1.9.0"
-
-[[deps.BoundaryValueDiffEqMIRKN]]
-deps = ["ADTypes", "ArrayInterface", "BandedMatrices", "BoundaryValueDiffEqCore", "ConcreteStructs", "DiffEqBase", "DifferentiationInterface", "FastAlmostBandedMatrices", "FastClosures", "ForwardDiff", "LinearAlgebra", "PreallocationTools", "PrecompileTools", "Preferences", "RecursiveArrayTools", "Reexport", "SciMLBase", "Setfield", "SparseArrays"]
-git-tree-sha1 = "609c2d03ea024df0d475fee483b93cf0e87c29d6"
-uuid = "9255f1d6-53bf-473e-b6bd-23f1ff009da4"
-version = "1.8.0"
-
-[[deps.BoundaryValueDiffEqShooting]]
-deps = ["ADTypes", "ArrayInterface", "BandedMatrices", "BoundaryValueDiffEqCore", "ConcreteStructs", "DiffEqBase", "DifferentiationInterface", "FastAlmostBandedMatrices", "FastClosures", "ForwardDiff", "LinearAlgebra", "PreallocationTools", "PrecompileTools", "Preferences", "RecursiveArrayTools", "Reexport", "SciMLBase", "Setfield", "SparseArrays"]
-git-tree-sha1 = "ba9bd1f31b58bfd5e48a56da0a426bcbd3462546"
-uuid = "ed55bfe0-3725-4db6-871e-a1dc9f42a757"
-version = "1.9.0"
-
 [[deps.BracketingNonlinearSolve]]
 deps = ["CommonSolve", "ConcreteStructs", "NonlinearSolveBase", "PrecompileTools", "Reexport", "SciMLBase"]
-git-tree-sha1 = "750f782fcc7e09283be7d8a7aa687a95e4911b60"
+git-tree-sha1 = "4999dff8efd76814f6662519b985aeda975a1924"
 uuid = "70df07ce-3d50-431d-a3e7-ca6ddb60ac1e"
-version = "1.6.2"
+version = "1.11.0"
 weakdeps = ["ChainRulesCore", "ForwardDiff"]
 
     [deps.BracketingNonlinearSolve.extensions]
@@ -418,15 +348,15 @@ version = "0.2.7"
 
 [[deps.CSV]]
 deps = ["CodecZlib", "Dates", "FilePathsBase", "InlineStrings", "Mmap", "Parsers", "PooledArrays", "PrecompileTools", "SentinelArrays", "Tables", "Unicode", "WeakRefStrings", "WorkerUtilities"]
-git-tree-sha1 = "deddd8725e5e1cc49ee205a1964256043720a6c3"
+git-tree-sha1 = "8d8e0b0f350b8e1c91420b5e64e5de774c2f0f4d"
 uuid = "336ed68f-0bac-5ca0-87d4-7b16caf5d00b"
-version = "0.10.15"
+version = "0.10.16"
 
 [[deps.Cairo_jll]]
 deps = ["Artifacts", "Bzip2_jll", "CompilerSupportLibraries_jll", "Fontconfig_jll", "FreeType2_jll", "Glib_jll", "JLLWrappers", "LZO_jll", "Libdl", "Pixman_jll", "Xorg_libXext_jll", "Xorg_libXrender_jll", "Zlib_jll", "libpng_jll"]
-git-tree-sha1 = "fde3bf89aead2e723284a8ff9cdf5b551ed700e8"
+git-tree-sha1 = "a21c5464519504e41e0cbc91f0188e8ca23d7440"
 uuid = "83423d85-b0ee-5818-9007-b63ccbeb887a"
-version = "1.18.5+0"
+version = "1.18.5+1"
 
 [[deps.Cassette]]
 git-tree-sha1 = "f8764df8d9d2aec2812f009a1ac39e46c33354b8"
@@ -457,9 +387,9 @@ version = "1.0.2"
 
 [[deps.ChainRules]]
 deps = ["Adapt", "ChainRulesCore", "Compat", "Distributed", "GPUArraysCore", "IrrationalConstants", "LinearAlgebra", "Random", "RealDot", "SparseArrays", "SparseInverseSubset", "Statistics", "StructArrays", "SuiteSparse"]
-git-tree-sha1 = "3b704353e517a957323bd3ac70fa7b669b5f48d4"
+git-tree-sha1 = "3c190c570fb3108c09f838607386d10c71701789"
 uuid = "082447d4-558c-5d27-93f4-14fc19e9eca2"
-version = "1.72.6"
+version = "1.73.0"
 
 [[deps.ChainRulesCore]]
 deps = ["Compat", "LinearAlgebra"]
@@ -542,11 +472,6 @@ git-tree-sha1 = "37ea44092930b1811e666c3bc38065d7d87fcc74"
 uuid = "5ae59095-9a9b-59fe-a467-6f913c188581"
 version = "0.13.1"
 
-[[deps.Combinatorics]]
-git-tree-sha1 = "c761b00e7755700f9cdf5b02039939d1359330e1"
-uuid = "861a8166-3701-5b0c-9a16-15d98fcdc6aa"
-version = "1.1.0"
-
 [[deps.CommonSolve]]
 git-tree-sha1 = "78ea4ddbcf9c241827e7035c3a03e2e456711470"
 uuid = "38540f10-b2f7-11e9-35d8-d573e4eb0ff2"
@@ -594,9 +519,9 @@ version = "0.2.3"
 
 [[deps.ConcurrentUtilities]]
 deps = ["Serialization", "Sockets"]
-git-tree-sha1 = "d9d26935a0bcffc87d2613ce14c527c99fc543fd"
+git-tree-sha1 = "21d088c496ea22914fe80906eb5bce65755e5ec8"
 uuid = "f0e56b4a-5159-44fe-b623-3e5288b988bb"
-version = "2.5.0"
+version = "2.5.1"
 
 [[deps.ConsoleProgressMonitor]]
 deps = ["Logging", "ProgressMeter"]
@@ -649,10 +574,10 @@ uuid = "a93c6f00-e57d-5684-b7b6-d8193f3e46c0"
 version = "1.8.1"
 
 [[deps.DataStructures]]
-deps = ["Compat", "InteractiveUtils", "OrderedCollections"]
-git-tree-sha1 = "4e1fe97fdaed23e9dc21d4d664bea76b65fc50a0"
+deps = ["OrderedCollections"]
+git-tree-sha1 = "e357641bb3e0638d353c4b29ea0e40ea644066a6"
 uuid = "864edb3b-99cc-5e75-8d2d-829cb0a9cfe8"
-version = "0.18.22"
+version = "0.19.3"
 
 [[deps.DataValueInterfaces]]
 git-tree-sha1 = "bfc1187b79289637fa0ef6d4436ebdfe6905cbd6"
@@ -676,10 +601,10 @@ uuid = "244e2a9f-e319-4986-a169-4d1fe445cd52"
 version = "0.1.2"
 
 [[deps.DelayDiffEq]]
-deps = ["ArrayInterface", "DataStructures", "DiffEqBase", "FastBroadcast", "ForwardDiff", "LinearAlgebra", "Logging", "OrdinaryDiffEq", "OrdinaryDiffEqCore", "OrdinaryDiffEqDefault", "OrdinaryDiffEqDifferentiation", "OrdinaryDiffEqFunctionMap", "OrdinaryDiffEqNonlinearSolve", "OrdinaryDiffEqRosenbrock", "Printf", "RecursiveArrayTools", "Reexport", "SciMLBase", "SimpleNonlinearSolve", "SymbolicIndexingInterface"]
-git-tree-sha1 = "3bb871aa4a73f6972f7597c9ff4a4dccc1830b68"
+deps = ["ArrayInterface", "ConcreteStructs", "DataStructures", "DiffEqBase", "FastBroadcast", "ForwardDiff", "LinearAlgebra", "Logging", "OrdinaryDiffEq", "OrdinaryDiffEqCore", "OrdinaryDiffEqDefault", "OrdinaryDiffEqDifferentiation", "OrdinaryDiffEqFunctionMap", "OrdinaryDiffEqNonlinearSolve", "OrdinaryDiffEqRosenbrock", "Printf", "RecursiveArrayTools", "Reexport", "SciMLBase", "SciMLLogging", "SimpleNonlinearSolve", "SymbolicIndexingInterface"]
+git-tree-sha1 = "508151e101ee796201a4abd05506c6027213e967"
 uuid = "bcd4f6db-9728-5f36-b5f7-82caef46ccdb"
-version = "5.66.0"
+version = "5.69.0"
 
 [[deps.DelimitedFiles]]
 deps = ["Mmap"]
@@ -695,14 +620,15 @@ version = "0.4.0"
 
 [[deps.DiffEqBase]]
 deps = ["ArrayInterface", "BracketingNonlinearSolve", "ConcreteStructs", "DocStringExtensions", "FastBroadcast", "FastClosures", "FastPower", "FunctionWrappers", "FunctionWrappersWrappers", "LinearAlgebra", "Logging", "Markdown", "MuladdMacro", "PrecompileTools", "Printf", "RecursiveArrayTools", "Reexport", "SciMLBase", "SciMLOperators", "SciMLStructures", "Setfield", "Static", "StaticArraysCore", "SymbolicIndexingInterface", "TruncatedStacktraces"]
-git-tree-sha1 = "c4707e6374210edbad5d2e1be1bd0e38d8106203"
+git-tree-sha1 = "1719cd1b0a12e01775dc6db1577dd6ace1798fee"
 uuid = "2b5f629d-d688-5b77-993f-72d75c75574e"
-version = "6.200.0"
+version = "6.210.1"
 
     [deps.DiffEqBase.extensions]
     DiffEqBaseCUDAExt = "CUDA"
     DiffEqBaseChainRulesCoreExt = "ChainRulesCore"
     DiffEqBaseEnzymeExt = ["ChainRulesCore", "Enzyme"]
+    DiffEqBaseFlexUnitsExt = "FlexUnits"
     DiffEqBaseForwardDiffExt = ["ForwardDiff"]
     DiffEqBaseGTPSAExt = "GTPSA"
     DiffEqBaseGeneralizedGeneratedExt = "GeneralizedGenerated"
@@ -720,6 +646,7 @@ version = "6.200.0"
     ChainRulesCore = "d360d2e6-b24c-11e9-a2a3-2a2ae2dbcce4"
     Distributions = "31c24e10-a181-5473-b8eb-7969acd0382f"
     Enzyme = "7da242da-08ed-463a-9acd-ee780be4f1d9"
+    FlexUnits = "76e01b6b-c995-4ce6-8559-91e72a3d4e95"
     ForwardDiff = "f6369f11-7733-5829-9624-2563aa707210"
     GTPSA = "b27dd330-f138-47c5-815b-40db9dd9b6e8"
     GeneralizedGenerated = "6b9d7cbe-bcb9-11e9-073f-15a7a543e2eb"
@@ -743,10 +670,10 @@ weakdeps = ["Functors"]
     DiffEqCallbacksFunctorsExt = "Functors"
 
 [[deps.DiffEqNoiseProcess]]
-deps = ["CommonSolve", "DiffEqBase", "Distributions", "GPUArraysCore", "LinearAlgebra", "Markdown", "PoissonRandom", "QuadGK", "Random", "Random123", "RecipesBase", "RecursiveArrayTools", "ResettableStacks", "SciMLBase", "StaticArraysCore", "Statistics"]
-git-tree-sha1 = "76fbb6985dda2aba32c97148540ad2c043e741e3"
+deps = ["CommonSolve", "DiffEqBase", "Distributions", "GPUArraysCore", "LinearAlgebra", "Markdown", "PoissonRandom", "QuadGK", "Random", "RecipesBase", "RecursiveArrayTools", "ResettableStacks", "SciMLBase", "StaticArraysCore", "Statistics"]
+git-tree-sha1 = "b879ca516034469f28becdf01f85f56b45f518b9"
 uuid = "77a26b50-5914-5dd7-bc55-306e6241c503"
-version = "5.26.0"
+version = "5.27.0"
 weakdeps = ["Optim", "ReverseDiff"]
 
     [deps.DiffEqNoiseProcess.extensions]
@@ -765,17 +692,11 @@ git-tree-sha1 = "23163d55f885173722d1e4cf0f6110cdbaf7e272"
 uuid = "b552c78f-8df3-52c6-915a-8e097449b14b"
 version = "1.15.1"
 
-[[deps.DifferentialEquations]]
-deps = ["BoundaryValueDiffEq", "DelayDiffEq", "DiffEqBase", "DiffEqCallbacks", "DiffEqNoiseProcess", "JumpProcesses", "LinearAlgebra", "LinearSolve", "NonlinearSolve", "OrdinaryDiffEq", "Random", "RecursiveArrayTools", "Reexport", "SciMLBase", "SteadyStateDiffEq", "StochasticDiffEq", "Sundials"]
-git-tree-sha1 = "1df783c534cd0c4a865a397b1c4801771b5cbb07"
-uuid = "0c46a032-eb83-5123-abaf-570d42b7fbaa"
-version = "7.17.0"
-
 [[deps.DifferentiationInterface]]
 deps = ["ADTypes", "LinearAlgebra"]
-git-tree-sha1 = "5e6897d988addbfe7d9ad2ee467cc0c91001aae4"
+git-tree-sha1 = "7ae99144ea44715402c6c882bfef2adbeadbc4ce"
 uuid = "a0c0ee7d-e4b9-4e03-894e-1c5f64a51d63"
-version = "0.7.15"
+version = "0.7.16"
 
     [deps.DifferentiationInterface.extensions]
     DifferentiationInterfaceChainRulesCoreExt = "ChainRulesCore"
@@ -860,19 +781,6 @@ weakdeps = ["ChainRulesCore", "DensityInterface", "Test"]
     DistributionsDensityInterfaceExt = "DensityInterface"
     DistributionsTestExt = "Test"
 
-[[deps.DistributionsAD]]
-deps = ["Adapt", "ChainRules", "ChainRulesCore", "Compat", "Distributions", "FillArrays", "LinearAlgebra", "PDMats", "Random", "Requires", "SpecialFunctions", "StaticArrays", "StatsFuns", "ZygoteRules"]
-git-tree-sha1 = "4acbf909e892ce1f94c39a138541566c1aad5e66"
-uuid = "ced4e74d-a319-5a8a-b0ac-84af2272839c"
-version = "0.6.58"
-weakdeps = ["ForwardDiff", "LazyArrays", "ReverseDiff", "Tracker"]
-
-    [deps.DistributionsAD.extensions]
-    DistributionsADForwardDiffExt = "ForwardDiff"
-    DistributionsADLazyArraysExt = "LazyArrays"
-    DistributionsADReverseDiffExt = "ReverseDiff"
-    DistributionsADTrackerExt = "Tracker"
-
 [[deps.DocStringExtensions]]
 git-tree-sha1 = "7442a5dfe1ebb773c29cc2962a8980f47221d76c"
 uuid = "ffbed154-4ef7-542d-bbb7-c09d3a79fcae"
@@ -890,29 +798,27 @@ uuid = "bbc10e6e-7c05-544b-b16e-64fede858acb"
 version = "3.6.0"
 
 [[deps.DynamicPPL]]
-deps = ["ADTypes", "AbstractMCMC", "AbstractPPL", "Accessors", "BangBang", "Bijectors", "Chairmarks", "Compat", "ConstructionBase", "DifferentiationInterface", "Distributions", "DocStringExtensions", "InteractiveUtils", "LinearAlgebra", "LogDensityProblems", "MacroTools", "OrderedCollections", "Printf", "Random", "Statistics", "Test"]
-git-tree-sha1 = "2094be08e519dd8bca023f16643c0b1db300615f"
+deps = ["ADTypes", "AbstractMCMC", "AbstractPPL", "Accessors", "BangBang", "Bijectors", "Chairmarks", "Compat", "ConstructionBase", "DifferentiationInterface", "Distributions", "DocStringExtensions", "FillArrays", "InteractiveUtils", "LinearAlgebra", "LogDensityProblems", "MacroTools", "OrderedCollections", "PrecompileTools", "Printf", "Random", "Statistics", "Test"]
+git-tree-sha1 = "9b4203a175a2b49963711899d4d25e10c25d14ae"
 uuid = "366bfd00-2699-11ea-058f-f148b4cae6d8"
-version = "0.39.13"
+version = "0.40.7"
 
     [deps.DynamicPPL.extensions]
-    DynamicPPLChainRulesCoreExt = ["ChainRulesCore"]
     DynamicPPLEnzymeCoreExt = ["EnzymeCore"]
     DynamicPPLForwardDiffExt = ["ForwardDiff"]
-    DynamicPPLJETExt = ["JET"]
     DynamicPPLMCMCChainsExt = ["MCMCChains"]
     DynamicPPLMarginalLogDensitiesExt = ["MarginalLogDensities"]
-    DynamicPPLMooncakeExt = ["Mooncake"]
+    DynamicPPLMooncakeExt = ["Mooncake", "DifferentiationInterface"]
+    DynamicPPLReverseDiffExt = ["ReverseDiff"]
 
     [deps.DynamicPPL.weakdeps]
-    ChainRulesCore = "d360d2e6-b24c-11e9-a2a3-2a2ae2dbcce4"
     EnzymeCore = "f151be2c-9106-41f4-ab19-57ee4f262869"
     ForwardDiff = "f6369f11-7733-5829-9624-2563aa707210"
-    JET = "c3a54625-cd67-489e-a8e7-0a5a0ff4e31b"
     KernelAbstractions = "63c18a36-062a-441e-b654-da1e3ab1ce7c"
     MCMCChains = "c7f686f2-ff18-58e9-bc7b-31028e88f75d"
     MarginalLogDensities = "f0c3360a-fb8d-11e9-1194-5521fd7ee392"
     Mooncake = "da2b9cff-9c12-43a0-ae48-6db2b0edb7d6"
+    ReverseDiff = "37e2e3b7-166d-5795-8a7a-e32c996b4267"
 
 [[deps.EllipticalSliceSampling]]
 deps = ["AbstractMCMC", "ArrayInterface", "Distributions", "Random", "Statistics"]
@@ -921,9 +827,9 @@ uuid = "cad2338a-1db2-11e9-3401-43bc07c9ede2"
 version = "2.0.0"
 
 [[deps.EnumX]]
-git-tree-sha1 = "7bebc8aad6ee6217c78c5ddcf7ed289d65d0263e"
+git-tree-sha1 = "c49898e8438c828577f04b92fc9368c388ac783c"
 uuid = "4e289a0a-7415-4d19-859d-a7e5c4648b56"
-version = "1.0.6"
+version = "1.0.7"
 
 [[deps.Enzyme]]
 deps = ["CEnum", "EnzymeCore", "Enzyme_jll", "GPUCompiler", "InteractiveUtils", "LLVM", "Libdl", "LinearAlgebra", "ObjectFile", "PrecompileTools", "Preferences", "Printf", "Random", "SparseArrays"]
@@ -998,9 +904,9 @@ uuid = "e2ba6199-217a-4e67-a87a-7c52f15ade04"
 version = "0.1.10"
 
 [[deps.ExpressionExplorer]]
-git-tree-sha1 = "4a8c0a9eebf807ac42f0f6de758e60a20be25ffb"
+git-tree-sha1 = "5f1c005ed214356bbe41d442cc1ccd416e510b7e"
 uuid = "21656369-7473-754a-2065-74616d696c43"
-version = "1.1.3"
+version = "1.1.4"
 
 [[deps.ExproniconLite]]
 git-tree-sha1 = "c13f0b150373771b0fdc1713c97860f8df12e6c2"
@@ -1037,12 +943,6 @@ git-tree-sha1 = "656f7a6859be8673bf1f35da5670246b923964f7"
 uuid = "b9860ae5-e623-471e-878b-f6a53c775ea6"
 version = "0.1.1"
 
-[[deps.FastAlmostBandedMatrices]]
-deps = ["ArrayInterface", "ArrayLayouts", "BandedMatrices", "ConcreteStructs", "LazyArrays", "LinearAlgebra", "MatrixFactorizations", "PrecompileTools", "Reexport"]
-git-tree-sha1 = "3733dfb413e2a87c790cdf34f32f2c6a6f7fb95e"
-uuid = "9d29842c-ecb8-4973-b1e9-a27b1157504e"
-version = "0.1.6"
-
 [[deps.FastBroadcast]]
 deps = ["ArrayInterface", "LinearAlgebra", "Polyester", "Static", "StaticArrayInterface", "StrideArraysCore"]
 git-tree-sha1 = "ab1b34570bcdf272899062e1a56285a53ecaae08"
@@ -1232,9 +1132,9 @@ version = "1.8.2"
 
 [[deps.GR]]
 deps = ["Artifacts", "Base64", "DelimitedFiles", "Downloads", "GR_jll", "HTTP", "JSON", "Libdl", "LinearAlgebra", "Preferences", "Printf", "Qt6Wayland_jll", "Random", "Serialization", "Sockets", "TOML", "Tar", "Test", "p7zip_jll"]
-git-tree-sha1 = "ee0585b62671ce88e48d3409733230b401c9775c"
+git-tree-sha1 = "44716a1a667cb867ee0e9ec8edc31c3e4aa5afdc"
 uuid = "28b8d3ca-fb5f-59d9-8090-bfdbd6d07a71"
-version = "0.73.22"
+version = "0.73.24"
 
     [deps.GR.extensions]
     IJuliaExt = "IJulia"
@@ -1244,9 +1144,9 @@ version = "0.73.22"
 
 [[deps.GR_jll]]
 deps = ["Artifacts", "Bzip2_jll", "Cairo_jll", "FFMPEG_jll", "Fontconfig_jll", "FreeType2_jll", "GLFW_jll", "JLLWrappers", "JpegTurbo_jll", "Libdl", "Libtiff_jll", "Pixman_jll", "Qt6Base_jll", "Zlib_jll", "libpng_jll"]
-git-tree-sha1 = "7dd7173f7129a1b6f84e0f03e0890cd1189b0659"
+git-tree-sha1 = "be8a1b8065959e24fdc1b51402f39f3b6f0f6653"
 uuid = "d2c73de3-f751-5644-a686-071e5b155ba9"
-version = "0.73.22+0"
+version = "0.73.24+0"
 
 [[deps.GenericSchur]]
 deps = ["LinearAlgebra", "Printf"]
@@ -1268,9 +1168,9 @@ version = "9.55.1+0"
 
 [[deps.Glib_jll]]
 deps = ["Artifacts", "GettextRuntime_jll", "JLLWrappers", "Libdl", "Libffi_jll", "Libiconv_jll", "Libmount_jll", "PCRE2_jll", "Zlib_jll"]
-git-tree-sha1 = "6b4d2dc81736fe3980ff0e8879a9fc7c33c44ddf"
+git-tree-sha1 = "24f6def62397474a297bfcec22384101609142ed"
 uuid = "7746bdde-850d-59dc-9ae8-88ece973131d"
-version = "2.86.2+0"
+version = "2.86.3+0"
 
 [[deps.Graphite2_jll]]
 deps = ["Artifacts", "JLLWrappers", "Libdl"]
@@ -1279,10 +1179,14 @@ uuid = "3b182d85-2403-5c21-9c21-1e1f0cc25472"
 version = "1.3.15+0"
 
 [[deps.Graphs]]
-deps = ["ArnoldiMethod", "DataStructures", "Distributed", "Inflate", "LinearAlgebra", "Random", "SharedArrays", "SimpleTraits", "SparseArrays", "Statistics"]
-git-tree-sha1 = "7a98c6502f4632dbe9fb1973a4244eaa3324e84d"
+deps = ["ArnoldiMethod", "DataStructures", "Inflate", "LinearAlgebra", "Random", "SimpleTraits", "SparseArrays", "Statistics"]
+git-tree-sha1 = "7eb45fe833a5b7c51cf6d89c5a841d5967e44be3"
 uuid = "86223c79-3864-5bf0-83f7-82e725a168b6"
-version = "1.13.1"
+version = "1.14.0"
+weakdeps = ["Distributed", "SharedArrays"]
+
+    [deps.Graphs.extensions]
+    GraphsSharedArraysExt = "SharedArrays"
 
 [[deps.Grisu]]
 git-tree-sha1 = "53bb909d1151e57e2484c3d1b53e19552b887fb2"
@@ -1469,21 +1373,11 @@ git-tree-sha1 = "49fb3cb53362ddadb4415e9b73926d6b40709e70"
 uuid = "b14d175d-62b4-44ba-8fb7-3064adc8c3ec"
 version = "0.2.4"
 
-[[deps.JumpProcesses]]
-deps = ["ArrayInterface", "DataStructures", "DiffEqBase", "DiffEqCallbacks", "DocStringExtensions", "FunctionWrappers", "Graphs", "LinearAlgebra", "PoissonRandom", "Random", "RecursiveArrayTools", "Reexport", "SciMLBase", "Setfield", "StaticArrays", "SymbolicIndexingInterface"]
-git-tree-sha1 = "c19bb0be5fe979b4476ab5531393b4fb0752ace5"
-uuid = "ccbc3e58-028d-4f4c-8cd5-9ae44345cda5"
-version = "9.21.1"
-weakdeps = ["Adapt", "FastBroadcast", "KernelAbstractions"]
-
-    [deps.JumpProcesses.extensions]
-    JumpProcessesKernelAbstractionsExt = ["Adapt", "KernelAbstractions"]
-
 [[deps.KernelAbstractions]]
 deps = ["Adapt", "Atomix", "InteractiveUtils", "MacroTools", "PrecompileTools", "Requires", "StaticArrays", "UUIDs"]
-git-tree-sha1 = "b5a371fcd1d989d844a4354127365611ae1e305f"
+git-tree-sha1 = "fb14a863240d62fbf5922bf9f8803d7df6c62dc8"
 uuid = "63c18a36-062a-441e-b654-da1e3ab1ce7c"
-version = "0.9.39"
+version = "0.9.40"
 weakdeps = ["EnzymeCore", "LinearAlgebra", "SparseArrays"]
 
     [deps.KernelAbstractions.extensions]
@@ -1580,24 +1474,6 @@ git-tree-sha1 = "a9eaadb366f5493a5654e843864c13d8b107548c"
 uuid = "10f19ff3-798f-405d-979b-55457f8fc047"
 version = "0.1.17"
 
-[[deps.LazyArrays]]
-deps = ["ArrayLayouts", "FillArrays", "LinearAlgebra", "MacroTools", "SparseArrays"]
-git-tree-sha1 = "41d433e5854d7a67e8ab2b04962a713fcbcffcf1"
-uuid = "5078a376-72f3-5289-bfd5-ec5146d43c02"
-version = "2.9.5"
-
-    [deps.LazyArrays.extensions]
-    LazyArraysBandedMatricesExt = "BandedMatrices"
-    LazyArraysBlockArraysExt = "BlockArrays"
-    LazyArraysBlockBandedMatricesExt = "BlockBandedMatrices"
-    LazyArraysStaticArraysExt = "StaticArrays"
-
-    [deps.LazyArrays.weakdeps]
-    BandedMatrices = "aae01518-5342-5314-be14-df237901396f"
-    BlockArrays = "8e7c35d0-a365-5155-bbbb-fb81a777f24e"
-    BlockBandedMatrices = "ffab5731-97b5-5995-9138-79e8c1846df0"
-    StaticArrays = "90137ffa-7385-5640-81b9-e52037218182"
-
 [[deps.LazyArtifacts]]
 deps = ["Artifacts", "Pkg"]
 uuid = "4af54fe1-eca0-43a8-85a7-787d91b784e3"
@@ -1609,24 +1485,12 @@ git-tree-sha1 = "aff621f1f49e9262a34aaf0d57d02ea3b35aec60"
 uuid = "1fad7336-0346-5a1a-a56f-a06ba010965b"
 version = "0.1.3"
 
-[[deps.LearnBase]]
-deps = ["LinearAlgebra", "StatsBase"]
-git-tree-sha1 = "47e6f4623c1db88570c7a7fa66c6528b92ba4725"
-uuid = "7f8f8fb0-2700-5f03-b4bd-41f8cfc144b6"
-version = "0.3.0"
-
 [[deps.LeftChildRightSiblingTrees]]
 deps = ["AbstractTrees"]
 git-tree-sha1 = "95ba48564903b43b2462318aa243ee79d81135ff"
 uuid = "1d6d02ad-be62-4b6b-8a6d-2f90e265016e"
 version = "0.2.1"
 
-[[deps.LevyArea]]
-deps = ["LinearAlgebra", "Random", "SpecialFunctions"]
-git-tree-sha1 = "56513a09b8e0ae6485f34401ea9e2f31357958ec"
-uuid = "2d8b4e74-eb68-11e8-0fb9-d5eb67b50637"
-version = "1.0.0"
-
 [[deps.LibCURL]]
 deps = ["LibCURL_jll", "MozillaCACerts_jll"]
 uuid = "b27032c2-a3e7-50c8-80cd-2d36dbcbfd21"
@@ -1682,15 +1546,15 @@ version = "1.18.0+0"
 
 [[deps.Libmount_jll]]
 deps = ["Artifacts", "JLLWrappers", "Libdl"]
-git-tree-sha1 = "3acf07f130a76f87c041cfb2ff7d7284ca67b072"
+git-tree-sha1 = "97bbca976196f2a1eb9607131cb108c69ec3f8a6"
 uuid = "4b2f31a3-9ecc-558c-b454-b3730dcb73e9"
-version = "2.41.2+0"
+version = "2.41.3+0"
 
 [[deps.Libtask]]
 deps = ["MistyClosures", "Test"]
-git-tree-sha1 = "a88cfb11c45f350bbe51df05a1af7c691d58306d"
+git-tree-sha1 = "02dfe44e6115ecf1e55f3bc1be0df00d33901d4c"
 uuid = "6f1fad26-d15e-5dc8-ae53-837a1d7b8c9f"
-version = "0.9.10"
+version = "0.9.14"
 
 [[deps.Libtiff_jll]]
 deps = ["Artifacts", "JLLWrappers", "JpegTurbo_jll", "LERC_jll", "Libdl", "XZ_jll", "Zlib_jll", "Zstd_jll"]
@@ -1700,9 +1564,9 @@ version = "4.7.2+0"
 
 [[deps.Libuuid_jll]]
 deps = ["Artifacts", "JLLWrappers", "Libdl"]
-git-tree-sha1 = "2a7a12fc0a4e7fb773450d17975322aa77142106"
+git-tree-sha1 = "d0205286d9eceadc518742860bf23f703779a3d6"
 uuid = "38a345b3-de98-5d2b-a5d3-14cd9215e700"
-version = "2.41.2+0"
+version = "2.41.3+0"
 
 [[deps.LineSearch]]
 deps = ["ADTypes", "CommonSolve", "ConcreteStructs", "FastClosures", "LinearAlgebra", "MaybeInplace", "PrecompileTools", "SciMLBase", "SciMLJacobianOperators", "StaticArraysCore"]
@@ -1727,12 +1591,13 @@ version = "1.11.0"
 
 [[deps.LinearSolve]]
 deps = ["ArrayInterface", "ChainRulesCore", "ConcreteStructs", "DocStringExtensions", "EnumX", "GPUArraysCore", "InteractiveUtils", "Krylov", "Libdl", "LinearAlgebra", "MKL_jll", "Markdown", "OpenBLAS_jll", "PrecompileTools", "Preferences", "RecursiveArrayTools", "Reexport", "SciMLBase", "SciMLLogging", "SciMLOperators", "Setfield", "StaticArraysCore"]
-git-tree-sha1 = "7a1b73e0921e3278fce6a6cd80003c063ed937b4"
+git-tree-sha1 = "ba64436736405d666e0d22d54ee0e1b04e2e2b02"
 uuid = "7ed4a6bd-45f5-4d41-b270-4a48e9bafcae"
-version = "3.58.0"
+version = "3.64.0"
 
     [deps.LinearSolve.extensions]
     LinearSolveAMDGPUExt = "AMDGPU"
+    LinearSolveAlgebraicMultigridExt = "AlgebraicMultigrid"
     LinearSolveBLISExt = ["blis_jll", "LAPACK_jll"]
     LinearSolveBandedMatricesExt = "BandedMatrices"
     LinearSolveBlockDiagonalsExt = "BlockDiagonals"
@@ -1744,6 +1609,7 @@ version = "3.58.0"
     LinearSolveFastAlmostBandedMatricesExt = "FastAlmostBandedMatrices"
     LinearSolveFastLapackInterfaceExt = "FastLapackInterface"
     LinearSolveForwardDiffExt = "ForwardDiff"
+    LinearSolveGinkgoExt = ["Ginkgo", "SparseArrays"]
     LinearSolveHYPREExt = "HYPRE"
     LinearSolveIterativeSolversExt = "IterativeSolvers"
     LinearSolveKernelAbstractionsExt = "KernelAbstractions"
@@ -1751,6 +1617,7 @@ version = "3.58.0"
     LinearSolveMetalExt = "Metal"
     LinearSolveMooncakeExt = "Mooncake"
     LinearSolvePETScExt = ["PETSc", "SparseArrays"]
+    LinearSolveParUExt = ["ParU_jll", "SparseArrays"]
     LinearSolvePardisoExt = ["Pardiso", "SparseArrays"]
     LinearSolveRecursiveFactorizationExt = "RecursiveFactorization"
     LinearSolveSparseArraysExt = "SparseArrays"
@@ -1758,6 +1625,7 @@ version = "3.58.0"
 
     [deps.LinearSolve.weakdeps]
     AMDGPU = "21141c5a-9bdb-4563-92ae-f87d6854732e"
+    AlgebraicMultigrid = "2169fc97-5a83-5252-b627-83903c6c433c"
     BandedMatrices = "aae01518-5342-5314-be14-df237901396f"
     BlockDiagonals = "0a1fb500-61f7-11e9-3c65-f5ef3456f9f0"
     CUDA = "052768ef-5323-5732-b1bb-66c8b64840ba"
@@ -1768,6 +1636,7 @@ version = "3.58.0"
     FastAlmostBandedMatrices = "9d29842c-ecb8-4973-b1e9-a27b1157504e"
     FastLapackInterface = "29a986be-02c6-4525-aec4-84b980013641"
     ForwardDiff = "f6369f11-7733-5829-9624-2563aa707210"
+    Ginkgo = "4c8bd3c9-ead9-4b5e-a625-08f1338ba0ec"
     HYPRE = "b5ffcf37-a2bd-41ab-a3da-4bd9bc8ad771"
     IterativeSolvers = "42fd0dbc-a981-5370-80f2-aaf504508153"
     KernelAbstractions = "63c18a36-062a-441e-b654-da1e3ab1ce7c"
@@ -1776,6 +1645,7 @@ version = "3.58.0"
     Metal = "dde4c033-4e86-420c-a63e-0dd931031962"
     Mooncake = "da2b9cff-9c12-43a0-ae48-6db2b0edb7d6"
     PETSc = "ace2c81b-2b5f-4b1e-a30d-d662738edfe0"
+    ParU_jll = "9e0b026c-e8ce-559c-a2c4-6a3d5c955bc9"
     Pardiso = "46dd5b70-b6fb-5a00-ae2d-e8fea33afaf2"
     RecursiveFactorization = "f2c3362d-daeb-58d1-803e-2bc74f2840b4"
     SparseArrays = "2f01184e-e22b-5df5-ae63-d93ebab69eaf"
@@ -1840,9 +1710,9 @@ version = "1.2.0"
 
 [[deps.Lux]]
 deps = ["ADTypes", "Adapt", "ArrayInterface", "ChainRulesCore", "ConcreteStructs", "DiffResults", "DispatchDoctor", "EnzymeCore", "FastClosures", "ForwardDiff", "Functors", "GPUArraysCore", "LinearAlgebra", "LuxCore", "LuxLib", "MLDataDevices", "MacroTools", "Markdown", "NNlib", "Optimisers", "PrecompileTools", "Preferences", "Random", "ReactantCore", "Reexport", "SciMLPublic", "Setfield", "Static", "StaticArraysCore", "Statistics", "UUIDs", "WeightInitializers"]
-git-tree-sha1 = "9d618572621b53dbb7ab47ee97413b2a11e3f1ea"
+git-tree-sha1 = "334de475ff414c8eb67f88f57f7b02d40cd8f320"
 uuid = "b2108857-7c20-44ae-9111-449ecde12c47"
-version = "1.31.1"
+version = "1.31.3"
 
     [deps.Lux.extensions]
     ComponentArraysExt = "ComponentArrays"
@@ -1959,9 +1829,9 @@ version = "7.7.0"
 
 [[deps.MCMCDiagnosticTools]]
 deps = ["AbstractFFTs", "DataAPI", "DataStructures", "Distributions", "LinearAlgebra", "MLJModelInterface", "Random", "SpecialFunctions", "Statistics", "StatsBase", "StatsFuns", "Tables"]
-git-tree-sha1 = "526c98cd41028da22c01cb8a203246799ad853a8"
+git-tree-sha1 = "f90494689e927268dec7bbd1ece64f134ad251f4"
 uuid = "be115224-59cd-429b-ad48-344e309966f0"
-version = "0.3.15"
+version = "0.3.16"
 
 [[deps.MKL_jll]]
 deps = ["Artifacts", "IntelOpenMP_jll", "JLLWrappers", "LazyArtifacts", "Libdl", "oneTBB_jll"]
@@ -2023,30 +1893,12 @@ version = "1.17.4"
     cuDNN = "02a925ec-e4fe-4b08-9a7e-0d78e3d38ccd"
     oneAPI = "8f75cd03-7ff8-4ecb-9b8f-daf728133b1b"
 
-[[deps.MLDataPattern]]
-deps = ["LearnBase", "MLLabelUtils", "Random", "SparseArrays", "StatsBase"]
-git-tree-sha1 = "e99514e96e8b8129bb333c69e063a56ab6402b5b"
-uuid = "9920b226-0b2a-5f5f-9153-9aa70a013f8b"
-version = "0.5.4"
-
-[[deps.MLDataUtils]]
-deps = ["DataFrames", "DelimitedFiles", "LearnBase", "MLDataPattern", "MLLabelUtils", "Statistics", "StatsBase"]
-git-tree-sha1 = "ee54803aea12b9c8ee972e78ece11ac6023715e6"
-uuid = "cc2ba9b6-d476-5e6d-8eaf-a92d5412d41d"
-version = "0.5.4"
-
 [[deps.MLJModelInterface]]
 deps = ["InteractiveUtils", "REPL", "Random", "ScientificTypesBase", "StatisticalTraits"]
 git-tree-sha1 = "c275fae2e693206b4527dd9d2382aa15359ef3ed"
 uuid = "e80e1ace-859a-464e-9ed9-23947d8ae3ea"
 version = "1.12.1"
 
-[[deps.MLLabelUtils]]
-deps = ["LearnBase", "MappedArrays", "StatsBase"]
-git-tree-sha1 = "fd75d4b0c4016e047bbb6263eecf7ae3891af522"
-uuid = "66a33bbf-0c2b-5fc8-a008-9da813334f0a"
-version = "0.5.7"
-
 [[deps.MLStyle]]
 git-tree-sha1 = "bc38dff0548128765760c79eb7388a4b37fae2c8"
 uuid = "d8e11817-5142-5d16-987a-aa16d5891078"
@@ -2078,16 +1930,6 @@ deps = ["Base64"]
 uuid = "d6f4376e-aef5-505a-96c1-9c027394607a"
 version = "1.11.0"
 
-[[deps.MatrixFactorizations]]
-deps = ["ArrayLayouts", "LinearAlgebra", "Printf", "Random"]
-git-tree-sha1 = "3bb3cf4685f1c90f22883f4c4bb6d203fa882b79"
-uuid = "a3b82374-2e81-5b9e-98ce-41277c0e4c87"
-version = "3.1.3"
-weakdeps = ["BandedMatrices"]
-
-    [deps.MatrixFactorizations.extensions]
-    MatrixFactorizationsBandedMatricesExt = "BandedMatrices"
-
 [[deps.MaybeInplace]]
 deps = ["ArrayInterface", "LinearAlgebra", "MacroTools"]
 git-tree-sha1 = "54e2fdc38130c05b42be423e90da3bade29b74bd"
@@ -2100,9 +1942,9 @@ weakdeps = ["SparseArrays"]
 
 [[deps.MbedTLS]]
 deps = ["Dates", "MbedTLS_jll", "MozillaCACerts_jll", "NetworkOptions", "Random", "Sockets"]
-git-tree-sha1 = "c067a280ddc25f196b5e7df3877c6b226d390aaf"
+git-tree-sha1 = "8785729fa736197687541f7053f6d8ab7fc44f92"
 uuid = "739be429-bea8-5141-9913-cc70e7f3736d"
-version = "1.1.9"
+version = "1.1.10"
 
 [[deps.MbedTLS_jll]]
 deps = ["Artifacts", "Libdl"]
@@ -2142,14 +1984,15 @@ uuid = "78c3b35d-d492-501b-9361-3d52fe80e533"
 version = "0.8.1"
 
 [[deps.Mooncake]]
-deps = ["ADTypes", "ChainRules", "ChainRulesCore", "DispatchDoctor", "ExprTools", "Graphs", "LinearAlgebra", "MistyClosures", "Random", "Test"]
-git-tree-sha1 = "d49f255b638014e78affde6aa8be08ef282548e3"
+deps = ["ADTypes", "ChainRules", "ChainRulesCore", "DispatchDoctor", "ExprTools", "Graphs", "LinearAlgebra", "MistyClosures", "PrecompileTools", "Random", "Test"]
+git-tree-sha1 = "bf6df81be03543cd072367880d729a331c5048a5"
 uuid = "da2b9cff-9c12-43a0-ae48-6db2b0edb7d6"
-version = "0.4.203"
+version = "0.5.17"
 
     [deps.Mooncake.extensions]
     MooncakeAllocCheckExt = "AllocCheck"
     MooncakeCUDAExt = "CUDA"
+    MooncakeDistributionsExt = "Distributions"
     MooncakeDynamicExpressionsExt = "DynamicExpressions"
     MooncakeFluxExt = "Flux"
     MooncakeFunctionWrappersExt = "FunctionWrappers"
@@ -2163,6 +2006,7 @@ version = "0.4.203"
     [deps.Mooncake.weakdeps]
     AllocCheck = "9b6a8646-10ed-4001-bbdc-1d2f46dfbb1a"
     CUDA = "052768ef-5323-5732-b1bb-66c8b64840ba"
+    Distributions = "31c24e10-a181-5473-b8eb-7969acd0382f"
     DynamicExpressions = "a40a106e-89c9-4ca8-8020-a735e8728b6b"
     Flux = "587475ba-b771-5e3f-ad9e-33799f191a9c"
     FunctionWrappers = "069b7b12-0de2-55c6-9aab-29f3d0a68a2e"
@@ -2193,9 +2037,9 @@ version = "0.2.4"
 
 [[deps.MultivariateStats]]
 deps = ["Arpack", "Distributions", "LinearAlgebra", "SparseArrays", "Statistics", "StatsAPI", "StatsBase"]
-git-tree-sha1 = "816620e3aac93e5b5359e4fdaf23ca4525b00ddf"
+git-tree-sha1 = "7c3ff68a904d0f7404e5d2f7f5bc667934d8d616"
 uuid = "6f286f6a-111f-5878-ab1e-185364afe411"
-version = "0.10.3"
+version = "0.10.4"
 
 [[deps.NLSolversBase]]
 deps = ["ADTypes", "DifferentiationInterface", "FiniteDiff", "LinearAlgebra"]
@@ -2259,12 +2103,6 @@ git-tree-sha1 = "1a0fa0e9613f46c9b8c11eee38ebb4f590013c5e"
 uuid = "71a1bf82-56d0-4bbc-8a3c-48b961074391"
 version = "0.1.5"
 
-[[deps.NamedArrays]]
-deps = ["Combinatorics", "DelimitedFiles", "InvertedIndices", "LinearAlgebra", "OrderedCollections", "Random", "Requires", "SparseArrays", "Statistics"]
-git-tree-sha1 = "33d258318d9e049d26c02ca31b4843b2c851c0b0"
-uuid = "86f7a689-2022-50b4-a561-43c23ac3c673"
-version = "0.10.5"
-
 [[deps.NaturalSort]]
 git-tree-sha1 = "eda490d06b9f7c00752ee81cfa451efe55521e21"
 uuid = "c020b1a1-e9b0-503a-9c33-f039bfc54a85"
@@ -2282,9 +2120,9 @@ version = "1.2.0"
 
 [[deps.NonlinearSolve]]
 deps = ["ADTypes", "ArrayInterface", "BracketingNonlinearSolve", "CommonSolve", "ConcreteStructs", "DifferentiationInterface", "FastClosures", "FiniteDiff", "ForwardDiff", "LineSearch", "LinearAlgebra", "LinearSolve", "NonlinearSolveBase", "NonlinearSolveFirstOrder", "NonlinearSolveQuasiNewton", "NonlinearSolveSpectralMethods", "PrecompileTools", "Preferences", "Reexport", "SciMLBase", "SciMLLogging", "SimpleNonlinearSolve", "StaticArraysCore", "SymbolicIndexingInterface"]
-git-tree-sha1 = "da41d5cd90c1118f5a8914392cf561263a1d09cb"
+git-tree-sha1 = "d27bcf0cebf8786edcc2eaa4455c959e680334e7"
 uuid = "8913a72c-1f9b-4ce2-8d82-65094dcecaec"
-version = "4.15.0"
+version = "4.16.0"
 
     [deps.NonlinearSolve.extensions]
     NonlinearSolveFastLevenbergMarquardtExt = "FastLevenbergMarquardt"
@@ -2314,11 +2152,10 @@ version = "4.15.0"
     Sundials = "c3572dad-4567-51f8-b174-8c6c989267f4"
 
 [[deps.NonlinearSolveBase]]
-deps = ["ADTypes", "Adapt", "ArrayInterface", "CommonSolve", "Compat", "ConcreteStructs", "DifferentiationInterface", "EnzymeCore", "FastClosures", "LinearAlgebra", "Markdown", "MaybeInplace", "Preferences", "Printf", "RecursiveArrayTools", "SciMLBase", "SciMLJacobianOperators", "SciMLLogging", "SciMLOperators", "SciMLStructures", "Setfield", "StaticArraysCore", "SymbolicIndexingInterface", "TimerOutputs"]
-git-tree-sha1 = "9323e063ce69851b28e5c96539b2e2024f9a7e4c"
+deps = ["ADTypes", "Adapt", "ArrayInterface", "CommonSolve", "Compat", "ConcreteStructs", "DifferentiationInterface", "EnzymeCore", "FastClosures", "LinearAlgebra", "LogExpFunctions", "Markdown", "MaybeInplace", "PreallocationTools", "Preferences", "Printf", "RecursiveArrayTools", "SciMLBase", "SciMLJacobianOperators", "SciMLLogging", "SciMLOperators", "SciMLStructures", "Setfield", "StaticArraysCore", "SymbolicIndexingInterface", "TimerOutputs"]
+git-tree-sha1 = "4f595a0977d6e048fa1e3c382b088b950f8c7934"
 uuid = "be0214bd-f91f-a760-ac4e-3421ce2b2da0"
-version = "2.11.2"
-weakdeps = ["BandedMatrices", "ChainRulesCore", "Enzyme", "ForwardDiff", "LineSearch", "LinearSolve", "Mooncake", "ReverseDiff", "SparseArrays", "SparseMatrixColorings", "Tracker"]
+version = "2.15.0"
 
     [deps.NonlinearSolveBase.extensions]
     NonlinearSolveBaseBandedMatricesExt = "BandedMatrices"
@@ -2333,11 +2170,24 @@ weakdeps = ["BandedMatrices", "ChainRulesCore", "Enzyme", "ForwardDiff", "LineSe
     NonlinearSolveBaseSparseMatrixColoringsExt = "SparseMatrixColorings"
     NonlinearSolveBaseTrackerExt = "Tracker"
 
+    [deps.NonlinearSolveBase.weakdeps]
+    BandedMatrices = "aae01518-5342-5314-be14-df237901396f"
+    ChainRulesCore = "d360d2e6-b24c-11e9-a2a3-2a2ae2dbcce4"
+    Enzyme = "7da242da-08ed-463a-9acd-ee780be4f1d9"
+    ForwardDiff = "f6369f11-7733-5829-9624-2563aa707210"
+    LineSearch = "87fe0de2-c867-4266-b59a-2f0a94fc965b"
+    LinearSolve = "7ed4a6bd-45f5-4d41-b270-4a48e9bafcae"
+    Mooncake = "da2b9cff-9c12-43a0-ae48-6db2b0edb7d6"
+    ReverseDiff = "37e2e3b7-166d-5795-8a7a-e32c996b4267"
+    SparseArrays = "2f01184e-e22b-5df5-ae63-d93ebab69eaf"
+    SparseMatrixColorings = "0a514795-09f3-496d-8182-132a7b665d35"
+    Tracker = "9f7883ad-71c0-57eb-9f7f-b5c9e6d3789c"
+
 [[deps.NonlinearSolveFirstOrder]]
 deps = ["ADTypes", "ArrayInterface", "CommonSolve", "ConcreteStructs", "FiniteDiff", "ForwardDiff", "LineSearch", "LinearAlgebra", "LinearSolve", "MaybeInplace", "NonlinearSolveBase", "PrecompileTools", "Reexport", "SciMLBase", "SciMLJacobianOperators", "Setfield", "StaticArraysCore"]
-git-tree-sha1 = "df31d105d8e7254447256a44606f2a7e98b61aba"
+git-tree-sha1 = "eea7cbe389b168c77df7ff779fb7277019c685c8"
 uuid = "5959db7a-ea39-4486-b5fe-2dd0bf03d60d"
-version = "1.11.1"
+version = "2.0.0"
 
 [[deps.NonlinearSolveQuasiNewton]]
 deps = ["ArrayInterface", "CommonSolve", "ConcreteStructs", "LinearAlgebra", "LinearSolve", "MaybeInplace", "NonlinearSolveBase", "PrecompileTools", "Reexport", "SciMLBase", "SciMLOperators", "StaticArraysCore"]
@@ -2385,12 +2235,6 @@ git-tree-sha1 = "b6aa4566bb7ae78498a5e68943863fa8b5231b59"
 uuid = "e7412a2a-1a6e-54c0-be00-318e2571c051"
 version = "1.3.6+0"
 
-[[deps.OpenBLAS32_jll]]
-deps = ["Artifacts", "CompilerSupportLibraries_jll", "JLLWrappers", "Libdl"]
-git-tree-sha1 = "46cce8b42186882811da4ce1f4c7208b02deb716"
-uuid = "656ef2d0-ae68-5445-9ca0-591084a874a2"
-version = "0.3.30+0"
-
 [[deps.OpenBLAS_jll]]
 deps = ["Artifacts", "CompilerSupportLibraries_jll", "Libdl"]
 uuid = "4536629a-c528-5b80-bd46-f80d51c5b363"
@@ -2421,9 +2265,9 @@ version = "0.5.6+0"
 
 [[deps.Optim]]
 deps = ["ADTypes", "EnumX", "FillArrays", "LineSearches", "LinearAlgebra", "NLSolversBase", "NaNMath", "PositiveFactorizations", "Printf", "SparseArrays", "Statistics"]
-git-tree-sha1 = "e4f98846b70ef55e111ac8c40add135256c0cc47"
+git-tree-sha1 = "7957b66b4e80f1031417197099f35273f7dd93dd"
 uuid = "429524aa-4258-5aef-a3af-852621145aeb"
-version = "2.0.0"
+version = "2.0.1"
 
     [deps.Optim.extensions]
     OptimMOIExt = "MathOptInterface"
@@ -2449,15 +2293,15 @@ version = "0.4.7"
 
 [[deps.Optimization]]
 deps = ["ADTypes", "ArrayInterface", "ConsoleProgressMonitor", "DocStringExtensions", "LinearAlgebra", "Logging", "LoggingExtras", "OptimizationBase", "Printf", "Reexport", "SciMLBase", "SparseArrays", "TerminalLoggers"]
-git-tree-sha1 = "166ff0e9c44c45f26113fef6971b8783d7ce7998"
+git-tree-sha1 = "2c409c814c2d745620fdd55391a66ee514561146"
 uuid = "7f7a1694-90dd-40f0-9382-eb1efda571ba"
-version = "5.4.0"
+version = "5.5.0"
 
 [[deps.OptimizationBase]]
-deps = ["ADTypes", "ArrayInterface", "DifferentiationInterface", "DocStringExtensions", "FastClosures", "LinearAlgebra", "PDMats", "PrecompileTools", "Reexport", "SciMLBase", "SparseArrays", "SparseConnectivityTracer", "SparseMatrixColorings"]
-git-tree-sha1 = "9d1129ecde9f1773521196bdb2c5f16170bb2f6c"
+deps = ["ADTypes", "ArrayInterface", "DifferentiationInterface", "DocStringExtensions", "FastClosures", "LinearAlgebra", "PDMats", "PrecompileTools", "Reexport", "SciMLBase", "SciMLLogging", "SparseArrays", "SparseConnectivityTracer", "SparseMatrixColorings"]
+git-tree-sha1 = "710cce5771c03bf11e133bc4353c342acdf7cc29"
 uuid = "bca83a33-5cc9-4baa-983d-23429ab6bcbb"
-version = "4.2.0"
+version = "5.0.0"
 
     [deps.OptimizationBase.extensions]
     OptimizationEnzymeExt = "Enzyme"
@@ -2481,15 +2325,15 @@ version = "4.2.0"
 
 [[deps.OptimizationNLopt]]
 deps = ["NLopt", "OptimizationBase", "Random", "Reexport", "SciMLBase"]
-git-tree-sha1 = "8354392af1d62b7c3ac28a33094b1e8338364843"
+git-tree-sha1 = "127bbb0ed9968f8d93a73d60ff7eaaa48947726c"
 uuid = "4e6fcdb7-1186-4e1f-a706-475e75c168bb"
-version = "0.3.8"
+version = "0.3.9"
 
 [[deps.OptimizationOptimJL]]
 deps = ["Optim", "OptimizationBase", "Reexport", "SciMLBase", "SparseArrays"]
-git-tree-sha1 = "dffc6cc3dbe32eb370e297e332153198aa4a201c"
+git-tree-sha1 = "615ffed7e1e032fd000aabb5046dc4c976a4afca"
 uuid = "36348300-93cb-4f02-beb5-3c3902f8871e"
-version = "0.4.9"
+version = "0.4.10"
 
 [[deps.Opus_jll]]
 deps = ["Artifacts", "JLLWrappers", "Libdl"]
@@ -2504,44 +2348,44 @@ version = "1.8.1"
 
 [[deps.OrdinaryDiffEq]]
 deps = ["ADTypes", "Adapt", "ArrayInterface", "CommonSolve", "DataStructures", "DiffEqBase", "DocStringExtensions", "EnumX", "ExponentialUtilities", "FastBroadcast", "FastClosures", "FillArrays", "FiniteDiff", "ForwardDiff", "FunctionWrappersWrappers", "InteractiveUtils", "LineSearches", "LinearAlgebra", "LinearSolve", "Logging", "MacroTools", "MuladdMacro", "NonlinearSolve", "OrdinaryDiffEqAdamsBashforthMoulton", "OrdinaryDiffEqBDF", "OrdinaryDiffEqCore", "OrdinaryDiffEqDefault", "OrdinaryDiffEqDifferentiation", "OrdinaryDiffEqExplicitRK", "OrdinaryDiffEqExponentialRK", "OrdinaryDiffEqExtrapolation", "OrdinaryDiffEqFIRK", "OrdinaryDiffEqFeagin", "OrdinaryDiffEqFunctionMap", "OrdinaryDiffEqHighOrderRK", "OrdinaryDiffEqIMEXMultistep", "OrdinaryDiffEqLinear", "OrdinaryDiffEqLowOrderRK", "OrdinaryDiffEqLowStorageRK", "OrdinaryDiffEqNonlinearSolve", "OrdinaryDiffEqNordsieck", "OrdinaryDiffEqPDIRK", "OrdinaryDiffEqPRK", "OrdinaryDiffEqQPRK", "OrdinaryDiffEqRKN", "OrdinaryDiffEqRosenbrock", "OrdinaryDiffEqSDIRK", "OrdinaryDiffEqSSPRK", "OrdinaryDiffEqStabilizedIRK", "OrdinaryDiffEqStabilizedRK", "OrdinaryDiffEqSymplecticRK", "OrdinaryDiffEqTsit5", "OrdinaryDiffEqVerner", "Polyester", "PreallocationTools", "PrecompileTools", "Preferences", "RecursiveArrayTools", "Reexport", "SciMLBase", "SciMLOperators", "SciMLStructures", "SimpleNonlinearSolve", "SparseArrays", "Static", "StaticArrayInterface", "StaticArrays", "TruncatedStacktraces"]
-git-tree-sha1 = "00c0f2ce8fba6b7edd8847875043a28c1e6ec6cb"
+git-tree-sha1 = "924e1db15095c7df6b844231c00c40d756a7553d"
 uuid = "1dea7af3-3e70-54e6-95c3-0bf5283fa5ed"
-version = "6.105.0"
+version = "6.108.0"
 
 [[deps.OrdinaryDiffEqAdamsBashforthMoulton]]
 deps = ["DiffEqBase", "FastBroadcast", "MuladdMacro", "OrdinaryDiffEqCore", "OrdinaryDiffEqLowOrderRK", "Polyester", "RecursiveArrayTools", "Reexport", "SciMLBase", "Static"]
-git-tree-sha1 = "b772f64c6551ab208211201deb5982efee6aa1ea"
+git-tree-sha1 = "8307937159c3aeec5f19f4b661d82d96d25a3ff1"
 uuid = "89bda076-bce5-4f1c-845f-551c83cdda9a"
-version = "1.8.0"
+version = "1.9.0"
 
 [[deps.OrdinaryDiffEqBDF]]
 deps = ["ADTypes", "ArrayInterface", "DiffEqBase", "FastBroadcast", "LinearAlgebra", "MacroTools", "MuladdMacro", "OrdinaryDiffEqCore", "OrdinaryDiffEqDifferentiation", "OrdinaryDiffEqNonlinearSolve", "OrdinaryDiffEqSDIRK", "PrecompileTools", "Preferences", "RecursiveArrayTools", "Reexport", "SciMLBase", "StaticArrays", "TruncatedStacktraces"]
-git-tree-sha1 = "19d7750f7e6df1a04e314ba1c340a3c3e79d0c00"
+git-tree-sha1 = "22b0c4f7939af140b7f7f4ce2cce90d9f72fa515"
 uuid = "6ad6398a-0878-4a85-9266-38940aa047c8"
-version = "1.13.0"
+version = "1.22.0"
 
 [[deps.OrdinaryDiffEqCore]]
-deps = ["ADTypes", "Accessors", "Adapt", "ArrayInterface", "DataStructures", "DiffEqBase", "DocStringExtensions", "EnumX", "FastBroadcast", "FastClosures", "FastPower", "FillArrays", "FunctionWrappersWrappers", "InteractiveUtils", "LinearAlgebra", "Logging", "MacroTools", "MuladdMacro", "Polyester", "PrecompileTools", "Preferences", "RecursiveArrayTools", "Reexport", "SciMLBase", "SciMLOperators", "SciMLStructures", "Static", "StaticArrayInterface", "StaticArraysCore", "SymbolicIndexingInterface", "TruncatedStacktraces"]
-git-tree-sha1 = "c1e91924e46c76e8312d60352cd3e6e2ed8eb785"
+deps = ["ADTypes", "Accessors", "Adapt", "ArrayInterface", "ConcreteStructs", "DataStructures", "DiffEqBase", "DocStringExtensions", "EnumX", "EnzymeCore", "FastBroadcast", "FastClosures", "FastPower", "FillArrays", "FunctionWrappersWrappers", "InteractiveUtils", "LinearAlgebra", "Logging", "MacroTools", "MuladdMacro", "Polyester", "PrecompileTools", "Preferences", "Random", "RecursiveArrayTools", "Reexport", "SciMLBase", "SciMLLogging", "SciMLOperators", "SciMLStructures", "Static", "StaticArrayInterface", "StaticArraysCore", "SymbolicIndexingInterface", "TruncatedStacktraces"]
+git-tree-sha1 = "e051c1fb69b1cb1511a00161b97e7a79e0b70687"
 uuid = "bbf590c4-e513-4bbe-9b18-05decba2e5d8"
-version = "2.3.0"
-weakdeps = ["EnzymeCore", "Mooncake"]
+version = "3.17.0"
+weakdeps = ["Mooncake", "SparseArrays"]
 
     [deps.OrdinaryDiffEqCore.extensions]
-    OrdinaryDiffEqCoreEnzymeCoreExt = "EnzymeCore"
     OrdinaryDiffEqCoreMooncakeExt = "Mooncake"
+    OrdinaryDiffEqCoreSparseArraysExt = "SparseArrays"
 
 [[deps.OrdinaryDiffEqDefault]]
 deps = ["ADTypes", "DiffEqBase", "EnumX", "LinearAlgebra", "LinearSolve", "OrdinaryDiffEqBDF", "OrdinaryDiffEqCore", "OrdinaryDiffEqRosenbrock", "OrdinaryDiffEqTsit5", "OrdinaryDiffEqVerner", "PrecompileTools", "Preferences", "Reexport", "SciMLBase"]
-git-tree-sha1 = "54ddfad5e465b739a3e562de4622ce56c20bf38b"
+git-tree-sha1 = "0f40d969dd10d1b226c864bf7dc4b4b8933bc130"
 uuid = "50262376-6c5a-4cf5-baba-aaf4f84d72d7"
-version = "1.11.0"
+version = "1.13.0"
 
 [[deps.OrdinaryDiffEqDifferentiation]]
 deps = ["ADTypes", "ArrayInterface", "ConcreteStructs", "ConstructionBase", "DiffEqBase", "DifferentiationInterface", "FastBroadcast", "FiniteDiff", "ForwardDiff", "FunctionWrappersWrappers", "LinearAlgebra", "LinearSolve", "OrdinaryDiffEqCore", "SciMLBase", "SciMLOperators", "SparseMatrixColorings", "StaticArrayInterface", "StaticArrays"]
-git-tree-sha1 = "9ac7607971bf66b6443bb2ce22dd602846ed1b68"
+git-tree-sha1 = "c85968ea296acaff5de6ed0d9b64ddb00f4ea01f"
 uuid = "4302a76b-040a-498a-8c04-15b101fed76b"
-version = "1.21.0"
+version = "2.2.1"
 weakdeps = ["SparseArrays"]
 
     [deps.OrdinaryDiffEqDifferentiation.extensions]
@@ -2549,153 +2393,153 @@ weakdeps = ["SparseArrays"]
 
 [[deps.OrdinaryDiffEqExplicitRK]]
 deps = ["DiffEqBase", "FastBroadcast", "LinearAlgebra", "MuladdMacro", "OrdinaryDiffEqCore", "RecursiveArrayTools", "Reexport", "SciMLBase", "TruncatedStacktraces"]
-git-tree-sha1 = "f3344e1711d20d80c29692658f4f8ee3bd79a1f0"
+git-tree-sha1 = "c5b900878b088776b8d1bd5a7b1d94e301e21c4e"
 uuid = "9286f039-9fbf-40e8-bf65-aa933bdc4db0"
-version = "1.7.0"
+version = "1.9.0"
 
 [[deps.OrdinaryDiffEqExponentialRK]]
 deps = ["ADTypes", "DiffEqBase", "ExponentialUtilities", "FastBroadcast", "LinearAlgebra", "MuladdMacro", "OrdinaryDiffEqCore", "OrdinaryDiffEqDifferentiation", "RecursiveArrayTools", "Reexport", "SciMLBase"]
-git-tree-sha1 = "24a43208f358e45eea6596a884fb821fd9d993f0"
+git-tree-sha1 = "72156f954b199ff23dada0e8c0f12c44503b5cf9"
 uuid = "e0540318-69ee-4070-8777-9e2de6de23de"
-version = "1.11.0"
+version = "1.13.0"
 
 [[deps.OrdinaryDiffEqExtrapolation]]
 deps = ["ADTypes", "DiffEqBase", "FastBroadcast", "FastPower", "LinearSolve", "MuladdMacro", "OrdinaryDiffEqCore", "OrdinaryDiffEqDifferentiation", "Polyester", "RecursiveArrayTools", "Reexport", "SciMLBase"]
-git-tree-sha1 = "de3cb37ab28447e1b4662c12f617f5e899c4cd83"
+git-tree-sha1 = "129730b7b6cb60cc9c18e0db5861f4a7ed2c30b9"
 uuid = "becaefa8-8ca2-5cf9-886d-c06f3d2bd2c4"
-version = "1.12.0"
+version = "1.16.0"
 
 [[deps.OrdinaryDiffEqFIRK]]
 deps = ["ADTypes", "DiffEqBase", "FastBroadcast", "FastGaussQuadrature", "FastPower", "LinearAlgebra", "LinearSolve", "MuladdMacro", "OrdinaryDiffEqCore", "OrdinaryDiffEqDifferentiation", "OrdinaryDiffEqNonlinearSolve", "Polyester", "RecursiveArrayTools", "Reexport", "SciMLBase", "SciMLOperators"]
-git-tree-sha1 = "2bbb98c0674767468258bf4f05f79237f3fe8e1f"
+git-tree-sha1 = "342c716e0c15ab44203f68a78f98800ec560df82"
 uuid = "5960d6e9-dd7a-4743-88e7-cf307b64f125"
-version = "1.19.0"
+version = "1.23.0"
 
 [[deps.OrdinaryDiffEqFeagin]]
 deps = ["DiffEqBase", "FastBroadcast", "MuladdMacro", "OrdinaryDiffEqCore", "Polyester", "RecursiveArrayTools", "Reexport", "SciMLBase", "Static"]
-git-tree-sha1 = "9193f89b37f3bda1fd5979fdebf8f5d768ecf50a"
+git-tree-sha1 = "b123f64a8635a712ceb037a7d2ffe2a1875325d3"
 uuid = "101fe9f7-ebb6-4678-b671-3a81e7194747"
-version = "1.7.0"
+version = "1.8.0"
 
 [[deps.OrdinaryDiffEqFunctionMap]]
 deps = ["DiffEqBase", "FastBroadcast", "MuladdMacro", "OrdinaryDiffEqCore", "RecursiveArrayTools", "Reexport", "SciMLBase", "Static"]
-git-tree-sha1 = "7f6567109b48bafe14d1032adeecf2f387dccf42"
+git-tree-sha1 = "cbd291508808caf10cf455f974c2025e886ed2a3"
 uuid = "d3585ca7-f5d3-4ba6-8057-292ed1abd90f"
-version = "1.8.0"
+version = "1.9.0"
 
 [[deps.OrdinaryDiffEqHighOrderRK]]
 deps = ["DiffEqBase", "FastBroadcast", "MuladdMacro", "OrdinaryDiffEqCore", "RecursiveArrayTools", "Reexport", "SciMLBase", "Static"]
-git-tree-sha1 = "1504b92b5efe7f27b2d50470363238eecb8082bf"
+git-tree-sha1 = "9584dcc90cf10216de7aa0f2a1edc0f54d254cf6"
 uuid = "d28bc4f8-55e1-4f49-af69-84c1a99f0f58"
-version = "1.8.0"
+version = "1.9.0"
 
 [[deps.OrdinaryDiffEqIMEXMultistep]]
 deps = ["ADTypes", "DiffEqBase", "FastBroadcast", "OrdinaryDiffEqCore", "OrdinaryDiffEqDifferentiation", "OrdinaryDiffEqNonlinearSolve", "Reexport", "SciMLBase"]
-git-tree-sha1 = "3b75f3f7e47e094f20a0fe76569c1a30f94088a1"
+git-tree-sha1 = "9280abaf9ac36d60dd774113f7ce8a7f826d6e2e"
 uuid = "9f002381-b378-40b7-97a6-27a27c83f129"
-version = "1.10.0"
+version = "1.12.0"
 
 [[deps.OrdinaryDiffEqLinear]]
 deps = ["DiffEqBase", "ExponentialUtilities", "LinearAlgebra", "OrdinaryDiffEqCore", "RecursiveArrayTools", "Reexport", "SciMLBase", "SciMLOperators"]
-git-tree-sha1 = "caf51563014bc4c058c7f4893f4e539642d6e903"
+git-tree-sha1 = "c92913fa5942ed9bc748f3e79a5c693c8ec0c3d7"
 uuid = "521117fe-8c41-49f8-b3b6-30780b3f0fb5"
-version = "1.9.0"
+version = "1.10.0"
 
 [[deps.OrdinaryDiffEqLowOrderRK]]
 deps = ["DiffEqBase", "FastBroadcast", "LinearAlgebra", "MuladdMacro", "OrdinaryDiffEqCore", "RecursiveArrayTools", "Reexport", "SciMLBase", "Static"]
-git-tree-sha1 = "6672802d50aad826fee6e19357463307f5d35805"
+git-tree-sha1 = "78223e34d4988070443465cd3f2bdc38d6bd14b0"
 uuid = "1344f307-1e59-4825-a18e-ace9aa3fa4c6"
-version = "1.9.0"
+version = "1.10.0"
 
 [[deps.OrdinaryDiffEqLowStorageRK]]
 deps = ["Adapt", "DiffEqBase", "FastBroadcast", "MuladdMacro", "OrdinaryDiffEqCore", "Polyester", "PrecompileTools", "Preferences", "RecursiveArrayTools", "Reexport", "SciMLBase", "Static", "StaticArrays"]
-git-tree-sha1 = "a3b1a6b9fef66dcc38aacae6891870af4a512a32"
+git-tree-sha1 = "bd032c73716bc538033af041ca8903df6c813bfd"
 uuid = "b0944070-b475-4768-8dec-fb6eb410534d"
-version = "1.10.0"
+version = "1.12.0"
 
 [[deps.OrdinaryDiffEqNonlinearSolve]]
 deps = ["ADTypes", "ArrayInterface", "DiffEqBase", "FastBroadcast", "FastClosures", "ForwardDiff", "LinearAlgebra", "LinearSolve", "MuladdMacro", "NonlinearSolve", "OrdinaryDiffEqCore", "OrdinaryDiffEqDifferentiation", "PreallocationTools", "RecursiveArrayTools", "SciMLBase", "SciMLOperators", "SciMLStructures", "SimpleNonlinearSolve", "SparseArrays", "StaticArrays"]
-git-tree-sha1 = "1a724ba7bc219cc282e7dee9087a16b8778db50c"
+git-tree-sha1 = "a75727e93ffef0f0bc408372988f7bc0767b1781"
 uuid = "127b3ac7-2247-4354-8eb6-78cf4e7c58e8"
-version = "1.18.1"
+version = "1.23.0"
 
 [[deps.OrdinaryDiffEqNordsieck]]
 deps = ["DiffEqBase", "FastBroadcast", "LinearAlgebra", "MuladdMacro", "OrdinaryDiffEqCore", "OrdinaryDiffEqTsit5", "Polyester", "RecursiveArrayTools", "Reexport", "SciMLBase", "Static"]
-git-tree-sha1 = "5c289863b17b79b79f229e8e9a290736618f6cb6"
+git-tree-sha1 = "facea9aaf48eed5e9ba66d8b3246e51417c084d0"
 uuid = "c9986a66-5c92-4813-8696-a7ec84c806c8"
-version = "1.7.0"
+version = "1.9.0"
 
 [[deps.OrdinaryDiffEqPDIRK]]
 deps = ["ADTypes", "DiffEqBase", "FastBroadcast", "MuladdMacro", "OrdinaryDiffEqCore", "OrdinaryDiffEqDifferentiation", "OrdinaryDiffEqNonlinearSolve", "Polyester", "Reexport", "SciMLBase", "StaticArrays"]
-git-tree-sha1 = "478d3b3ca90b20b261452f92ba8dd488aa5e7ede"
+git-tree-sha1 = "c95dd60623e11464e6079b77d2ce604fb399a02d"
 uuid = "5dd0a6cf-3d4b-4314-aa06-06d4e299bc89"
-version = "1.9.0"
+version = "1.11.0"
 
 [[deps.OrdinaryDiffEqPRK]]
 deps = ["DiffEqBase", "FastBroadcast", "MuladdMacro", "OrdinaryDiffEqCore", "Polyester", "Reexport", "SciMLBase"]
-git-tree-sha1 = "b904958ddca6a572ee61bfdc0bd40766b5bbbc65"
+git-tree-sha1 = "baa77b7f874cda1f58f8c793fc7a9778e78a91c5"
 uuid = "5b33eab2-c0f1-4480-b2c3-94bc1e80bda1"
-version = "1.7.0"
+version = "1.8.0"
 
 [[deps.OrdinaryDiffEqQPRK]]
 deps = ["DiffEqBase", "FastBroadcast", "MuladdMacro", "OrdinaryDiffEqCore", "RecursiveArrayTools", "Reexport", "SciMLBase", "Static"]
-git-tree-sha1 = "13e7b0ae977195b225740044d56ccd2e3e8e2217"
+git-tree-sha1 = "9e351a8f923c843adb48945318437e051f6ee139"
 uuid = "04162be5-8125-4266-98ed-640baecc6514"
-version = "1.7.0"
+version = "1.8.0"
 
 [[deps.OrdinaryDiffEqRKN]]
 deps = ["DiffEqBase", "FastBroadcast", "MuladdMacro", "OrdinaryDiffEqCore", "Polyester", "RecursiveArrayTools", "Reexport", "SciMLBase"]
-git-tree-sha1 = "9ecb931559be1422bc92c9005f2420ace4c05d43"
+git-tree-sha1 = "b086c6d1b4153c9ff4b3f184a9ba7829413cc502"
 uuid = "af6ede74-add8-4cfd-b1df-9a4dbb109d7a"
-version = "1.8.0"
+version = "1.10.0"
 
 [[deps.OrdinaryDiffEqRosenbrock]]
 deps = ["ADTypes", "DiffEqBase", "DifferentiationInterface", "FastBroadcast", "FiniteDiff", "ForwardDiff", "LinearAlgebra", "LinearSolve", "MacroTools", "MuladdMacro", "OrdinaryDiffEqCore", "OrdinaryDiffEqDifferentiation", "Polyester", "PrecompileTools", "Preferences", "RecursiveArrayTools", "Reexport", "SciMLBase", "Static"]
-git-tree-sha1 = "210cce3ff9fa705282d268fb834c91b661bb1b5a"
+git-tree-sha1 = "f11347f3f01a5b00dae2b565e73795ee138cdc68"
 uuid = "43230ef6-c299-4910-a778-202eb28ce4ce"
-version = "1.21.0"
+version = "1.25.0"
 
 [[deps.OrdinaryDiffEqSDIRK]]
 deps = ["ADTypes", "DiffEqBase", "FastBroadcast", "LinearAlgebra", "MacroTools", "MuladdMacro", "OrdinaryDiffEqCore", "OrdinaryDiffEqDifferentiation", "OrdinaryDiffEqNonlinearSolve", "RecursiveArrayTools", "Reexport", "SciMLBase", "TruncatedStacktraces"]
-git-tree-sha1 = "4de6054187d1a92b6ce9291a4e091aa70389ec0f"
+git-tree-sha1 = "0b766d820e3b948881f1f246899de9ef3d329224"
 uuid = "2d112036-d095-4a1e-ab9a-08536f3ecdbf"
-version = "1.10.0"
+version = "1.12.0"
 
 [[deps.OrdinaryDiffEqSSPRK]]
 deps = ["DiffEqBase", "FastBroadcast", "MuladdMacro", "OrdinaryDiffEqCore", "Polyester", "PrecompileTools", "Preferences", "RecursiveArrayTools", "Reexport", "SciMLBase", "Static", "StaticArrays"]
-git-tree-sha1 = "99edf697fdca7d329841d05bf9c54bf33570c4b0"
+git-tree-sha1 = "8abc61382a0c6469aa9c3bff2d61c9925a088320"
 uuid = "669c94d9-1f4b-4b64-b377-1aa079aa2388"
-version = "1.10.0"
+version = "1.11.0"
 
 [[deps.OrdinaryDiffEqStabilizedIRK]]
 deps = ["ADTypes", "DiffEqBase", "FastBroadcast", "MuladdMacro", "OrdinaryDiffEqCore", "OrdinaryDiffEqDifferentiation", "OrdinaryDiffEqNonlinearSolve", "OrdinaryDiffEqStabilizedRK", "RecursiveArrayTools", "Reexport", "SciMLBase", "StaticArrays"]
-git-tree-sha1 = "5f287d7d64b3c16981c91588cc6bb52cf75f2074"
+git-tree-sha1 = "cf6856c731ddf9866e3e22612cce5e270f071545"
 uuid = "e3e12d00-db14-5390-b879-ac3dd2ef6296"
-version = "1.9.0"
+version = "1.11.0"
 
 [[deps.OrdinaryDiffEqStabilizedRK]]
 deps = ["DiffEqBase", "FastBroadcast", "MuladdMacro", "OrdinaryDiffEqCore", "RecursiveArrayTools", "Reexport", "SciMLBase", "StaticArrays"]
-git-tree-sha1 = "46432bb034066830e196507651e8a906ab881146"
+git-tree-sha1 = "d156a972fa7bc37bf8377d33a7d51d152e354d4c"
 uuid = "358294b1-0aab-51c3-aafe-ad5ab194a2ad"
-version = "1.7.0"
+version = "1.8.0"
 
 [[deps.OrdinaryDiffEqSymplecticRK]]
 deps = ["DiffEqBase", "FastBroadcast", "MuladdMacro", "OrdinaryDiffEqCore", "Polyester", "RecursiveArrayTools", "Reexport", "SciMLBase"]
-git-tree-sha1 = "9271773d454e86ea3ca36b0dfbfb64a50c023fa1"
+git-tree-sha1 = "9b783806fe2dc778649231cb3932cb71b63222d9"
 uuid = "fa646aed-7ef9-47eb-84c4-9443fc8cbfa8"
-version = "1.10.0"
+version = "1.11.0"
 
 [[deps.OrdinaryDiffEqTsit5]]
 deps = ["DiffEqBase", "FastBroadcast", "LinearAlgebra", "MuladdMacro", "OrdinaryDiffEqCore", "PrecompileTools", "Preferences", "RecursiveArrayTools", "Reexport", "SciMLBase", "Static", "TruncatedStacktraces"]
-git-tree-sha1 = "c15a392715a2fa459650771d73adc80c8fbfe0c1"
+git-tree-sha1 = "8be4cba85586cd2efa6c76d1792c548758610901"
 uuid = "b1df2697-797e-41e3-8120-5422d3b24e4a"
-version = "1.8.0"
+version = "1.9.0"
 
 [[deps.OrdinaryDiffEqVerner]]
 deps = ["DiffEqBase", "FastBroadcast", "LinearAlgebra", "MuladdMacro", "OrdinaryDiffEqCore", "Polyester", "PrecompileTools", "Preferences", "RecursiveArrayTools", "Reexport", "SciMLBase", "Static", "TruncatedStacktraces"]
-git-tree-sha1 = "8df1d3e545a864b4d0839b738e400fecc708f03a"
+git-tree-sha1 = "5ca5dbbfea89e14f283ce9fe2301c528ff4ec007"
 uuid = "79d7bb75-1356-48c1-b8c0-6832512096c2"
-version = "1.9.0"
+version = "1.11.0"
 
 [[deps.PCRE2_jll]]
 deps = ["Artifacts", "Libdl"]
@@ -2704,9 +2548,13 @@ version = "10.42.0+1"
 
 [[deps.PDMats]]
 deps = ["LinearAlgebra", "SparseArrays", "SuiteSparse"]
-git-tree-sha1 = "f07c06228a1c670ae4c87d1276b92c7c597fdda0"
+git-tree-sha1 = "e4cff168707d441cd6bf3ff7e4832bdf34278e4a"
 uuid = "90014a1f-27ba-587c-ab20-58faa44d9150"
-version = "0.11.35"
+version = "0.11.37"
+weakdeps = ["StatsBase"]
+
+    [deps.PDMats.extensions]
+    StatsBaseExt = "StatsBase"
 
 [[deps.PackageExtensionCompat]]
 git-tree-sha1 = "fb28e33b8a95c4cee25ce296c817d89cc2e53518"
@@ -2755,9 +2603,9 @@ version = "1.4.4"
 
 [[deps.Plots]]
 deps = ["Base64", "Contour", "Dates", "Downloads", "FFMPEG", "FixedPointNumbers", "GR", "JLFzf", "JSON", "LaTeXStrings", "Latexify", "LinearAlgebra", "Measures", "NaNMath", "Pkg", "PlotThemes", "PlotUtils", "PrecompileTools", "Printf", "REPL", "Random", "RecipesBase", "RecipesPipeline", "Reexport", "RelocatableFolders", "Requires", "Scratch", "Showoff", "SparseArrays", "Statistics", "StatsBase", "TOML", "UUIDs", "UnicodeFun", "Unzip"]
-git-tree-sha1 = "1cc8ad0762e59e713ee3ef28f9b78b2c9f4ca078"
+git-tree-sha1 = "cb20a4eacda080e517e4deb9cfb6c7c518131265"
 uuid = "91a5bcdd-55d7-5caf-9e0b-520d859cae80"
-version = "1.41.5"
+version = "1.41.6"
 
     [deps.Plots.extensions]
     FileIOExt = "FileIO"
@@ -2781,9 +2629,9 @@ version = "0.4.7"
 
 [[deps.Polyester]]
 deps = ["ArrayInterface", "BitTwiddlingConvenienceFunctions", "CPUSummary", "IfElse", "ManualMemory", "PolyesterWeave", "Static", "StaticArrayInterface", "StrideArraysCore", "ThreadingUtilities"]
-git-tree-sha1 = "6f7cd22a802094d239824c57d94c8e2d0f7cfc7d"
+git-tree-sha1 = "16bbc30b5ebea91e9ce1671adc03de2832cff552"
 uuid = "f517fe37-dbe3-4b94-8317-1923a5111588"
-version = "0.7.18"
+version = "0.7.19"
 
 [[deps.PolyesterWeave]]
 deps = ["BitTwiddlingConvenienceFunctions", "CPUSummary", "IfElse", "Static", "ThreadingUtilities"]
@@ -2805,9 +2653,9 @@ version = "0.2.4"
 
 [[deps.PreallocationTools]]
 deps = ["Adapt", "ArrayInterface", "PrecompileTools"]
-git-tree-sha1 = "c05b4c6325262152483a1ecb6c69846d2e01727b"
+git-tree-sha1 = "dc8d6bde5005a0eac05ae8faf1eceaaca166cfa4"
 uuid = "d236fae5-4411-538c-8e31-a6e3d9e00b46"
-version = "0.4.34"
+version = "1.1.2"
 weakdeps = ["ForwardDiff", "ReverseDiff", "SparseConnectivityTracer"]
 
     [deps.PreallocationTools.extensions]
@@ -2823,9 +2671,9 @@ version = "1.2.1"
 
 [[deps.Preferences]]
 deps = ["TOML"]
-git-tree-sha1 = "522f093a29b31a93e34eaea17ba055d850edea28"
+git-tree-sha1 = "8b770b60760d4451834fe79dd483e318eee709c4"
 uuid = "21216c6a-2e73-6563-6e65-726566657250"
-version = "1.5.1"
+version = "1.5.2"
 
 [[deps.PrettyPrint]]
 git-tree-sha1 = "632eb4abab3449ab30c5e1afaa874f0b98b586e4"
@@ -2834,9 +2682,15 @@ version = "0.2.0"
 
 [[deps.PrettyTables]]
 deps = ["Crayons", "LaTeXStrings", "Markdown", "PrecompileTools", "Printf", "REPL", "Reexport", "StringManipulation", "Tables"]
-git-tree-sha1 = "c5a07210bd060d6a8491b0ccdee2fa0235fc00bf"
+git-tree-sha1 = "211530a7dc76ab59087f4d4d1fc3f086fbe87594"
 uuid = "08abe8d2-0d0c-5749-adfa-8a2ac140af0d"
-version = "3.1.2"
+version = "3.2.3"
+
+    [deps.PrettyTables.extensions]
+    PrettyTablesTypstryExt = "Typstry"
+
+    [deps.PrettyTables.weakdeps]
+    Typstry = "f0ed7684-a786-439e-b1e3-3b82803b501e"
 
 [[deps.Primes]]
 deps = ["IntegerMathUtils"]
@@ -2862,33 +2716,39 @@ uuid = "92933f4c-e287-5a05-a399-4b506db050ca"
 version = "1.11.0"
 
 [[deps.PtrArrays]]
-git-tree-sha1 = "1d36ef11a9aaf1e8b74dacc6a731dd1de8fd493d"
+git-tree-sha1 = "4fbbafbc6251b883f4d2705356f3641f3652a7fe"
 uuid = "43287f4e-b6f4-7ad1-bb20-aadabca52c3d"
-version = "1.3.0"
+version = "1.4.0"
 
 [[deps.Qt6Base_jll]]
 deps = ["Artifacts", "CompilerSupportLibraries_jll", "Fontconfig_jll", "Glib_jll", "JLLWrappers", "Libdl", "Libglvnd_jll", "OpenSSL_jll", "Vulkan_Loader_jll", "Xorg_libSM_jll", "Xorg_libXext_jll", "Xorg_libXrender_jll", "Xorg_libxcb_jll", "Xorg_xcb_util_cursor_jll", "Xorg_xcb_util_image_jll", "Xorg_xcb_util_keysyms_jll", "Xorg_xcb_util_renderutil_jll", "Xorg_xcb_util_wm_jll", "Zlib_jll", "libinput_jll", "xkbcommon_jll"]
-git-tree-sha1 = "34f7e5d2861083ec7596af8b8c092531facf2192"
+git-tree-sha1 = "d7a4bff94f42208ce3cf6bc8e4e7d1d663e7ee8b"
 uuid = "c0090381-4147-56d7-9ebc-da0b1113ec56"
-version = "6.8.2+2"
+version = "6.10.2+1"
 
 [[deps.Qt6Declarative_jll]]
-deps = ["Artifacts", "JLLWrappers", "Libdl", "Qt6Base_jll", "Qt6ShaderTools_jll"]
-git-tree-sha1 = "da7adf145cce0d44e892626e647f9dcbe9cb3e10"
+deps = ["Artifacts", "JLLWrappers", "Libdl", "Qt6Base_jll", "Qt6ShaderTools_jll", "Qt6Svg_jll"]
+git-tree-sha1 = "d5b7dd0e226774cbd87e2790e34def09245c7eab"
 uuid = "629bc702-f1f5-5709-abd5-49b8460ea067"
-version = "6.8.2+1"
+version = "6.10.2+1"
 
 [[deps.Qt6ShaderTools_jll]]
 deps = ["Artifacts", "JLLWrappers", "Libdl", "Qt6Base_jll"]
-git-tree-sha1 = "9eca9fc3fe515d619ce004c83c31ffd3f85c7ccf"
+git-tree-sha1 = "4d85eedf69d875982c46643f6b4f66919d7e157b"
 uuid = "ce943373-25bb-56aa-8eca-768745ed7b5a"
-version = "6.8.2+1"
+version = "6.10.2+1"
+
+[[deps.Qt6Svg_jll]]
+deps = ["Artifacts", "JLLWrappers", "Libdl", "Qt6Base_jll"]
+git-tree-sha1 = "81587ff5ff25a4e1115ce191e36285ede0334c9d"
+uuid = "6de9746b-f93d-5813-b365-ba18ad4a9cf3"
+version = "6.10.2+0"
 
 [[deps.Qt6Wayland_jll]]
 deps = ["Artifacts", "JLLWrappers", "Libdl", "Qt6Base_jll", "Qt6Declarative_jll"]
-git-tree-sha1 = "8f528b0851b5b7025032818eb5abbeb8a736f853"
+git-tree-sha1 = "672c938b4b4e3e0169a07a5f227029d4905456f2"
 uuid = "e99dba38-086e-5de3-a5b1-6e4c66e897c3"
-version = "6.8.2+2"
+version = "6.10.2+1"
 
 [[deps.QuadGK]]
 deps = ["DataStructures", "LinearAlgebra"]
@@ -2975,9 +2835,9 @@ version = "0.6.12"
 
 [[deps.RecursiveArrayTools]]
 deps = ["Adapt", "ArrayInterface", "DocStringExtensions", "GPUArraysCore", "LinearAlgebra", "PrecompileTools", "RecipesBase", "StaticArraysCore", "SymbolicIndexingInterface"]
-git-tree-sha1 = "81750fa442cc5cb3ab1ba89b1cdf8eda543e6905"
+git-tree-sha1 = "18d2a6fd1ea9a8205cadb3a5704f8e51abdd748b"
 uuid = "731186ca-8d62-57ce-b412-fbd966d074cd"
-version = "3.47.0"
+version = "3.48.0"
 
     [deps.RecursiveArrayTools.extensions]
     RecursiveArrayToolsFastBroadcastExt = "FastBroadcast"
@@ -3050,9 +2910,9 @@ version = "0.5.1+0"
 
 [[deps.Roots]]
 deps = ["Accessors", "CommonSolve", "Printf"]
-git-tree-sha1 = "8a433b1ede5e9be9a7ba5b1cc6698daa8d718f1d"
+git-tree-sha1 = "10a488dbecb88a9679c8f357d383d7d83dcc748d"
 uuid = "f2b01f46-fcfa-551c-844a-d8ac1e96c665"
-version = "2.2.10"
+version = "2.2.13"
 
     [deps.Roots.extensions]
     RootsChainRulesCoreExt = "ChainRulesCore"
@@ -3093,9 +2953,9 @@ version = "0.6.1"
 
 [[deps.SciMLBase]]
 deps = ["ADTypes", "Accessors", "Adapt", "ArrayInterface", "CommonSolve", "ConstructionBase", "Distributed", "DocStringExtensions", "EnumX", "FunctionWrappersWrappers", "IteratorInterfaceExtensions", "LinearAlgebra", "Logging", "Markdown", "Moshi", "PreallocationTools", "PrecompileTools", "Preferences", "Printf", "RecipesBase", "RecursiveArrayTools", "Reexport", "RuntimeGeneratedFunctions", "SciMLLogging", "SciMLOperators", "SciMLPublic", "SciMLStructures", "StaticArraysCore", "Statistics", "SymbolicIndexingInterface"]
-git-tree-sha1 = "1b007ef25d4c18da29f956c2cad0a45f1c98f0f3"
+git-tree-sha1 = "4675d321bfebe190d22dc4d9de6af7e318d5174a"
 uuid = "0bca4576-84f4-4d90-8ffe-ffa030f20462"
-version = "2.136.0"
+version = "2.148.0"
 
     [deps.SciMLBase.extensions]
     SciMLBaseChainRulesCoreExt = "ChainRulesCore"
@@ -3144,9 +3004,13 @@ version = "0.1.12"
 
 [[deps.SciMLLogging]]
 deps = ["Logging", "LoggingExtras", "Preferences"]
-git-tree-sha1 = "7eebb9985e35b123e12025a3a2ad020cd6059f71"
+git-tree-sha1 = "0161be062570af4042cf6f69e3d5d0b0555b6927"
 uuid = "a6db7da4-7206-11f0-1eab-35f2a5dbe1d1"
-version = "1.8.0"
+version = "1.9.1"
+weakdeps = ["Tracy"]
+
+    [deps.SciMLLogging.extensions]
+    SciMLLoggingTracyExt = "Tracy"
 
 [[deps.SciMLOperators]]
 deps = ["Accessors", "ArrayInterface", "DocStringExtensions", "LinearAlgebra"]
@@ -3165,14 +3029,18 @@ uuid = "431bcebd-1456-4ced-9d72-93c2757fff0b"
 version = "1.0.1"
 
 [[deps.SciMLSensitivity]]
-deps = ["ADTypes", "Accessors", "Adapt", "ArrayInterface", "ChainRulesCore", "DiffEqBase", "DiffEqCallbacks", "DiffEqNoiseProcess", "Distributions", "Enzyme", "FastBroadcast", "FiniteDiff", "ForwardDiff", "FunctionProperties", "FunctionWrappersWrappers", "Functors", "GPUArraysCore", "LinearAlgebra", "LinearSolve", "Markdown", "OrdinaryDiffEqCore", "PreallocationTools", "QuadGK", "Random", "RandomNumbers", "RecursiveArrayTools", "Reexport", "ReverseDiff", "SciMLBase", "SciMLJacobianOperators", "SciMLLogging", "SciMLStructures", "StaticArrays", "StaticArraysCore", "Statistics", "SymbolicIndexingInterface", "Tracker", "Zygote"]
-git-tree-sha1 = "b099878e89bb8175aaba5d16aba703564b5bb2ed"
+deps = ["ADTypes", "Accessors", "Adapt", "ArrayInterface", "ChainRulesCore", "ConstructionBase", "DiffEqBase", "DiffEqCallbacks", "DiffEqNoiseProcess", "Distributions", "Enzyme", "FastBroadcast", "FiniteDiff", "ForwardDiff", "FunctionProperties", "FunctionWrappersWrappers", "Functors", "GPUArraysCore", "LinearAlgebra", "LinearSolve", "Markdown", "OrdinaryDiffEqCore", "PreallocationTools", "QuadGK", "Random", "RandomNumbers", "RecursiveArrayTools", "Reexport", "ReverseDiff", "SciMLBase", "SciMLJacobianOperators", "SciMLLogging", "SciMLStructures", "SparseArrays", "StaticArrays", "StaticArraysCore", "Statistics", "SymbolicIndexingInterface", "Tracker", "Zygote"]
+git-tree-sha1 = "d8861efbd815a4d461f547d9010d5ef920de5f9e"
 uuid = "1ed8b502-d754-442c-8d5d-10ac956f44a1"
-version = "7.94.0"
-weakdeps = ["Mooncake"]
+version = "7.98.1"
 
     [deps.SciMLSensitivity.extensions]
     SciMLSensitivityMooncakeExt = "Mooncake"
+    SciMLSensitivityReactantExt = "Reactant"
+
+    [deps.SciMLSensitivity.weakdeps]
+    Mooncake = "da2b9cff-9c12-43a0-ae48-6db2b0edb7d6"
+    Reactant = "3c362404-f566-11ee-1572-e11a4b42c853"
 
 [[deps.SciMLStructures]]
 deps = ["ArrayInterface", "PrecompileTools"]
@@ -3181,9 +3049,10 @@ uuid = "53ae85a6-f571-4167-b2af-e1d143709226"
 version = "1.10.0"
 
 [[deps.ScientificTypesBase]]
-git-tree-sha1 = "a8e18eb383b5ecf1b5e6fc237eb39255044fd92b"
+deps = ["InteractiveUtils"]
+git-tree-sha1 = "e785eaa35a0f5518a388f9010e66fda64ea95ede"
 uuid = "30f210dd-8aff-4c5f-94ba-8e64358c1161"
-version = "3.0.0"
+version = "3.1.0"
 
 [[deps.ScopedValues]]
 deps = ["HashArrayMappedTries", "Logging"]
@@ -3241,9 +3110,9 @@ version = "1.2.0"
 
 [[deps.SimpleNonlinearSolve]]
 deps = ["ADTypes", "ArrayInterface", "BracketingNonlinearSolve", "CommonSolve", "ConcreteStructs", "DifferentiationInterface", "FastClosures", "FiniteDiff", "ForwardDiff", "LineSearch", "LinearAlgebra", "MaybeInplace", "NonlinearSolveBase", "PrecompileTools", "Reexport", "SciMLBase", "Setfield", "StaticArraysCore"]
-git-tree-sha1 = "315da09948861edbc6d18e066c08903487bb580d"
+git-tree-sha1 = "744c3f0fb186ad28376199c1e72ca39d0c614b5d"
 uuid = "727e6d20-b764-4bd8-a329-72de5adea6c7"
-version = "2.10.0"
+version = "2.11.0"
 weakdeps = ["ChainRulesCore", "ReverseDiff", "Tracker"]
 
     [deps.SimpleNonlinearSolve.extensions]
@@ -3274,9 +3143,9 @@ version = "1.11.0"
 
 [[deps.SparseConnectivityTracer]]
 deps = ["ADTypes", "DocStringExtensions", "FillArrays", "LinearAlgebra", "Random", "SparseArrays"]
-git-tree-sha1 = "322365aa23098275562cbad6a1c2539ee40d9618"
+git-tree-sha1 = "590b72143436e443888124aaf4026a636049e3f5"
 uuid = "9f842d2f-2579-4b1d-911e-f412cf18a3f5"
-version = "1.1.3"
+version = "1.2.1"
 weakdeps = ["ChainRulesCore", "LogExpFunctions", "NNlib", "NaNMath", "SpecialFunctions"]
 
     [deps.SparseConnectivityTracer.extensions]
@@ -3294,9 +3163,9 @@ version = "0.1.2"
 
 [[deps.SparseMatrixColorings]]
 deps = ["ADTypes", "DocStringExtensions", "LinearAlgebra", "PrecompileTools", "Random", "SparseArrays"]
-git-tree-sha1 = "6ed48d9a3b22417c765dc273ae3e1e4de035e7c8"
+git-tree-sha1 = "7b2263c87aa890bf6d18ae05cedbe259754e3f34"
 uuid = "0a514795-09f3-496d-8182-132a7b665d35"
-version = "0.4.23"
+version = "0.4.24"
 
     [deps.SparseMatrixColorings.extensions]
     SparseMatrixColoringsCUDAExt = "CUDA"
@@ -3313,9 +3182,9 @@ version = "0.4.23"
 
 [[deps.SpecialFunctions]]
 deps = ["IrrationalConstants", "LogExpFunctions", "OpenLibm_jll", "OpenSpecFun_jll"]
-git-tree-sha1 = "f2685b435df2613e25fc10ad8c26dddb8640f547"
+git-tree-sha1 = "5acc6a41b3082920f79ca3c759acbcecf18a8d78"
 uuid = "276daf66-3868-5448-9aa4-cd146d93841b"
-version = "2.6.1"
+version = "2.7.1"
 weakdeps = ["ChainRulesCore"]
 
     [deps.SpecialFunctions.extensions]
@@ -3340,10 +3209,10 @@ uuid = "aedffcd0-7271-4cad-89d0-dc628f76c6d3"
 version = "1.3.1"
 
 [[deps.StaticArrayInterface]]
-deps = ["ArrayInterface", "Compat", "IfElse", "LinearAlgebra", "PrecompileTools", "Static"]
-git-tree-sha1 = "96381d50f1ce85f2663584c8e886a6ca97e60554"
+deps = ["ArrayInterface", "Compat", "IfElse", "LinearAlgebra", "PrecompileTools", "SciMLPublic", "Static"]
+git-tree-sha1 = "aa1ea41b3d45ac449d10477f65e2b40e3197a0d2"
 uuid = "0d7ed370-da01-4f52-bd93-41d350b8b718"
-version = "1.8.0"
+version = "1.9.0"
 weakdeps = ["OffsetArrays", "StaticArrays"]
 
     [deps.StaticArrayInterface.extensions]
@@ -3352,9 +3221,9 @@ weakdeps = ["OffsetArrays", "StaticArrays"]
 
 [[deps.StaticArrays]]
 deps = ["LinearAlgebra", "PrecompileTools", "Random", "StaticArraysCore"]
-git-tree-sha1 = "eee1b9ad8b29ef0d936e3ec9838c7ec089620308"
+git-tree-sha1 = "0f529006004a8be48f1be25f3451186579392d47"
 uuid = "90137ffa-7385-5640-81b9-e52037218182"
-version = "1.9.16"
+version = "1.9.17"
 weakdeps = ["ChainRulesCore", "Statistics"]
 
     [deps.StaticArrays.extensions]
@@ -3389,10 +3258,10 @@ uuid = "82ae8749-77ed-4fe6-ae5f-f523153014b0"
 version = "1.8.0"
 
 [[deps.StatsBase]]
-deps = ["DataAPI", "DataStructures", "LinearAlgebra", "LogExpFunctions", "Missings", "Printf", "Random", "SortingAlgorithms", "SparseArrays", "Statistics", "StatsAPI"]
-git-tree-sha1 = "d1bf48bfcc554a3761a133fe3a9bb01488e06916"
+deps = ["AliasTables", "DataAPI", "DataStructures", "IrrationalConstants", "LinearAlgebra", "LogExpFunctions", "Missings", "Printf", "Random", "SortingAlgorithms", "SparseArrays", "Statistics", "StatsAPI"]
+git-tree-sha1 = "aceda6f4e598d331548e04cc6b2124a6148138e3"
 uuid = "2913bbd2-ae8a-5f71-8c99-4fb6c76f3a91"
-version = "0.33.21"
+version = "0.34.10"
 
 [[deps.StatsFuns]]
 deps = ["HypergeometricFunctions", "IrrationalConstants", "LogExpFunctions", "Reexport", "Rmath", "SpecialFunctions"]
@@ -3407,9 +3276,9 @@ weakdeps = ["ChainRulesCore", "InverseFunctions"]
 
 [[deps.StatsModels]]
 deps = ["DataAPI", "DataStructures", "LinearAlgebra", "Printf", "REPL", "ShiftedArrays", "SparseArrays", "StatsAPI", "StatsBase", "StatsFuns", "Tables"]
-git-tree-sha1 = "b12d37d25a2378f01abba02591cfd39a6cc4936f"
+git-tree-sha1 = "08786db4a1346d17d0a8d952d2e66fd00fa18192"
 uuid = "3eaba693-59b7-5ba5-a881-562e759f1c8d"
-version = "0.7.8"
+version = "0.7.9"
 
 [[deps.StatsPlots]]
 deps = ["AbstractFFTs", "Clustering", "DataStructures", "Distributions", "Interpolations", "KernelDensity", "LinearAlgebra", "MultivariateStats", "NaNMath", "Observables", "Plots", "RecipesBase", "RecipesPipeline", "Reexport", "StatsBase", "TableOperations", "Tables", "Widgets"]
@@ -3417,18 +3286,6 @@ git-tree-sha1 = "88cf3587711d9ad0a55722d339a013c4c56c5bbc"
 uuid = "f3b207a7-027a-5e70-b257-86293d7955fd"
 version = "0.15.8"
 
-[[deps.SteadyStateDiffEq]]
-deps = ["ConcreteStructs", "DiffEqBase", "DiffEqCallbacks", "LinearAlgebra", "NonlinearSolveBase", "Reexport", "SciMLBase"]
-git-tree-sha1 = "7b32737ebda77355ee61cfa9e59d376de3604629"
-uuid = "9672c7b4-1e72-59bd-8a11-6ac3964bc41f"
-version = "2.9.0"
-
-[[deps.StochasticDiffEq]]
-deps = ["ADTypes", "Adapt", "ArrayInterface", "DataStructures", "DiffEqBase", "DiffEqNoiseProcess", "DocStringExtensions", "FastPower", "FiniteDiff", "ForwardDiff", "JumpProcesses", "LevyArea", "LinearAlgebra", "Logging", "MuladdMacro", "OrdinaryDiffEqCore", "OrdinaryDiffEqDifferentiation", "OrdinaryDiffEqNonlinearSolve", "Random", "RecursiveArrayTools", "Reexport", "SciMLBase", "SciMLOperators", "SimpleNonlinearSolve", "SparseArrays", "StaticArrays"]
-git-tree-sha1 = "d24537c04013ab0f6fa17c17f06594bac9ad61f2"
-uuid = "789caeaf-c7a9-5a7d-9973-96adeb23e2a0"
-version = "6.90.0"
-
 [[deps.StrideArraysCore]]
 deps = ["ArrayInterface", "CloseOpenIntervals", "IfElse", "LayoutPointers", "LinearAlgebra", "ManualMemory", "SIMDTypes", "Static", "StaticArrayInterface", "ThreadingUtilities"]
 git-tree-sha1 = "83151ba8065a73f53ca2ae98bc7274d817aa30f2"
@@ -3437,29 +3294,45 @@ version = "0.5.8"
 
 [[deps.Strided]]
 deps = ["LinearAlgebra", "StridedViews", "TupleTools"]
-git-tree-sha1 = "c2e72c33ac8871d104901db736aecb36b223f10c"
+git-tree-sha1 = "0fa01489ecc57749f2f7dcbc2918e46a164af8b2"
 uuid = "5e0ebb24-38b0-5f93-81fe-25c709ecae67"
-version = "2.3.2"
+version = "2.3.4"
+
+    [deps.Strided.extensions]
+    StridedAMDGPUExt = "AMDGPU"
+    StridedCUDAExt = "CUDA"
+    StridedGPUArraysExt = "GPUArrays"
+    StridedJLArraysExt = "JLArrays"
+
+    [deps.Strided.weakdeps]
+    AMDGPU = "21141c5a-9bdb-4563-92ae-f87d6854732e"
+    CUDA = "052768ef-5323-5732-b1bb-66c8b64840ba"
+    GPUArrays = "0c68f7d7-f131-5f86-a1c3-88cf8149b2d7"
+    JLArrays = "27aeb0d3-9eb9-45fb-866b-73c2ecf80fcb"
 
 [[deps.StridedViews]]
 deps = ["LinearAlgebra", "PackageExtensionCompat"]
-git-tree-sha1 = "e34a59ea9c7abc8f10bfd77578de9d64bded2859"
+git-tree-sha1 = "b1b42ff0249fbb02df163633adc612b943c6ac74"
 uuid = "4db3bf67-4bd7-4b4e-b153-31dc3fb37143"
-version = "0.4.3"
+version = "0.4.6"
 
     [deps.StridedViews.extensions]
+    StridedViewsAMDGPUExt = "AMDGPU"
     StridedViewsCUDAExt = "CUDA"
+    StridedViewsJLArraysExt = "JLArrays"
     StridedViewsPtrArraysExt = "PtrArrays"
 
     [deps.StridedViews.weakdeps]
+    AMDGPU = "21141c5a-9bdb-4563-92ae-f87d6854732e"
     CUDA = "052768ef-5323-5732-b1bb-66c8b64840ba"
+    JLArrays = "27aeb0d3-9eb9-45fb-866b-73c2ecf80fcb"
     PtrArrays = "43287f4e-b6f4-7ad1-bb20-aadabca52c3d"
 
 [[deps.StringManipulation]]
 deps = ["PrecompileTools"]
-git-tree-sha1 = "a3c1536470bf8c5e02096ad4853606d7c8f62721"
+git-tree-sha1 = "d05693d339e37d6ab134c5ab53c29fce5ee5d7d5"
 uuid = "892a3eda-7b42-436c-8928-eab12a02cf0e"
-version = "0.4.2"
+version = "0.4.4"
 
 [[deps.StructArrays]]
 deps = ["ConstructionBase", "DataAPI", "Tables"]
@@ -3482,9 +3355,9 @@ version = "0.3.1"
 
 [[deps.StructUtils]]
 deps = ["Dates", "UUIDs"]
-git-tree-sha1 = "9297459be9e338e546f5c4bedb59b3b5674da7f1"
+git-tree-sha1 = "28145feabf717c5d65c1d5e09747ee7b1ff3ed13"
 uuid = "ec057cc2-7a8d-4b58-b3b3-92acb9f63b42"
-version = "2.6.2"
+version = "2.6.3"
 
     [deps.StructUtils.extensions]
     StructUtilsMeasurementsExt = ["Measurements"]
@@ -3502,29 +3375,11 @@ version = "1.11.0"
 deps = ["Libdl", "LinearAlgebra", "Serialization", "SparseArrays"]
 uuid = "4607b0f0-06f3-5cda-b6b1-a6196a1729e9"
 
-[[deps.SuiteSparse32_jll]]
-deps = ["Artifacts", "JLLWrappers", "Libdl", "libblastrampoline_jll"]
-git-tree-sha1 = "1d43a4874b879f381b8a3a978f0ebe837cfd0922"
-uuid = "ca45d3f4-326b-53b0-9957-23b75aacb3f2"
-version = "7.12.1+0"
-
 [[deps.SuiteSparse_jll]]
 deps = ["Artifacts", "Libdl", "libblastrampoline_jll"]
 uuid = "bea87d4a-7f5b-5778-9afe-8cc45184846c"
 version = "7.7.0+0"
 
-[[deps.Sundials]]
-deps = ["Accessors", "ArrayInterface", "CEnum", "DataStructures", "DiffEqBase", "Libdl", "LinearAlgebra", "LinearSolve", "Logging", "NonlinearSolveBase", "PrecompileTools", "Reexport", "SciMLBase", "SparseArrays", "Sundials_jll", "SymbolicIndexingInterface"]
-git-tree-sha1 = "2d27edb89b7c555a57b8f22bfde92d6828d11cee"
-uuid = "c3572dad-4567-51f8-b174-8c6c989267f4"
-version = "5.1.0"
-
-[[deps.Sundials_jll]]
-deps = ["Artifacts", "CompilerSupportLibraries_jll", "JLLWrappers", "Libdl", "OpenBLAS32_jll", "SuiteSparse32_jll"]
-git-tree-sha1 = "a872f379c836e9cb5734485ca0681b192a59b98b"
-uuid = "fb77eaff-e24c-56d4-86b1-d163f2edb164"
-version = "7.5.0+0"
-
 [[deps.SymbolicIndexingInterface]]
 deps = ["Accessors", "ArrayInterface", "RuntimeGeneratedFunctions", "StaticArraysCore"]
 git-tree-sha1 = "94c58884e013efff548002e8dc2fdd1cb74dfce5"
@@ -3687,10 +3542,10 @@ uuid = "9d95972d-f1c8-5527-a6e0-b4b365fa01f6"
 version = "1.6.0"
 
 [[deps.Turing]]
-deps = ["ADTypes", "AbstractMCMC", "AbstractPPL", "Accessors", "AdvancedHMC", "AdvancedMH", "AdvancedPS", "AdvancedVI", "BangBang", "Bijectors", "Compat", "DataStructures", "Distributions", "DistributionsAD", "DocStringExtensions", "DynamicPPL", "EllipticalSliceSampling", "ForwardDiff", "Libtask", "LinearAlgebra", "LogDensityProblems", "MCMCChains", "NamedArrays", "Optimization", "OptimizationOptimJL", "OrderedCollections", "Printf", "Random", "Reexport", "SciMLBase", "SpecialFunctions", "Statistics", "StatsAPI", "StatsBase", "StatsFuns"]
-git-tree-sha1 = "923ba6ce1ab6b3d95f5efe1daad92369553aadfe"
+deps = ["ADTypes", "AbstractMCMC", "AbstractPPL", "Accessors", "AdvancedHMC", "AdvancedMH", "AdvancedPS", "AdvancedVI", "BangBang", "Bijectors", "Compat", "DataStructures", "DifferentiationInterface", "Distributions", "DocStringExtensions", "DynamicPPL", "EllipticalSliceSampling", "ForwardDiff", "Libtask", "LinearAlgebra", "LogDensityProblems", "MCMCChains", "Optimization", "OptimizationOptimJL", "OrderedCollections", "Printf", "Random", "Reexport", "SciMLBase", "SpecialFunctions", "Statistics", "StatsAPI", "StatsBase", "StatsFuns"]
+git-tree-sha1 = "45ddf0d7564c7723760ff22e39fde90a87cd12c5"
 uuid = "fce5fe82-541a-59a6-adf8-730c64b5f9a0"
-version = "0.42.8"
+version = "0.43.0"
 weakdeps = ["DynamicHMC"]
 
     [deps.Turing.extensions]
@@ -3805,9 +3660,9 @@ version = "1.2.6+0"
 
 [[deps.Xorg_libX11_jll]]
 deps = ["Artifacts", "JLLWrappers", "Libdl", "Xorg_libxcb_jll", "Xorg_xtrans_jll"]
-git-tree-sha1 = "b5899b25d17bf1889d25906fb9deed5da0c15b3b"
+git-tree-sha1 = "808090ede1d41644447dd5cbafced4731c56bd2f"
 uuid = "4f6342f7-b3d2-589e-9d20-edeb45f2b2bc"
-version = "1.8.12+0"
+version = "1.8.13+0"
 
 [[deps.Xorg_libXau_jll]]
 deps = ["Artifacts", "JLLWrappers", "Libdl"]
@@ -3829,9 +3684,9 @@ version = "1.1.6+0"
 
 [[deps.Xorg_libXext_jll]]
 deps = ["Artifacts", "JLLWrappers", "Libdl", "Xorg_libX11_jll"]
-git-tree-sha1 = "a4c0ee07ad36bf8bbce1c3bb52d21fb1e0b987fb"
+git-tree-sha1 = "1a4a26870bf1e5d26cd585e38038d399d7e65706"
 uuid = "1082639a-0dae-5f34-9b06-72781eeb8cb3"
-version = "1.3.7+0"
+version = "1.3.8+0"
 
 [[deps.Xorg_libXfixes_jll]]
 deps = ["Artifacts", "JLLWrappers", "Libdl", "Xorg_libX11_jll"]
@@ -3847,15 +3702,15 @@ version = "1.8.3+0"
 
 [[deps.Xorg_libXinerama_jll]]
 deps = ["Artifacts", "JLLWrappers", "Libdl", "Xorg_libXext_jll"]
-git-tree-sha1 = "a5bc75478d323358a90dc36766f3c99ba7feb024"
+git-tree-sha1 = "0ba01bc7396896a4ace8aab67db31403c71628f4"
 uuid = "d1454406-59df-5ea1-beac-c340f2130bc3"
-version = "1.1.6+0"
+version = "1.1.7+0"
 
 [[deps.Xorg_libXrandr_jll]]
 deps = ["Artifacts", "JLLWrappers", "Libdl", "Xorg_libXext_jll", "Xorg_libXrender_jll"]
-git-tree-sha1 = "aff463c82a773cb86061bce8d53a0d976854923e"
+git-tree-sha1 = "6c174ef70c96c76f4c3f4d3cfbe09d018bcd1b53"
 uuid = "ec84b674-ba8e-5d96-8ba1-2a689ba10484"
-version = "1.5.5+0"
+version = "1.5.6+0"
 
 [[deps.Xorg_libXrender_jll]]
 deps = ["Artifacts", "JLLWrappers", "Libdl", "Xorg_libX11_jll"]
@@ -3871,9 +3726,9 @@ version = "1.17.1+0"
 
 [[deps.Xorg_libxkbfile_jll]]
 deps = ["Artifacts", "JLLWrappers", "Libdl", "Xorg_libX11_jll"]
-git-tree-sha1 = "e3150c7400c41e207012b41659591f083f3ef795"
+git-tree-sha1 = "ed756a03e95fff88d8f738ebc2849431bdd4fd1a"
 uuid = "cc61e674-0454-545c-8b26-ed2c68acab7a"
-version = "1.1.3+0"
+version = "1.2.0+0"
 
 [[deps.Xorg_xcb_util_cursor_jll]]
 deps = ["Artifacts", "JLLWrappers", "Libdl", "Xorg_xcb_util_image_jll", "Xorg_xcb_util_jll", "Xorg_xcb_util_renderutil_jll"]
@@ -4019,9 +3874,9 @@ version = "1.28.1+0"
 
 [[deps.libpng_jll]]
 deps = ["Artifacts", "JLLWrappers", "Libdl", "Zlib_jll"]
-git-tree-sha1 = "6ab498eaf50e0495f89e7a5b582816e2efb95f64"
+git-tree-sha1 = "e015f211ebb898c8180887012b938f3851e719ac"
 uuid = "b53b4c65-9356-5827-b1ea-8c7a1a84506f"
-version = "1.6.54+0"
+version = "1.6.55+0"
 
 [[deps.libvorbis_jll]]
 deps = ["Artifacts", "JLLWrappers", "Libdl", "Ogg_jll"]
diff --git a/Project.toml b/Project.toml
index b13d7e2f2..790aa498a 100644
--- a/Project.toml
+++ b/Project.toml
@@ -9,7 +9,7 @@ Bijectors = "76274a88-744f-5084-9051-94815aaf08c4"
 CSV = "336ed68f-0bac-5ca0-87d4-7b16caf5d00b"
 Chairmarks = "0ca39b1e-fe0b-4e98-acfc-b1656634c4de"
 DataFrames = "a93c6f00-e57d-5684-b7b6-d8193f3e46c0"
-DifferentialEquations = "0c46a032-eb83-5123-abaf-570d42b7fbaa"
+DelayDiffEq = "bcd4f6db-9728-5f36-b5f7-82caef46ccdb"
 Distributed = "8ba89e20-285c-5b6f-9357-94700520ee1b"
 Distributions = "31c24e10-a181-5473-b8eb-7969acd0382f"
 DynamicHMC = "bbc10e6e-7c05-544b-b16e-64fede858acb"
@@ -27,15 +27,14 @@ LogExpFunctions = "2ab3a3ac-af41-5b50-aa03-7779005ae688"
 Logging = "56ddb016-857b-54e1-b83d-db4d58db5568"
 Lux = "b2108857-7c20-44ae-9111-449ecde12c47"
 MCMCChains = "c7f686f2-ff18-58e9-bc7b-31028e88f75d"
-MLDataUtils = "cc2ba9b6-d476-5e6d-8eaf-a92d5412d41d"
 MLUtils = "f1d291b0-491e-4a28-83b9-f70985020b54"
 MacroTools = "1914dd2f-81c6-5fcd-8719-6d5c9610ff09"
 Measures = "442fdcdd-2543-5da2-b0f3-8c86c306513e"
 Mooncake = "da2b9cff-9c12-43a0-ae48-6db2b0edb7d6"
-NNlib = "872c559c-99b0-510c-b3b7-b6c96a88d5cd"
 Optimisers = "3bd65402-5787-11e9-1adc-39752487f4e2"
 OptimizationNLopt = "4e6fcdb7-1186-4e1f-a706-475e75c168bb"
 OptimizationOptimJL = "36348300-93cb-4f02-beb5-3c3902f8871e"
+OrdinaryDiffEq = "1dea7af3-3e70-54e6-95c3-0bf5283fa5ed"
 PDMats = "90014a1f-27ba-587c-ab20-58faa44d9150"
 Pkg = "44cfe95a-1eb2-52ea-b672-e2afdf69b78f"
 Plots = "91a5bcdd-55d7-5caf-9e0b-520d859cae80"
@@ -51,4 +50,4 @@ StatsPlots = "f3b207a7-027a-5e70-b257-86293d7955fd"
 Turing = "fce5fe82-541a-59a6-adf8-730c64b5f9a0"
 
 [compat]
-Turing = "0.42"
+Turing = "0.43"
diff --git a/_quarto.yml b/_quarto.yml
index cb855f788..d9e4f38f7 100644
--- a/_quarto.yml
+++ b/_quarto.yml
@@ -43,7 +43,7 @@ website:
         href: https://turinglang.org/team/
     right:
       # Current version
-      - text: "v0.42"
+      - text: "v0.43"
         menu:
           - text: Changelog
             href: https://turinglang.org/docs/changelog.html
@@ -115,15 +115,9 @@ website:
           - section: "DynamicPPL's Compiler"
             collapse-level: 1
             contents:
-              - developers/compiler/model-manual/index.qmd
               - developers/compiler/minituring-compiler/index.qmd
               - developers/compiler/minituring-contexts/index.qmd
 
-          - section: "DynamicPPL Models"
-            collapse-level: 1
-            contents:
-              - developers/models/varinfo-overview/index.qmd
-
           - section: "DynamicPPL Contexts"
             collapse-level: 1
             contents:
@@ -134,7 +128,6 @@ website:
             contents:
               - developers/transforms/distributions/index.qmd
               - developers/transforms/bijectors/index.qmd
-              - developers/transforms/dynamicppl/index.qmd
 
           - section: "Inference in Detail"
             collapse-level: 1
@@ -229,6 +222,4 @@ dev-variational-inference: developers/inference/variational-inference
 using-turing-implementing-samplers: developers/inference/implementing-samplers
 dev-transforms-distributions: developers/transforms/distributions
 dev-transforms-bijectors: developers/transforms/bijectors
-dev-transforms-dynamicppl: developers/transforms/dynamicppl
 dev-contexts-submodel-condition: developers/contexts/submodel-condition
-dev-models-varinfo-overview: developers/models/varinfo-overview
diff --git a/developers/compiler/design-overview/index.qmd b/developers/compiler/design-overview/index.qmd
deleted file mode 100755
index f57a96e7f..000000000
--- a/developers/compiler/design-overview/index.qmd
+++ /dev/null
@@ -1,277 +0,0 @@
----
-title: Turing Compiler Design (Outdated)
-engine: julia
-aliases:
-  - ../../../tutorials/docs-05-for-developers-compiler/index.html
----
-
-```{julia}
-#| echo: false
-#| output: false
-using Pkg;
-Pkg.instantiate();
-```
-
-In this section, the current design of Turing's model "compiler" is described, which enables Turing to perform various types of Bayesian inference without changing the model definition. The "compiler" is essentially just a macro that rewrites the user's model definition to a function that generates a `Model` struct that Julia's dispatch can operate on and that Julia's compiler can successfully do type inference on for efficient machine code generation.
-
-# Overview
-
-The following terminology will be used in this section:
-
-  - `D`: observed data variables conditioned upon in the posterior,
-  - `P`: parameter variables distributed according to the prior distributions, these are also referred to as random variables,
-  - `Model`: a fully defined probabilistic model with input data
-
-`Turing`'s `@model` macro rewrites the user-provided function definition such that it can be used to instantiate a `Model` by passing in the observed data `D`.
-
-The following are the main jobs of the `@model` macro:
-
- 1. Parse `~` and `.~` lines, e.g. `y .~ Normal.(c*x, 1.0)`
- 2. Figure out if a variable belongs to the data `D` and/or to the parameters `P`
- 3. Enable the handling of missing data variables in `D` when defining a `Model` and treating them as parameter variables in `P` instead
- 4. Enable the tracking of random variables using the data structures `VarName` and `VarInfo`
- 5. Change `~`/`.~` lines with a variable in `P` on the LHS to a call to `tilde_assume` or `dot_tilde_assume`
- 6. Change `~`/`.~` lines with a variable in `D` on the LHS to a call to `tilde_observe` or `dot_tilde_observe`
- 7. Enable type stable automatic differentiation of the model using type parameters
-
-## The model
-
-<!-- Very outdated
-A `model::Model` is a callable struct that one can sample from by calling
-
-```{julia}
-#| eval: false
-(model::Model)([rng, varinfo, sampler, context])
-```
-
-where `rng` is a random number generator (default: `Random.default_rng()`), `varinfo` is a data structure that stores information about the random variables (default: `DynamicPPL.VarInfo()`), `sampler` is a sampling algorithm (default: `DynamicPPL.SampleFromPrior()`), and `context` is a sampling context that can, for example, modify how the log probability is accumulated (default: `DynamicPPL.DefaultContext()`).
-
-Sampling resets the log joint probability of `varinfo` and increases the evaluation counter of `sampler`. If `context` is a `LikelihoodContext`, only the log likelihood of `D` will be accumulated, whereas with `PriorContext` only the log prior probability of `P` is. With the `DefaultContext` the log joint probability of both `P` and `D` is accumulated.
-
-The `Model` struct contains the four internal fields `f`, `args`, `defaults`, and `context`.
-When `model::Model` is called, then the internal function `model.f` is called as `model.f(rng, varinfo, sampler, context, model.args...)`
-(for multithreaded sampling, instead of `varinfo` a threadsafe wrapper is passed to `model.f`).
-The positional and keyword arguments that were passed to the user-defined model function when the model was created are saved as a `NamedTuple` in `model.args`. The default values of the positional and keyword arguments of the user-defined model functions, if any, are saved as a `NamedTuple` in `model.defaults`. They are used for constructing model instances with different arguments by the `logprob` and `prob` string macros.
-The `context` variable sets an evaluation context that can be used to control, for instance, whether log probabilities should be evaluated for the prior, likelihood, or joint probability. By default it is set to evaluate the log joint.
-
-# Example
-
-Let's take the following model as an example:
-
-```{julia}
-#| eval: false
-@model function gauss(
-    x=missing, y=1.0, ::Type{TV}=Vector{Float64}
-) where {TV<:AbstractVector}
-    if x === missing
-        x = TV(undef, 3)
-    end
-    p = TV(undef, 2)
-    p[1] ~ InverseGamma(2, 3)
-    p[2] ~ Normal(0, 1.0)
-    @. x[1:2] ~ Normal(p[2], sqrt(p[1]))
-    x[3] ~ Normal()
-    return y ~ Normal(p[2], sqrt(p[1]))
-end
-```
-
-The above call of the `@model` macro defines the function `gauss` with positional arguments `x`, `y`, and `::Type{TV}`, rewritten in such a way that every call of it returns a `model::Model`. Note that only the function body is modified by the `@model` macro, and the function signature is left untouched. It is also possible to implement models with keyword arguments such as
-
-```{julia}
-#| eval: false
-@model function gauss(
-    ::Type{TV}=Vector{Float64}; x=missing, y=1.0
-) where {TV<:AbstractVector}
-    return ...
-end
-```
-
-This would allow us to generate a model by calling `gauss(; x = rand(3))`.
-
-If an argument has a default value `missing`, it is treated as a random variable. For variables which require an initialisation because we need to loop or broadcast over its elements, such as `x` above, the following needs to be done:
-
-```{julia}
-#| eval: false
-if x === missing
-    x = ...
-end
-```
-
-Note that since `gauss` behaves like a regular function it is possible to define additional dispatches in a second step as well. For instance, we could achieve the same behaviour by
-
-```{julia}
-#| eval: false
-@model function gauss(x, y=1.0, ::Type{TV}=Vector{Float64}) where {TV<:AbstractVector}
-    p = TV(undef, 2)
-    return ...
-end
-
-function gauss(::Missing, y=1.0, ::Type{TV}=Vector{Float64}) where {TV<:AbstractVector}
-    return gauss(TV(undef, 3), y, TV)
-end
-```
-
-If `x` is sampled as a whole from a distribution and not indexed, e.g., `x ~ Normal(...)` or `x ~ MvNormal(...)`, there is no need to initialise it in an `if`-block.
-
-## Step 1: Break up the model definition
-
-First, the `@model` macro breaks up the user-provided function definition using `DynamicPPL.build_model_info`. This function returns a dictionary consisting of:
-
-  - `allargs_exprs`: The expressions of the positional and keyword arguments, without default values.
-  - `allargs_syms`: The names of the positional and keyword arguments, e.g., `[:x, :y, :TV]` above.
-  - `allargs_namedtuple`: An expression that constructs a `NamedTuple` of the positional and keyword arguments, e.g., `:((x = x, y = y, TV = TV))` above.
-  - `defaults_namedtuple`: An expression that constructs a `NamedTuple` of the default positional and keyword arguments, if any, e.g., `:((x = missing, y = 1, TV = Vector{Float64}))` above.
-  - `modeldef`: A dictionary with the name, arguments, and function body of the model definition, as returned by `MacroTools.splitdef`.
-
-## Step 2: Generate the body of the internal model function
-
-In a second step, `DynamicPPL.generate_mainbody` generates the main part of the transformed function body using the user-provided function body and the provided function arguments, without default values, for figuring out if a variable denotes an observation or a random variable. Hereby the function `DynamicPPL.generate_tilde` replaces the `L ~ R` lines in the model and the function `DynamicPPL.generate_dot_tilde` replaces the `@. L ~ R` and `L .~ R` lines in the model.
-
-In the above example, `p[1] ~ InverseGamma(2, 3)` is replaced with something similar to
-
-```{julia}
-#| eval: false
-#= REPL[25]:6 =#
-begin
-    var"##tmpright#323" = InverseGamma(2, 3)
-    var"##tmpright#323" isa Union{Distribution,AbstractVector{<:Distribution}} || throw(
-        ArgumentError(
-            "Right-hand side of a ~ must be subtype of Distribution or a vector of Distributions.",
-        ),
-    )
-    var"##vn#325" = (DynamicPPL.VarName)(:p, ((1,),))
-    var"##inds#326" = ((1,),)
-    p[1] = (DynamicPPL.tilde_assume)(
-        _rng,
-        _context,
-        _sampler,
-        var"##tmpright#323",
-        var"##vn#325",
-        var"##inds#326",
-        _varinfo,
-    )
-end
-```
-
-Here the first line is a so-called line number node that enables more helpful error messages by providing users with the exact location of the error in their model definition. Then the right hand side (RHS) of the `~` is assigned to a variable (with an automatically generated name). We check that the RHS is a distribution or an array of distributions, otherwise an error is thrown.
-Next we extract a compact representation of the variable with its name and index (or indices). Finally, the `~` expression is replaced with a call to `DynamicPPL.tilde_assume` since the compiler figured out that `p[1]` is a random variable using the following heuristic:
-
-  1. If the symbol on the LHS of `~`, `:p` in this case, is not among the arguments to the model, `(:x, :y, :T)` in this case, it is a random variable.
-  2. If the symbol on the LHS of `~`, `:p` in this case, is among the arguments to the model but has a value of `missing`, it is a random variable.
-  3. If the value of the LHS of `~`, `p[1]` in this case, is `missing`, then it is a random variable.
-  4. Otherwise, it is treated as an observation.
-
-The `DynamicPPL.tilde_assume` function takes care of sampling the random variable, if needed, and updating its value and the accumulated log joint probability in the `_varinfo` object. If `L ~ R` is an observation, `DynamicPPL.tilde_observe` is called with the same arguments except the random number generator `_rng` (since observations are never sampled).
-
-A similar transformation is performed for expressions of the form `@. L ~ R` and `L .~ R`. For instance,
-`@. x[1:2] ~ Normal(p[2], sqrt(p[1]))` is replaced with
-
-```{julia}
-#| eval: false
-#= REPL[25]:8 =#
-begin
-    var"##tmpright#331" = Normal.(p[2], sqrt.(p[1]))
-    var"##tmpright#331" isa Union{Distribution,AbstractVector{<:Distribution}} || throw(
-        ArgumentError(
-            "Right-hand side of a ~ must be subtype of Distribution or a vector of Distributions.",
-        ),
-    )
-    var"##vn#333" = (DynamicPPL.VarName)(:x, ((1:2,),))
-    var"##inds#334" = ((1:2,),)
-    var"##isassumption#335" = begin
-        let var"##vn#336" = (DynamicPPL.VarName)(:x, ((1:2,),))
-            if !((DynamicPPL.inargnames)(var"##vn#336", _model)) ||
-                (DynamicPPL.inmissings)(var"##vn#336", _model)
-                true
-            else
-                x[1:2] === missing
-            end
-        end
-    end
-    if var"##isassumption#335"
-        x[1:2] .= (DynamicPPL.dot_tilde_assume)(
-            _rng,
-            _context,
-            _sampler,
-            var"##tmpright#331",
-            x[1:2],
-            var"##vn#333",
-            var"##inds#334",
-            _varinfo,
-        )
-    else
-        (DynamicPPL.dot_tilde_observe)(
-            _context,
-            _sampler,
-            var"##tmpright#331",
-            x[1:2],
-            var"##vn#333",
-            var"##inds#334",
-            _varinfo,
-        )
-    end
-end
-```
-
-The main difference in the expanded code between `L ~ R` and `@. L ~ R` is that the former doesn't assume `L` to be defined, it can be a new Julia variable in the scope, while the latter assumes `L` already exists. Moreover, `DynamicPPL.dot_tilde_assume` and `DynamicPPL.dot_tilde_observe` are called instead of `DynamicPPL.tilde_assume` and `DynamicPPL.tilde_observe`.
-
-## Step 3: Replace the user-provided function body
-
-Finally, we replace the user-provided function body using `DynamicPPL.build_output`. This function uses `MacroTools.combinedef` to reassemble the user-provided function with a new function body. In the modified function body an anonymous function is created whose function body was generated in step 2 above and whose arguments are
-
-  - a random number generator `_rng`,
-  - a model `_model`,
-  - a datastructure `_varinfo`,
-  - a sampler `_sampler`,
-  - a sampling context `_context`,
-  - and all positional and keyword arguments of the user-provided model function as positional arguments without any default values. Finally, in the new function body a `model::Model` with this anonymous function as internal function is returned.
-
-# `VarName`
-
-In order to track random variables in the sampling process, `Turing` uses the `VarName` struct which acts as a random variable identifier generated at runtime. The `VarName` of a random variable is generated from the expression on the LHS of a `~` statement when the symbol on the LHS is in the set `P` of unobserved random variables. Every `VarName` instance has a type parameter `sym` which is the symbol of the Julia variable in the model that the random variable belongs to. For example, `x[1] ~ Normal()` will generate an instance of `VarName{:x}` assuming `x` is an unobserved random variable. Every `VarName` also has a field `indexing`, which stores the indices required to access the random variable from the Julia variable indicated by `sym` as a tuple of tuples. Each element of the tuple thereby contains the indices of one indexing operation (`VarName` also supports hierarchical arrays and range indexing). Some examples:
-
-  - `x ~ Normal()` will generate a `VarName(:x, ())`.
-  - `x[1] ~ Normal()` will generate a `VarName(:x, ((1,),))`.
-  - `x[:,1] ~ MvNormal(zeros(2), I)` will generate a `VarName(:x, ((Colon(), 1),))`.
-  - `x[:,1][1+1] ~ Normal()` will generate a `VarName(:x, ((Colon(), 1), (2,)))`.
-
-The easiest way to manually construct a `VarName` is to use the `@varname` macro on an indexing expression, which will take the `sym` value from the actual variable name, and put the index values appropriately into the constructor.
-
-# `VarInfo`
-
-## Overview
-
-`VarInfo` is the data structure in `Turing` that facilitates tracking random variables and certain metadata about them that are required for sampling. For instance, the distribution of every random variable is stored in `VarInfo` because we need to know the support of every random variable when sampling using HMC for example. Random variables whose distributions have a constrained support are transformed using a bijector from [Bijectors.jl](https://github.com/TuringLang/Bijectors.jl) so that the sampling happens in the unconstrained space. Different samplers require different metadata about the random variables.
-
-The definition of `VarInfo` in `Turing` is:
-
-```{julia}
-#| eval: false
-struct VarInfo{Tmeta, Tlogp} <: AbstractVarInfo
-    metadata::Tmeta
-    logp::Base.RefValue{Tlogp}
-    num_produce::Base.RefValue{Int}
-end
-```
-
-Based on the type of `metadata`, the `VarInfo` is either aliased `UntypedVarInfo` or `TypedVarInfo`. `metadata` can be either a subtype of the union type `Metadata` or a `NamedTuple` of multiple such subtypes. Let `vi` be an instance of `VarInfo`. If `vi isa VarInfo{<:Metadata}`, then it is called an `UntypedVarInfo`. If `vi isa VarInfo{<:NamedTuple}`, then `vi.metadata` would be a `NamedTuple` mapping each symbol in `P` to an instance of `Metadata`. `vi` would then be called a `TypedVarInfo`. The other fields of `VarInfo` include `logp` which is used to accumulate the log probability or log probability density of the variables in `P` and `D`. `num_produce` keeps track of how many observations have been made in the model so far. This is incremented when running a `~` statement when the symbol on the LHS is in `D`.
-
-## `Metadata`
-
-The `Metadata` struct stores some metadata about the random variables sampled. This helps query certain information about a variable such as: its distribution, which samplers sample this variable, its value and whether this value is transformed to real space or not. Let `md` be an instance of `Metadata`:
-
-  - `md.vns` is the vector of all `VarName` instances. Let `vn` be an arbitrary element of `md.vns`
-  - `md.idcs` is the dictionary that maps each `VarName` instance to its index in `md.vns`, `md.ranges`, `md.dists`, `md.orders` and `md.flags`.
-  - `md.vns[md.idcs[vn]] == vn`.
-  - `md.dists[md.idcs[vn]]` is the distribution of `vn`.
-  - `md.gids[md.idcs[vn]]` is the set of algorithms used to sample `vn`. This was used by the Gibbs sampler. Since Turing v0.36 it is unused and will eventually be deleted.
-  - `md.orders[md.idcs[vn]]` is the number of `observe` statements before `vn` is sampled.
-  - `md.ranges[md.idcs[vn]]` is the index range of `vn` in `md.vals`.
-  - `md.vals[md.ranges[md.idcs[vn]]]` is the linearized vector of values of corresponding to `vn`.
-  - `md.flags` is a dictionary of true/false flags. `md.flags[flag][md.idcs[vn]]` is the value of `flag` corresponding to `vn`.
-
-Note that in order to make `md::Metadata` type stable, all the `md.vns` must have the same symbol and distribution type. However, one can have a single Julia variable, e.g. `x`, that is a matrix or a hierarchical array sampled in partitions, e.g. `x[1][:] ~ MvNormal(zeros(2), I); x[2][:] ~ MvNormal(ones(2), I)`. The symbol `x` can still be managed by a single `md::Metadata` without hurting the type stability since all the distributions on the RHS of `~` are of the same type.
-
-However, in `Turing` models one cannot have this restriction, so we must use a type unstable `Metadata` if we want to use one `Metadata` instance for the whole model. This is what `UntypedVarInfo` does. A type unstable `Metadata` will still work but will have inferior performance.
-
-To strike a balance between flexibility and performance when constructing the `spl::Sampler` instance, the model is first run by sampling the parameters in `P` from their priors using an `UntypedVarInfo`, i.e. a type unstable `Metadata` is used for all the variables. Then once all the symbols and distribution types have been identified, a `vi::TypedVarInfo` is constructed where `vi.metadata` is a `NamedTuple` mapping each symbol in `P` to a specialized instance of `Metadata`. So as long as each symbol in `P` is sampled from only one type of distributions, `vi::TypedVarInfo` will have fully concretely typed fields which brings out the peak performance of Julia.
diff --git a/developers/compiler/model-manual/index.qmd b/developers/compiler/model-manual/index.qmd
index 13f1b33ec..0edf49513 100755
--- a/developers/compiler/model-manual/index.qmd
+++ b/developers/compiler/model-manual/index.qmd
@@ -30,23 +30,24 @@ However, models can be constructed by hand without the use of a macro. Taking th
 
 ```{julia}
 using DynamicPPL
+using DynamicPPL.VarNamedTuples: NoTemplate
 
 # Create the model function.
 function gdemo2(model, varinfo, x)
     # Assume s² has an InverseGamma distribution.
     s², varinfo = DynamicPPL.tilde_assume!!(
-        model.context, InverseGamma(2, 3), @varname(s²), varinfo
+        model.context, InverseGamma(2, 3), @varname(s²), NoTemplate(), varinfo
     )
 
     # Assume m has a Normal distribution.
     m, varinfo = DynamicPPL.tilde_assume!!(
-        model.context, Normal(0, sqrt(s²)), @varname(m), varinfo
+        model.context, Normal(0, sqrt(s²)), @varname(m), NoTemplate(), varinfo
     )
 
     # Observe each value of x[i] according to a Normal distribution.
     for i in eachindex(x)
         _retval, varinfo = DynamicPPL.tilde_observe!!(
-            model.context, Normal(m, sqrt(s²)), x[i], @varname(x[i]), varinfo
+            model.context, Normal(m, sqrt(s²)), x[i], @varname(x[i]), x, varinfo
         )
     end
 
diff --git a/developers/contexts/submodel-condition/index.qmd b/developers/contexts/submodel-condition/index.qmd
index 20dbf1901..21b3b5112 100755
--- a/developers/contexts/submodel-condition/index.qmd
+++ b/developers/contexts/submodel-condition/index.qmd
@@ -44,16 +44,11 @@ The phrase 'becoming' a different variable is a little underspecified: it is use
 The method responsible for it is `tilde_assume(::PrefixContext, right, vn, vi)`: this attaches the prefix in the context to the `VarName` argument, before recursively calling `tilde_assume` with the new prefixed `VarName`.
 This means that even though a statement `x ~ dist` still enters the tilde pipeline at the top level as `x`, if the model evaluation context contains a `PrefixContext`, any function after `tilde_assume(::PrefixContext, ...)` will see `a.x` instead.
 
-## ConditionContext
+## CondFixContext
 
-`ConditionContext` is a context which stores values of variables that are to be conditioned on.
-These values may be stored as a `Dict` which maps `VarName`s to values, or alternatively as a `NamedTuple`.
-The latter only works correctly if all `VarName`s are 'basic', in that they have an identity optic (i.e., something like `a.x` or `a[1]` is forbidden).
-Because of this limitation, we will only use `Dict` in this example.
-
-::: {.callout-note}
-If a `ConditionContext` with a `NamedTuple` encounters anything to do with a prefix, its internal `NamedTuple` is converted to a `Dict` anyway, so it is quite reasonable to ignore the `NamedTuple` case in this exposition.
-:::
+`CondFixContext` is a context which stores values of variables that are to be conditioned or fixed on.
+It takes a single type parameter, which is either `DynamicPPL.Condition` or `DynamicPPL.Fix`, which indicates whether the context is for conditioning or fixing.
+These values are internally stored as a `VarNamedTuple.`
 
 One can inspect the conditioning values with, for example:
 
@@ -64,12 +59,15 @@ One can inspect the conditioning values with, for example:
 end
 
 cond_model = d() | (@varname(x) => 1.0)
-cond_ctx = cond_model.context
+
+cond_values = conditioned(cond_model)
 ```
 
 There are several internal functions that are used to determine whether a variable is conditioned, and if so, what its value is.
 
 ```{julia}
+cond_ctx = cond_model.context
+
 DynamicPPL.hasconditioned_nested(cond_ctx, @varname(x))
 ```
 
@@ -88,15 +86,20 @@ Notice that (neglecting `missing` values) the return value of `contextual_isassu
 :::
 
 If a variable `x` is conditioned on, then the effect of this is to set the value of `x` to the given value (while still including its contribution to the log probability density).
-Since `x` is no longer a random variable, if we were to evaluate the model, we would find only one key in the `VarInfo`:
+Since `x` is no longer a random variable, if we were to evaluate the model, we would find only one key:
 
 ```{julia}
-keys(VarInfo(cond_model))
+rand(cond_model)
 ```
 
 ## Joint behaviour: desiderata at the model level
 
-When paired together, these two contexts have the potential to cause substantial confusion: `PrefixContext` modifies the variable names that are seen, which may cause them to be out of sync with the values contained inside the `ConditionContext`.
+:::{.callout-note}
+The same points apply to both conditioning and fixing, so we will discuss it generically in terms of `CondFixContext`.
+The code examples will use conditioning to demonstrate this.
+:::
+
+When paired together, these two contexts have the potential to cause substantial confusion: `PrefixContext` modifies the variable names that are seen, which may cause them to be out of sync with the values contained inside the `CondFixContext`.
 
 We begin by mentioning some high-level desiderata for their joint behaviour.
 Take these models, for example:
@@ -127,9 +130,9 @@ with_inner_cond = outer2()
 
 We want that:
 
- 1. `keys(VarInfo(outer()))` should return `[a.x, a.y]`;
- 2. `keys(VarInfo(with_outer_cond))` should return `[a.y]`;
- 3. `keys(VarInfo(with_inner_cond))` should return `[a.y]`,
+ 1. `keys(rand(outer()))` should return `[a.x, a.y]`;
+ 2. `keys(rand(with_outer_cond))` should return `[a.y]`;
+ 3. `keys(rand(with_inner_cond))` should return `[a.y]`,
 
 **In other words, we can condition submodels either from the outside (point (2)) or from the inside (point (3)), and the variable name we use to specify the conditioning should match the level at which we perform the conditioning.**
 
@@ -153,9 +156,9 @@ We do not specify the implementation details here, but we will sketch out someth
 **Points (2) and (3)** are more tricky.
 As the reader may surmise, the difference between them is the order in which the contexts are stacked.
 
-For the _outer_ conditioning case (point (2)), the `ConditionContext` will contain a `VarName` that is already prefixed.
-When we enter the inner submodel, this `ConditionContext` has to be passed down and somehow combined with the `PrefixContext` that is created when we enter the submodel.
-We make the claim here that the best way to do this is to nest the `PrefixContext` _inside_ the `ConditionContext`.
+For the _outer_ conditioning case (point (2)), the `CondFixContext` will contain a `VarName` that is already prefixed.
+When we enter the inner submodel, this `CondFixContext` has to be passed down and somehow combined with the `PrefixContext` that is created when we enter the submodel.
+We make the claim here that the best way to do this is to nest the `PrefixContext` _inside_ the `CondFixContext`.
 This is indeed what happens, as can be demonstrated by running the model.
 
 ```{julia}
@@ -163,8 +166,8 @@ with_outer_cond()
 ```
 
 For the _inner_ conditioning case (point (3)), the outer model is not run with any special context.
-The inner model will itself contain a `ConditionContext` will contain a `VarName` that is not prefixed.
-When we run the model, this `ConditionContext` should be then nested _inside_ a `PrefixContext` to form the final evaluation context.
+The inner model will itself contain a `CondFixContext` will contain a `VarName` that is not prefixed.
+When we run the model, this `CondFixContext` should be then nested _inside_ a `PrefixContext` to form the final evaluation context.
 Again, we can run the model to see this in action:
 
 ```{julia}
@@ -174,13 +177,17 @@ with_inner_cond()
 Putting all of the information so far together, what it means is that if we have these two inner contexts (taken from above):
 
 ```{julia}
-using DynamicPPL: PrefixContext, ConditionContext, DefaultContext
+using DynamicPPL: PrefixContext, DefaultContext, CondFixContext, Condition
 
-inner_ctx_with_outer_cond = ConditionContext(
-    Dict(@varname(a.x) => 1.0), PrefixContext(@varname(a))
-)
-inner_ctx_with_inner_cond = PrefixContext(
-    @varname(a), ConditionContext(Dict(@varname(x) => 1.0))
+outer_cond = @vnt begin
+    a.x := 1.0
+end
+inner_ctx_with_outer_cond = CondFixContext{Condition}(outer_cond, PrefixContext(@varname(a)))
+
+inner_cond = @vnt begin
+    x := 1.0
+end
+inner_ctx_with_inner_cond = PrefixContext(@varname(a), CondFixContext{Condition}(inner_cond)
 )
 ```
 
@@ -207,7 +214,7 @@ This allows us to finally specify our task as follows:
 ## How do we do it?
 
 (1) `hasconditioned_nested` and `getconditioned_nested` accomplish this by first 'collapsing' the context stack, i.e. they go through the context stack, remove all `PrefixContext`s, and apply those prefixes to any conditioned variables below it in the stack.
-Once the `PrefixContext`s have been removed, one can then iterate through the context stack and check if any of the `ConditionContext`s contain the variable, or get the value itself.
+Once the `PrefixContext`s have been removed, one can then iterate through the context stack and check if any of the `CondFixContext`s contain the variable, or get the value itself.
 For more details the reader is encouraged to read the source code.
 
 (2a) We ensure that the context stack is correctly arranged by relying on the behaviour of `make_evaluate_args_and_kwargs`.
@@ -221,7 +228,7 @@ This is done inside the `@model` macro, or technically, its subsidiary function
 
 ## Nested submodels
 
-Just in case the above wasn't complicated enough, we need to also be very careful when dealing with nested submodels, which have multiple layers of `PrefixContext`s which may be interspersed with `ConditionContext`s.
+Just in case the above wasn't complicated enough, we need to also be very careful when dealing with nested submodels, which have multiple layers of `PrefixContext`s which may be interspersed with `CondFixContext`s.
 For example, in this series of nested submodels,
 
 ```{julia}
@@ -248,11 +255,18 @@ The general strategy that we adopt is similar to above.
 Following the principle that `PrefixContext` should be nested inside the outer context, but outside the inner submodel's context, we can infer that the correct context inside `charlie` should be:
 
 ```{julia}
+vnt_by = @vnt begin
+    b.y := 1.0
+end
+vnt_x = @vnt begin
+    x := 1.0
+end
+
 big_ctx = PrefixContext(
     @varname(a),
-    ConditionContext(
-        Dict(@varname(b.y) => 1.0),
-        PrefixContext(@varname(b), ConditionContext(Dict(@varname(x) => 1.0))),
+    CondFixContext{Condition}(
+        vnt_by,
+        PrefixContext(@varname(b), CondFixContext{Condition}(vnt_x)),
     ),
 )
 ```
@@ -303,7 +317,7 @@ When editing this code, it is worth being mindful of this as a potential source
 If you have encountered left and right folds, the above discussion illustrates the difference between them: the wrong implementation of `myprefix` uses a left fold (which collects prefixes in the opposite order from which they are encountered), while the correct implementation uses a right fold.
 :::
 
-## Loose ends 1: Manual prefixing
+## Loose end: Manual prefixing
 
 Sometimes users may want to manually prefix a model, for example:
 
@@ -337,9 +351,3 @@ prefixed_model = prefix(model, :a)
 
 (model.context, prefixed_model.context)
 ```
-
-## Loose ends 2: FixedContext
-
-Finally, note that all of the above also applies to the interaction between `PrefixContext` and `FixedContext`, except that the functions have different names.
-(`FixedContext` behaves the same way as `ConditionContext`, except that unlike conditioned variables, fixed variables do not contribute to the log probability density.)
-This generally results in a large amount of code duplication, but the concepts that underlie both contexts are exactly the same.
diff --git a/developers/inference/abstractmcmc-turing/index.qmd b/developers/inference/abstractmcmc-turing/index.qmd
deleted file mode 100755
index 642b623b0..000000000
--- a/developers/inference/abstractmcmc-turing/index.qmd
+++ /dev/null
@@ -1,329 +0,0 @@
----
-title: How Turing Implements AbstractMCMC
-engine: julia
-aliases:
-  - ../../tutorials/docs-04-for-developers-abstractmcmc-turing/index.html
----
-
-```{julia}
-#| echo: false
-#| output: false
-using Pkg;
-Pkg.instantiate();
-```
-
-Prerequisite: Interface guide.
-
-## Introduction
-
-Consider the following Turing, code block:
-
-```{julia}
-using Turing
-
-@model function gdemo(x, y)
-    s² ~ InverseGamma(2, 3)
-    m ~ Normal(0, sqrt(s²))
-    x ~ Normal(m, sqrt(s²))
-    return y ~ Normal(m, sqrt(s²))
-end
-
-mod = gdemo(1.5, 2)
-alg = IS()
-n_samples = 1000
-
-chn = sample(mod, alg, n_samples, progress=false)
-```
-
-The function `sample` is part of the AbstractMCMC interface. As explained in the interface guide, building a sampling method that can be used by `sample` consists of overloading the structs and functions in `AbstractMCMC`. The interface guide also gives a standalone example of their implementation, [`AdvancedMH.jl`]().
-
-Turing sampling methods (most of which are written [here](https://github.com/TuringLang/Turing.jl/tree/main/src/mcmc)) also implement `AbstractMCMC`. Turing defines a particular architecture for `AbstractMCMC` implementations, which enables working with models defined by the `@model` macro, and uses DynamicPPL as a backend. The goal of this page is to describe this architecture, and how you would go about implementing your own sampling method in Turing, using Importance Sampling as an example. I don't go into all the details: for instance, I don't address selectors or parallelism.
-
-First, we explain how Importance Sampling works in the abstract. Consider the model defined in the first code block. Mathematically, it can be written:
-
-$$
-\begin{align*}
-s &\sim \text{InverseGamma}(2, 3), \\
-m &\sim \text{Normal}(0, \sqrt{s}), \\
-x &\sim \text{Normal}(m, \sqrt{s}), \\
-y &\sim \text{Normal}(m, \sqrt{s}).
-\end{align*}
-$$
-
-The **latent** variables are $s$ and $m$, the **observed** variables are $x$ and $y$. The model **joint** distribution $p(s,m,x,y)$ decomposes into the **prior** $p(s,m)$ and the **likelihood** $p(x,y \mid s,m).$ Since $x = 1.5$ and $y = 2$ are observed, the goal is to infer the **posterior** distribution $p(s,m \mid x,y).$
-
-Importance Sampling produces independent samples $(s_i, m_i)$ from the prior distribution. It also outputs unnormalized weights
-
-$$
-w_i = \frac {p(x,y,s_i,m_i)} {p(s_i, m_i)} = p(x,y \mid s_i, m_i)
-$$
-
-such that the empirical distribution
-
-$$
-\frac{1}{N} \sum_{i =1}^N \frac {w_i} {\sum_{j=1}^N w_j} \delta_{(s_i, m_i)}
-$$
-
-is a good approximation of the posterior.
-
-## 1. Define a Sampler
-
-Recall the last line of the above code block:
-
-```{julia}
-chn = sample(mod, alg, n_samples, progress=false)
-```
-
-Here `sample` takes as arguments a **model** `mod`, an **algorithm** `alg`, and a **number of samples** `n_samples`, and returns an instance `chn` of `Chains` which can be analysed using the functions in `MCMCChains`.
-
-### Models
-
-To define a **model**, you declare a joint distribution on variables in the `@model` macro, and specify which variables are observed and which should be inferred, as well as the value of the observed variables. Thus, when implementing Importance Sampling,
-
-```{julia}
-mod = gdemo(1.5, 2)
-```
-
-creates an instance `mod` of the struct `Model`, which corresponds to the observations of a value of `1.5` for `x`, and a value of `2` for `y`.
-
-This is all handled by DynamicPPL, more specifically [here](https://github.com/TuringLang/DynamicPPL.jl/blob/main/src/model.jl). I will return to how models are used to inform sampling algorithms [below](#assumeobserve).
-
-### Algorithms
-
-An **algorithm** is just a sampling method: in Turing, it is a subtype of the abstract type `InferenceAlgorithm`. Defining an algorithm may require specifying a few high-level parameters. For example, "Hamiltonian Monte-Carlo" may be too vague, but "Hamiltonian Monte Carlo with  10 leapfrog steps per proposal and a stepsize of 0.01" is an algorithm. "Metropolis-Hastings" may be too vague, but "Metropolis-Hastings with proposal distribution `p`" is an algorithm.
-Thus
-
-```{julia}
-stepsize = 0.01
-L = 10
-alg = HMC(stepsize, L)
-```
-
-defines a Hamiltonian Monte-Carlo algorithm, an instance of `HMC`, which is a subtype of `InferenceAlgorithm`.
-
-In the case of Importance Sampling, there is no need to specify additional parameters:
-
-```{julia}
-alg = IS()
-```
-
-defines an Importance Sampling algorithm, an instance of `IS`, a subtype of `InferenceAlgorithm`.
-
-When creating your own Turing sampling method, you must, therefore, build a subtype of `InferenceAlgorithm` corresponding to your method.
-
-### Samplers
-
-Samplers are **not** the same as algorithms. An algorithm is a generic sampling method, a sampler is an object that stores information about how algorithm and model interact during sampling, and is modified as sampling progresses. The `Sampler` struct is defined in DynamicPPL.
-
-Turing implements `AbstractMCMC`'s `AbstractSampler` with the `Sampler` struct defined in `DynamicPPL`. The most important attributes of an instance `spl` of `Sampler` are:
-
-- `spl.alg`: the sampling method used, an instance of a subtype of `InferenceAlgorithm`
-- `spl.state`: information about the sampling process, see [below](#states)
-
-When you call `sample(mod, alg, n_samples)`, Turing first uses `model` and `alg` to build an instance `spl` of `Sampler` , then calls the native `AbstractMCMC` function `sample(mod, spl, n_samples)`.
-
-When you define your own Turing sampling method, you must therefore build:
-
-- a **sampler constructor** that uses a model and an algorithm to initialise an instance of `Sampler`. For Importance Sampling:
-
-```{julia}
-#| eval: false
-function Sampler(alg::IS, model::Model, s::Selector)
-    info = Dict{Symbol,Any}()
-    state = ISState(model)
-    return Sampler(alg, info, s, state)
-end
-```
-
-- a **state** struct implementing `AbstractSamplerState` corresponding to your method: we cover this in the following paragraph.
-
-### States
-
-The `vi` field contains all the important information about sampling: first and foremost, the values of all the samples, but also the distributions from which they are sampled, the names of model parameters, and other metadata. As we will see below, many important steps during sampling correspond to queries or updates to `spl.state.vi`.
-
-By default, you can use `SamplerState`, a concrete type defined in `inference/Inference.jl`, which extends `AbstractSamplerState` and has no field except for `vi`:
-
-```{julia}
-#| eval: false
-mutable struct SamplerState{VIType<:VarInfo} <: AbstractSamplerState
-    vi::VIType
-end
-```
-
-When doing Importance Sampling, we care not only about the values of the samples but also their weights. We will see below that the weight of each sample is also added to `spl.state.vi`. Moreover, the average
-
-$$
-\frac 1 N \sum_{j=1}^N w_i = \frac 1 N \sum_{j=1}^N p(x,y \mid s_i, m_i)
-$$
-
-of the sample weights is a particularly important quantity:
-
-- it is used to **normalise** the **empirical approximation** of the posterior distribution
-- its logarithm is the importance sampling **estimate** of the **log evidence** $\log p(x, y)$
-
-To avoid having to compute it over and over again, `is.jl`defines an IS-specific concrete type `ISState` for sampler states, with an additional field `final_logevidence` containing
-
-$$
-\log \frac 1 N \sum_{j=1}^N w_i.
-$$
-
-```{julia}
-#| eval: false
-mutable struct ISState{V<:VarInfo,F<:AbstractFloat} <: AbstractSamplerState
-    vi::V
-    final_logevidence::F
-end
-
-# additional constructor
-ISState(model::Model) = ISState(VarInfo(model), 0.0)
-```
-
-The following diagram summarizes the hierarchy presented above.
-
-```{dot}
-//| echo: false
-digraph G {
-    node [shape=box];
-
-    spl [label=<spl<br/>Sampler<br/>&lt;:AbstractSampler>, style=rounded, xlabel="", shape=box];
-    state [label=<spl.state<br/>State<br/>&lt;:AbstractSamplerState>, style=rounded, xlabel="", shape=box];
-    alg [label=<spl.alg<br/>Algorithm<br/>&lt;:InferenceAlgorithm>, style=rounded, xlabel="", shape=box];
-    vi [label=<spl.state.vi<br/>VarInfo<br/>&lt;:AbstractVarInfo>, style=rounded, xlabel="", shape=box];
-    placeholder1 [label="...", width=1];
-    placeholder2 [label="...", width=1];
-    placeholder3 [label="...", width=1];
-    placeholder4 [label="...", width=1];
-
-    spl -> state;
-    spl -> alg;
-    spl -> placeholder1;
-
-    state -> vi;
-    state -> placeholder2;
-
-    alg -> placeholder3;
-    placeholder1 -> placeholder4;
-}
-```
-
-## 2. Overload the functions used inside mcmcsample
-
-A lot of the things here are method-specific. However, Turing also has some functions that make it easier for you to implement these functions, for example.
-
-### Transitions
-
-`AbstractMCMC` stores information corresponding to each individual sample in objects called `transition`, but does not specify what the structure of these objects could be. You could decide to implement a type `MyTransition` for transitions corresponding to the specifics of your methods. However, there are many situations in which the only information you need for each sample is:
-
-- its value: $\theta$
-- log of the joint probability of the observed data and this sample: `lp`
-
-`Inference.jl` [defines](https://github.com/TuringLang/Turing.jl/blob/main/src/inference/Inference.jl#L103) a struct `Transition`, which corresponds to this default situation
-
-```{julia}
-#| eval: false
-struct Transition{T,F<:AbstractFloat}
-    θ::T
-    lp::F
-end
-```
-
-It also [contains](https://github.com/TuringLang/Turing.jl/blob/main/src/inference/Inference.jl#L108) a constructor that builds an instance of `Transition` from an instance `spl` of `Sampler`: $\theta$ is `spl.state.vi` converted to a `namedtuple`, and `lp` is `getlogp(spl.state.vi)`. `is.jl` uses this default constructor at the end of the `step!` function [here](https://github.com/TuringLang/Turing.jl/blob/main/src/inference/is.jl#L58).
-
-### How `sample` works
-
-A crude summary, which ignores things like parallelism, is the following:
-
-`sample` calls `mcmcsample`, which calls
-
-- `sample_init!` to set things up
-- `step!` repeatedly to produce multiple new transitions
-- `sample_end!` to perform operations once all samples have been obtained
-- `bundle_samples` to convert a vector of transitions into a more palatable type, for instance a `Chain`.
-
-You can, of course, implement all of these functions, but `AbstractMCMC` as well as Turing, also provide default implementations for simple cases. For instance, importance sampling uses the default implementations of `sample_init!` and `bundle_samples`, which is why you don't see code for them inside `is.jl`.
-
-## 3. Overload assume and observe
-
-The functions mentioned above, such as `sample_init!`, `step!`, etc., must, of course, use information about the model in order to generate samples! In particular, these functions may need **samples from distributions** defined in the model or to **evaluate the density of these distributions** at some values of the corresponding parameters or observations.
-
-For an example of the former, consider **Importance Sampling** as defined in `is.jl`. This implementation of Importance Sampling uses the model prior distribution as a proposal distribution, and therefore requires **samples from the prior distribution** of the model. Another example is **Approximate Bayesian Computation**, which requires multiple **samples from the model prior and likelihood distributions** in order to generate a single sample.
-
-An example of the latter is the **Metropolis-Hastings** algorithm. At every step of sampling from a target posterior
-
-$$
-p(\theta \mid x_{\text{obs}}),
-$$
-
-in order to compute the acceptance ratio, you need to **evaluate the model joint density**
-
-$$
-p\left(\theta_{\text{prop}}, x_{\text{obs}}\right)
-$$
-
-with $\theta_{\text{prop}}$ a sample from the proposal and $x_{\text{obs}}$ the observed data.
-
-This begs the question: how can these functions access model information during sampling? Recall that the model is stored as an instance `m` of `Model`. One of the attributes of `m` is the model evaluation function `m.f`, which is built by compiling the `@model` macro. Executing `f` runs the tilde statements of the model in order, and adds model information to the sampler (the instance of `Sampler` that stores information about the ongoing sampling process) at each step (see [here]({{<meta dev-model-manual>}}) for more information about how the `@model` macro is compiled). The DynamicPPL functions `assume` and `observe` determine what kind of information to add to the sampler for every tilde statement.
-
-Consider an instance `m` of `Model` and a sampler `spl`, with associated `VarInfo` `vi = spl.state.vi`. At some point during the sampling process, an AbstractMCMC function such as `step!` calls  `m(vi, ...)`, which calls the model evaluation function `m.f(vi, ...)`.
-
-  - for every tilde statement in the `@model` macro, `m.f(vi, ...)` returns model-related information (samples, value of the model density, etc.), and adds it to `vi`. How does it do that?
-
-      + recall that the code for `m.f(vi, ...)` is automatically generated by compilation of the `@model` macro
-
-      + for every tilde statement in the `@model` declaration, this code contains a call to `assume(vi, ...)` if the variable on the LHS of the tilde is a **model parameter to infer**, and `observe(vi, ...)` if the variable on the LHS of the tilde is an **observation**
-
-      + in the file corresponding to your sampling method (ie in `Turing.jl/src/inference/<your_method>.jl`), you have **overloaded** `assume` and `observe`, so that they can modify `vi` to include the information and samples that you care about!
-
-      + at a minimum, `assume` and `observe` return the log density `lp` of the sample or observation. the model evaluation function then immediately calls `acclogp!!(vi, lp)`, which adds `lp` to the value of the log joint density stored in `vi`.
-
-Here's what `assume` looks like for Importance Sampling:
-
-```{julia}
-#| eval: false
-function DynamicPPL.assume(rng, spl::Sampler{<:IS}, dist::Distribution, vn::VarName, vi)
-    r = rand(rng, dist)
-    push!(vi, vn, r, dist, spl)
-    return r, 0
-end
-```
-
-The function first generates a sample `r` from the distribution `dist` (the right hand side of the tilde statement). It then adds `r` to `vi`, and returns `r` and 0.
-
-The `observe` function is even simpler:
-
-```{julia}
-#| eval: false
-function DynamicPPL.observe(spl::Sampler{<:IS}, dist::Distribution, value, vi)
-    return logpdf(dist, value)
-end
-```
-
-It simply returns the density (in the discrete case, the probability) of the observed value under the distribution `dist`.
-
-## 4. Summary: Importance Sampling step by step
-
-We focus on the AbstractMCMC functions that are overridden in `is.jl` and executed inside `mcmcsample`: `step!`, which is called `n_samples` times, and `sample_end!`, which is executed once after those `n_samples` iterations.
-
-  - During the $i$-th iteration, `step!` does 3 things:
-
-      + `empty!!(spl.state.vi)`: remove information about the previous sample from the sampler's `VarInfo`
-
-      + `model(rng, spl.state.vi, spl)`: call the model evaluation function
-
-          * calls to `assume` add the samples from the prior $s_i$ and $m_i$ to `spl.state.vi`
-
-          * calls to `assume` or `observe` are followed by the line `acclogp!!(vi, lp)`, where `lp` is an output of `assume` and `observe`
-
-          * `lp` is set to 0 after `assume`, and to the value of the density at the observation after `observe`
-
-          * When all the tilde statements have been covered, `spl.state.vi.logp[]` is the sum of the `lp`, i.e., the likelihood $\log p(x, y \mid s_i, m_i) = \log p(x \mid s_i, m_i) + \log p(y \mid s_i, m_i)$ of the observations given the latent variable samples $s_i$ and $m_i$.
-
-      + `return Transition(spl)`: build a transition from the sampler, and return that transition
-
-          * the transition's `vi` field is simply `spl.state.vi`
-
-          * the `lp` field contains the likelihood `spl.state.vi.logp[]`
-
-  - When the `n_samples` iterations are completed, `sample_end!` fills the `final_logevidence` field of `spl.state`
-
-      + It simply takes the logarithm of the average of the sample weights, using the log weights for numerical stability
\ No newline at end of file
diff --git a/developers/models/varinfo-overview/index.qmd b/developers/models/varinfo-overview/index.qmd
deleted file mode 100644
index 063463a1d..000000000
--- a/developers/models/varinfo-overview/index.qmd
+++ /dev/null
@@ -1,392 +0,0 @@
----
-title: "Evaluation of DynamicPPL Models with VarInfo"
-engine: julia
----
-
-Once you have defined a model using the `@model` macro, Turing.jl provides high-level interfaces for applying MCMC sampling, variational inference, optimisation, and other inference algorithms.
-Suppose, however, that you want to work more directly with the model.
-A common use case for this is if you are developing your own inference algorithm.
-
-This page describes how you can evaluate DynamicPPL models and obtain information about variable values, log densities, and other quantities of interest.
-In particular, this provides a high-level overview of what we call `VarInfo`: this is a data structure that holds information about the execution state while traversing a model.
-
-To begin, let's define a simple model.
-
-```{julia}
-using DynamicPPL, Distributions
-
-@model function simple()
-    @info " --- Executing model --- "
-    x ~ Normal()            # Prior
-    2.0 ~ Normal(x)         # Likelihood
-    return (; xplus1 = x + 1)  # Return value
-end
-
-model = simple()
-```
-
-## The outputs of a model
-
-A DynamicPPL model has similar characteristics to Julia functions (which should not come as a surprise, since the `@model` macro is applied to a Julia function).
-However, an ordinary function only has a return value, whereas DynamicPPL models can have both _return values_ as well as _latent variables_ (i.e., the random variables in the model).
-
-In general, both of these are of interest.
-We can obtain the return value by calling the model as if it were a function:
-
-```{julia}
-retval = model()
-```
-
-and the latent variables using `rand()`:
-
-```{julia}
-latents = rand(Dict, model)
-```
-
-::: {.callout-note}
-## Why `Dict`?
-
-Simply calling `rand(model)`, by default, returns a NamedTuple.
-This is fine for simple models where all variables on the left-hand side of tilde statements are standalone variables like `x`.
-However, if you have indices or fields such as `x[1]` or `x.a` on the left-hand side, then the NamedTuple will not be able to represent these variables properly.
-Feeding such a NamedTuple back into the model will lead to errors.
-
-In general, `Dict{VarName}` will always avoid such correctness issues.
-:::
-
-Before proceeding, it is worth mentioning that both of these calls generate values for random variables by sampling from their prior distributions.
-We will see how to use different sampling strategies later.
-
-## Passing latent values into a model
-
-Having considered what one can obtain from a model, we now turn to how we can use it.
-
-Suppose you now want to obtain the log probability (prior, likelihood, or joint) of a model, *given* certain parameters.
-For this purpose, DynamicPPL provides the `logprior`, `loglikelihood`, and `logjoint` functions:
-
-```{julia}
-logprior(model, latents)
-```
-
-One can check this against the expected log prior:
-
-```{julia}
-logpdf(Normal(), latents[@varname(x)])
-```
-
-Likewise, you can evaluate the return value of the model given the latent variables:
-
-```{julia}
-returned(model, latents)
-```
-
-## VarInfo
-
-The above functions are convenient, but for many 'serious' applications they might not be flexible enough.
-For example, if you wanted to obtain the return value _and_ the log joint, you would have to execute the model twice: once with `returned` and once with `logjoint`.
-
-If you want to avoid this duplicate work, you need to use a lower-level interface, which is `DynamicPPL.evaluate!!`.
-At its core, `evaluate!!` takes a model and a VarInfo object, and returns a tuple of the return value and the new VarInfo.
-So, before we even get to `evaluate!!`, we need to understand what a VarInfo is.
-
-A VarInfo is a container that tracks the state of model execution, as well as any outputs related to its latent variables, such as log probabilities.
-DynamicPPL's source code contains many different kinds of VarInfos, each with different trade-offs.
-The details of these are somewhat arcane and unfortunately cannot be fully abstracted away, mainly due to performance considerations.
-
-For the vast majority of users, it suffices to know that you can generate one of them for a model with the constructor `VarInfo([rng, ]model)`.
-Note that this construction executes the model once (sampling new parameter values from the prior in the process).
-
-```{julia}
-v = VarInfo(model)
-```
-
-(Don't worry about the printout of the VarInfo object: we won't need to understand its internal structure.)
-We can index into a VarInfo:
-
-```{julia}
-v[@varname(x)]
-```
-
-To access the values of log-probabilities, DynamicPPL provides the `getlogprior`, `getloglikelihood`, and `getlogjoint` functions:
-
-```{julia}
-DynamicPPL.getlogprior(v)
-```
-
-What about the return value?
-Well, the VarInfo does not store this directly: recall that `evaluate!!` gives us back the return value separately from the updated VarInfo.
-So, let's try calling it to see what happens.
-The default behaviour of `evaluate!!` is to use the parameter values stored in the VarInfo during model execution.
-That is, when it sees `x ~ Normal()`, it will use the value of `x` stored in `v`.
-We will see later how to change this behaviour.
-
-```{julia}
-retval, vout = DynamicPPL.evaluate!!(model, v)
-```
-
-So here in a single call we have obtained both the return value and an updated VarInfo `vout`, from which we can again extract log probabilities and variable values.
-We can see from this that the value of `vout[@varname(x)]` is the same as `v[@varname(x)]`:
-
-```{julia}
-vout[@varname(x)] == v[@varname(x)]
-```
-
-which is in line with the statement above that by default `evaluate!!` uses the values stored in the VarInfo.
-
-At this point, the keen reader will notice that we have not really solved the problem here.
-Although the call to `DynamicPPL.evaluate!!` does indeed only execute the model once, we also had to do this once more at the beginning when constructing the VarInfo.
-
-Besides, we don't know how to control the parameter values used during model execution: they were simply whatever we got in the original VarInfo.
-
-## Specifying parameter values
-
-We will first tackle the problem of specifying our own parameter values.
-To do this, we need to use `DynamicPPL.init!!` instead of `DynamicPPL.evaluate!!`.
-
-The difference is that instead of using the values stored in the VarInfo (which `evaluate!!` does by default), `init!!` uses a _strategy_ for generating new values, and overwrites the values in the VarInfo accordingly.
-For example, `InitFromPrior()` says that any time a tilde-statement `x ~ dist` is encountered, a new value for `x` should be sampled from `dist`:
-
-```{julia}
-retval, v_new = DynamicPPL.init!!(model, v, InitFromPrior())
-```
-
-This updates `v_new` with the new values that were sampled, and also means that log probabilities are computed using these new values.
-
-::: {.callout-note}
-## Random number generator
-You can also provide an `AbstractRNG` as the first argument to `init!!` to control the reproducibility of the sampling: here we have omitted it.
-:::
-
-Alternatively, to provide specific sets of values, we can use `InitFromParams(...)` to specify them.
-`InitFromParams` can wrap either a `NamedTuple` or an `AbstractDict{<:VarName}`, but `Dict` is generally much preferred as this guarantees correct behaviour even for complex variable names.
-
-```{julia}
-retval, v_new = DynamicPPL.init!!(
-    model, v, InitFromParams(Dict(@varname(x) => 3.0))
-)
-```
-
-We now find that if we look into `v_new`, the value of `x` is indeed `3.0`:
-
-```{julia}
-v_new[@varname(x)]
-```
-
-and we can extract the return value and log probabilities exactly as before.
-
-Note that `init!!` always ignores any values that are already present in the VarInfo, and overwrites them with new values according to the specified strategy.
-
-If you have a loop in which you want to repeatedly evaluate a model with different parameter values, then the workflow shown here is recommended:
-
- - First generate a VarInfo using `VarInfo(model)`;
- - Then call `DynamicPPL.init!!(model, v, InitFromParams(...))` to evaluate the model using those parameters.
-
-This requires you to pay a one-time cost at the very beginning to generate the VarInfo, but subsequent evaluations will be efficient.
-DynamicPPL uses this approach when implementing functions such as `predict(model, chain)`.
-
-::: {.callout-tip}
-If you want to avoid even the first model evaluation, you will need to read on to the 'Advanced' section below.
-However, for most applications this should not necessary.
-:::
-
-## Parameters in the form of Vectors
-
-In general, one problem with `init!!` is that it is often slower than `evaluate!!`.
-This is primarily because it does more work: it has to not only read from the provided parameters, but also overwrite existing values in the VarInfo.
-
-```{julia}
-using Chairmarks, Logging
-# We need to silence the 'executing model' message, or else it will
-# fill up the entire screen!
-with_logger(ConsoleLogger(stderr, Logging.Warn)) do
-    median(@be DynamicPPL.evaluate!!(model, v_new))
-end
-```
-
-```{julia}
-with_logger(ConsoleLogger(stderr, Logging.Warn)) do
-    median(@be DynamicPPL.init!!(model, v_new, InitFromParams(Dict(@varname(x) => 3.0))))
-end
-```
-
-When evaluating models in tight loops, as is often the case in inference algorithms, this overhead can be quite unwanted.
-DynamicPPL provides a rather dangerous, but powerful, way to get around this, which is the `DynamicPPL.unflatten` function.
-`unflatten` allows you to directly modify the internal storage of a VarInfo, without having to go through `init!!` and model evaluation.
-Its input is a vector of parameters.
-
-```{julia}
-xs = [7.0]
-v_unflattened = DynamicPPL.unflatten(v_new, xs)
-v_unflattened[@varname(x)]
-```
-
-We can then directly use `v_new` in `evaluate!!`, which will use the value `7.0` for `x`:
-
-```{julia}
-retval, vout = DynamicPPL.evaluate!!(model, v_unflattened)
-```
-
-Even the combination of `unflatten` and `evaluate!!` tends to be faster than a single call to `init!!`, especially for larger models.
-
-**However, there are several reasons why this function is dangerous.
-If you use it, you must pay close attention to correctness:**
-
-1. For models with multiple variables, the order in which these variables occur in the vector is not obvious. The short answer is that it depends on the order in which the variables are added to the VarInfo during its initialisation. If you have models where the order of variables can vary from one execution to another, then `unflatten` can easily lead to incorrect results.
-
-2. The meaning of the values passed in will generally depend on whether the VarInfo is linked or not (see the [Variable Transformations page]({{< meta dev-transforms-dynamicppl >}}) for more information about linked VarInfos). You must make sure that the values passed in are consistent with the link status of the VarInfo. In contrast, `InitFromParams` always uses unlinked values.
-
-3. While `unflatten` modifies the parameter values stored in the VarInfo, it does not modify any other information, such as log probabilities. Thus, after calling `unflatten`, your VarInfo will be in an inconsistent state, and you should not attempt to read any other information from it until you have called `evaluate!!` again (which recomputes e.g. log probabilities).
-
-The inverse operation of `unflatten` is `DynamicPPL.getindex_internal(v, :)`:
-
-```{julia}
-DynamicPPL.getindex_internal(v_unflattened, :)
-```
-
-## `LogDensityFunction`
-
-There is one place where `unflatten` is (unfortunately) quite indispensable, namely, the implementation of the LogDensityProblems.jl interface for Turing models.
-
-The LogDensityProblems interface defines interface functions such as
-
-```julia
-LogDensityProblems.logdensity(f, x::AbstractVector)
-```
-
-which evaluates the log density of a model `f` given a vector of parameters `x`.
-
-Given what we have seen above, this can be done by wrapping a model and a VarInfo together inside a struct.
-Here is a rough sketch of how this can be implemented:
-
-```{julia}
-using LogDensityProblems
-
-struct MyModelLogDensity{M<:DynamicPPL.Model,V<:DynamicPPL.VarInfo}
-    model::M
-    varinfo::V
-end
-
-function LogDensityProblems.logdensity(f::MyModelLogDensity, x::AbstractVector)
-    v_new = DynamicPPL.unflatten(f.varinfo, x)
-    _, vout = DynamicPPL.evaluate!!(f.model, v_new)
-    return DynamicPPL.getlogjoint(vout)
-end
-
-# Usage
-my_ldf = MyModelLogDensity(model, VarInfo(model))
-LogDensityProblems.logdensity(my_ldf, [2.5])
-```
-
-DynamicPPL contains a `LogDensityFunction` type that, at its core, is essentially the same as the above.
-
-```{julia}
-# the varinfo object defaults to VarInfo(model)
-ldf = DynamicPPL.LogDensityFunction(model)
-LogDensityProblems.logdensity(ldf, [2.5])
-```
-
-The real implementation is a bit more complicated as it provides more options, as well as support for gradients with automatic differentiation.
-
-In this way, any Turing model can be converted into an object that you can use with LogDensityProblems-compatible optimisers, samplers, and other algorithms.
-This is very powerful as it allows the algorithms to completely ignore the internal structure of the model, and simply treat it as an opaque log-density function.
-For example, Turing's external sampler interface makes heavy use of this.
-
-However, it should be noted that because this uses `unflatten` under the hood, it suffers from exactly the same limitations as described above.
-For example, models that do not have a fixed number or order of latent variables can lead to incorrect results or errors.
-
-## Advanced: Typed and untyped VarInfo
-
-The discussion above suffices for many applications of DynamicPPL, but one question remains: how to avoid the initial overhead of constructing a VarInfo object before we can do anything useful with it.
-This is important when implementing a function such as `logjoint(model, params)`: in principle, only a single evaluation should be needed.
-
-To tackle this, we need to understand a little bit more about two kinds of VarInfo.
-Conceptually, DynamicPPL has both _typed_ and _untyped_ VarInfos.
-This distinction is also described in section 4.2.4 of [our recent Turing.jl paper](https://dl.acm.org/doi/10.1145/3711897).
-
-Evaluating a model with an existing typed VarInfo is generally much faster, and once you have a typed VarInfo it is a good idea to stick with it.
-However, when instantiating a new VarInfo, it is often better to start with an untyped VarInfo, fill in the values, and then convert it to a typed VarInfo.
-
-::: {.callout-note}
-## Why is untyped initialisation better?
-Initialising a fresh VarInfo requires adding variables to it as they are encountered during model execution.
-There are two main reasons for preferring untyped VarInfo: firstly, compilation time with typed VarInfo scales poorly with the number of variables; and secondly, typed VarInfos can error with certain kinds of models.
-See [this issue](https://github.com/TuringLang/DynamicPPL.jl/issues/1062) for more information.
-:::
-
-To see this in action, let's begin by constructing an empty _untyped_ VarInfo.
-This does not execute the model, and so the resulting object has no stored variable values.
-If we try to index into it, we will get an error:
-
-```{julia}
-#| error: true
-v_empty_untyped = VarInfo()
-v_empty_untyped[@varname(x)]
-```
-
-::: {.callout-note}
-## `VarInfo(model)` returns a typed VarInfo
-Although `VarInfo()` with no arguments returns an untyped VarInfo, note that calling `VarInfo(model)` returns a typed VarInfo. This is a slightly awkward aspect of DynamicPPL's current API.
-:::
-
-To generate new values for it, we will use `DynamicPPL.init!!` as before.
-
-```{julia}
-_, v_filled_untyped = DynamicPPL.init!!(model, v_empty_untyped, InitFromParams(Dict(@varname(x) => 5.0)))
-```
-
-Now that we have filled in the untyped VarInfo, we can access parameter values, log probabilities, and so on:
-
-```{julia}
-DynamicPPL.getlogprior(v_filled_untyped)
-```
-
-So, putting this all together, this is how an implementation of `logprior(model, params)` could look:
-
-```{julia}
-function mylogprior(model, params)
-    # Create empty untyped VarInfo
-    v_empty_untyped = VarInfo()
-    # Fill in values from given params
-    _, v_filled_untyped = DynamicPPL.init!!(model, v_empty_untyped, InitFromParams(params))
-    # Extract log prior
-    return DynamicPPL.getlogprior(v_filled_untyped)
-end
-
-mylogprior(model, Dict(@varname(x) => 5.0))
-```
-
-Notice that the above only required a single model evaluation.
-
-If we later want to convert the untyped VarInfo into a typed VarInfo (for example, for later reuse), we can do so using `DynamicPPL.typed_varinfo`:
-
-```{julia}
-v_filled_typed = DynamicPPL.typed_varinfo(v_filled_untyped)
-```
-
-This allows us to demonstrate how `VarInfo(model)` is implemented:
-
-```{julia}
-function myvarinfo(model)
-    # Create empty untyped VarInfo
-    v_empty_untyped = VarInfo()
-    # Sample values from prior
-    _, v_filled_untyped = DynamicPPL.init!!(model, v_empty_untyped, InitFromPrior())
-    # Convert to typed VarInfo
-    return DynamicPPL.typed_varinfo(v_filled_untyped)
-end
-```
-
-Notice here that `evaluate!!` runs much faster with a typed VarInfo than with untyped: this is why generally for repeated evaluation you should use a typed VarInfo.
-The same is true of `init!!`.
-
-```{julia}
-with_logger(ConsoleLogger(stderr, Logging.Warn)) do
-    median(@be DynamicPPL.evaluate!!(model, v_filled_untyped))
-end
-```
-
-```{julia}
-with_logger(ConsoleLogger(stderr, Logging.Warn)) do
-    median(@be DynamicPPL.evaluate!!(model, v_filled_typed))
-end
-```
diff --git a/developers/transforms/bijectors/index.qmd b/developers/transforms/bijectors/index.qmd
index 761bc2927..a0d41476d 100644
--- a/developers/transforms/bijectors/index.qmd
+++ b/developers/transforms/bijectors/index.qmd
@@ -337,4 +337,4 @@ println("mean: $(mean(samples_questionable_untransformed))")
 
 You can see that even though we used ten times more samples, the mean is quite wrong, which implies that our samples are not being drawn from the correct distribution.
 
-In the next page, we'll see how to use these transformations in the context of a probabilistic programming language, paying particular attention to their handling in DynamicPPL.
\ No newline at end of file
+For a discussion of how these bijectors are used in DynamicPPL, please consult [the DynamicPPL documentation itself](https://turinglang.org/DynamicPPL.jl/stable/transforms/).
diff --git a/developers/transforms/dynamicppl/dynamicppl_link.png b/developers/transforms/dynamicppl/dynamicppl_link.png
deleted file mode 100644
index 4ed51a4fd..000000000
Binary files a/developers/transforms/dynamicppl/dynamicppl_link.png and /dev/null differ
diff --git a/developers/transforms/dynamicppl/dynamicppl_link2.png b/developers/transforms/dynamicppl/dynamicppl_link2.png
deleted file mode 100644
index 5b99f542d..000000000
Binary files a/developers/transforms/dynamicppl/dynamicppl_link2.png and /dev/null differ
diff --git a/developers/transforms/dynamicppl/index.qmd b/developers/transforms/dynamicppl/index.qmd
deleted file mode 100644
index ef502fdda..000000000
--- a/developers/transforms/dynamicppl/index.qmd
+++ /dev/null
@@ -1,392 +0,0 @@
----
-title: "Variable transformations in DynamicPPL"
-engine: julia
----
-
-```{julia}
-#| echo: false
-#| output: false
-using Pkg;
-Pkg.instantiate();
-```
-
-In the final part of this chapter, we will discuss the higher-level implications of constrained distributions in the Turing.jl framework.
-
-## Linked and unlinked VarInfos in DynamicPPL
-
-```{julia}
-import Random
-Random.seed!(468);
-
-# Turing re-exports the entirety of Distributions
-using Turing
-```
-
-When we are performing Bayesian inference, we are trying to sample from a joint probability distribution, which isn't usually a single, well-defined distribution like in the rather simplified example above.
-However, each random variable in the model will have its own distribution, and often some of these will be constrained.
-For example, if `b ~ LogNormal()` is a random variable in a model, then $p(b)$ will be zero for any $b \leq 0$.
-Consequently, any joint probability $p(b, c, \ldots)$ will also be zero for any combination of parameters where $b \leq 0$, and so that joint distribution is itself constrained.
-
-To get around this, DynamicPPL allows the variables to be transformed in exactly the same way as above.
-For simplicity, consider the following model:
-
-```{julia}
-using DynamicPPL
-
-@model function demo()
-    x ~ LogNormal()
-end
-
-model = demo()
-vi = VarInfo(model)
-vn_x = @varname(x)
-# Retrieve the 'internal' representation of x – we'll explain this later
-DynamicPPL.getindex_internal(vi, vn_x)
-```
-
-The call to `VarInfo` executes the model once and stores the sampled value inside `vi`.
-By default, `VarInfo` itself stores un-transformed values.
-We can see this by comparing the value of the logpdf stored inside the `VarInfo`:
-
-```{julia}
-DynamicPPL.getlogp(vi)
-```
-
-with a manual calculation:
-
-```{julia}
-logpdf(LogNormal(), DynamicPPL.getindex_internal(vi, vn_x))
-```
-
-In DynamicPPL, the `link` function can be used to transform the variables.
-This function does three things: first, it transforms the variables; secondly, it updates the value of logp (by adding the Jacobian term); and thirdly, it sets a flag on the variables to indicate that it has been transformed.
-Note that this acts on _all_ variables in the model, including unconstrained ones.
-(Unconstrained variables just have an identity transformation.)
-
-```{julia}
-vi_linked = DynamicPPL.link(vi, model)
-println("Transformed value: $(DynamicPPL.getindex_internal(vi_linked, vn_x))")
-println("Transformed logp: $(DynamicPPL.getlogp(vi_linked))")
-println("Transformed flag: $(DynamicPPL.is_transformed(vi_linked, vn_x))")
-```
-
-Indeed, we can see that the new logp value matches with
-
-```{julia}
-logpdf(Normal(), DynamicPPL.getindex_internal(vi_linked, vn_x))
-```
-
-The reverse transformation, `invlink`, reverts all of the above steps:
-
-```{julia}
-vi = DynamicPPL.invlink(vi_linked, model)  # Same as the previous vi
-println("Un-transformed value: $(DynamicPPL.getindex_internal(vi, vn_x))")
-println("Un-transformed logp: $(DynamicPPL.getlogp(vi))")
-println("Un-transformed flag: $(DynamicPPL.is_transformed(vi, vn_x))")
-```
-
-### Model and internal representations
-
-In DynamicPPL, there is a difference between the value of a random variable and its 'internal' value.
-This is most easily seen by first transforming, and then comparing the output of `getindex` and `getindex_internal`.
-The former extracts the regular value, which we call the **model representation** (because it is consistent with the distribution specified in the model).
-The latter, as the name suggests, gets the **internal representation** of the variable, which is how it is actually stored in the VarInfo object.
-
-```{julia}
-println("   Model representation: $(getindex(vi_linked, vn_x))")
-println("Internal representation: $(DynamicPPL.getindex_internal(vi_linked, vn_x))")
-```
-
-::: {.callout-note}
-Note that `vi_linked[vn_x]` can also be used as shorthand for `getindex(vi_linked, vn_x)`; this usage is common in the DynamicPPL/Turing codebase.
-:::
-
-We can see (for this linked varinfo) that there are _two_ differences between these outputs:
-
-1. _The internal representation has been transformed using the bijector (in this case, the log function)._
-   This means that the `is_transformed()` flag which we used above doesn't modify the model representation: it only tells us whether the internal representation has been transformed or not.
-
-2. _The internal representation is a vector, whereas the model representation is a scalar._
-   This is because in DynamicPPL, _all_ internal values are vectorised (i.e. converted into some vector), regardless of distribution. On the other hand, since the model specifies a univariate distribution, the model representation is a scalar.
-
-One might also ask, what is the internal representation for an _unlinked_ varinfo?
-
-```{julia}
-println("   Model representation: $(getindex(vi, vn_x))")
-println("Internal representation: $(DynamicPPL.getindex_internal(vi, vn_x))")
-```
-
-For an unlinked VarInfo, the internal representation is vectorised, but not transformed.
-We call this an **unlinked internal representation**; conversely, when the VarInfo has been linked, each variable will have a corresponding **linked internal representation**.
-
-This sequence of events is summed up in the following diagram, where `f(..., args)` indicates that the `...` is to be replaced with the object at the beginning of the arrow:
-
-![Functions related to variable transforms in DynamicPPL](./dynamicppl_link.png)
-
-In the final part of this article, we will take a more in-depth look at the internal DynamicPPL machinery that allows us to convert between representations and obtain the correct probability densities.
-Before that, though, we will take a quick high-level look at how the HMC sampler in Turing.jl uses the functions introduced so far.
-
-## HMC in Turing.jl
-
-While DynamicPPL provides the _functionality_ for transforming variables, the transformation itself happens at an even higher level, i.e. in the sampler itself.
-The HMC sampler in Turing.jl is in [this file](https://github.com/TuringLang/Turing.jl/blob/5b24cebe773922e0f3d5c4cb7f53162eb758b04d/src/mcmc/hmc.jl).
-
-In the first step of sampling, it calls `link` on the sampler.
-What this means is that from the perspective of the HMC sampler, it _never_ sees the constrained variable: it always thinks that it is sampling from an unconstrained distribution.
-
-The biggest prerequisite for this to work correctly is that the potential energy term in the Hamiltonian—or in other words, the model log density—must be programmed correctly to include the Jacobian term.
-This is exactly the same as how we had to make sure to define `logq(y)` correctly in the toy HMC example above.
-
-Within Turing.jl, this is correctly handled by calling
-
-```julia
-x, inv_logjac = with_logabsdet_jacobian(y, inverse_transform)
-```
-
-and then passing `inv_logjac` to DynamicPPL's `LogJacobianAccumulator`.
-
-## A deeper dive into DynamicPPL's internal machinery
-
-As described above, DynamicPPL stores a (possibly linked) _internal representation_ which is accessible via `getindex_internal`, but can also provide users with the original, untransformed, _model representation_ via `getindex`.
-This abstraction allows the user to obtain samples from constrained distributions without having to perform the transformation themselves.
-
-![More functions related to variable transforms in DynamicPPL](./dynamicppl_link2.png)
-
-The conversion between these representations is done using several internal functions in DynamicPPL, as depicted in the above diagram.
-The following operations are labelled:
-
-1. This is linking, i.e. transforming a constrained variable to an unconstrained one.
-
-2. This is vectorisation: for example, converting a scalar value to a 1-element vector.
-
-3. This arrow brings us from the model representation to the linked internal representation.
-   This is the composition of (1) and (2): linking and then vectorising.
-
-4. This arrow brings us from the model representation to the unlinked internal representation.
-   This only requires a single step, vectorisation.
-
-Each of these steps can be accomplished using the following functions.
-
-|     | To get the function | To get the inverse function |
-| --- | ------------------- | --------------------------- |
-| (1) | `link_transform(dist)` | `invlink_transform(dist)` |
-| (2) | `to_vec_transform(dist)` | `from_vec_transform(dist)` |
-| (3) | `to_linked_internal_transform(vi, vn[, dist])` | `from_linked_internal_transform(vi, vn[, dist])` |
-| (4) | `to_internal_transform(vi, vn[, dist])` | `from_internal_transform(vi, vn[, dist])` |
-
-Note that these functions do not perform the actual transformation; rather, they return the transformation function itself.
-For example, let's take a look at the `VarInfo` from the previous section, which contains a single variable `x ~ LogNormal()`.
-
-```{julia}
-model_repn = vi[vn_x]
-```
-
-```{julia}
-# (1) Get the link function
-f_link = DynamicPPL.link_transform(LogNormal())
-# (2) Get the vectorise function
-f_vec = DynamicPPL.to_vec_transform(LogNormal())
-
-# Apply it to the model representation
-linked_internal_repn = f_vec(f_link(model_repn))
-```
-
-Equivalently, we could have done:
-
-```{julia}
-# (3) Get the linked internal transform function
-f_linked_internal = DynamicPPL.to_linked_internal_transform(vi, vn_x, LogNormal())
-
-# Apply it to the model representation
-linked_internal_repn = f_linked_internal(model_repn)
-```
-
-And let's confirm that this is the same as the linked internal representation, using the `VarInfo` that we linked earlier:
-
-```{julia}
-DynamicPPL.getindex_internal(vi_linked, vn_x)
-```
-
-The purpose of having all of these machinery is to allow other parts of DynamicPPL, such as the tilde pipeline, to handle transformed variables correctly.
-The following diagram shows how `assume` first checks whether the variable is transformed (using `is_transformed`), and then applies the appropriate transformation function.
-
-<!-- 'wrappingWidth' setting required because of https://github.com/mermaid-js/mermaid-cli/issues/112#issuecomment-2352670995 -->
-```{mermaid}
-%%| echo: false
-
-%%{ init: { 'themeVariables': { 'lineColor': '#000000' } } }%%
-%%{ init: { 'flowchart': { 'curve': 'linear', 'wrappingWidth': -1 } } }%%
-graph TD
-    A["x ~ LogNormal()"]:::boxStyle
-    B["vn = <span style='color:#3B6EA8 !important;'>@varname</span>(x)<br>dist = LogNormal()<br>x, vi = ..."]:::boxStyle
-    C["assume(vn, dist, vi)"]:::boxStyle
-    D(["<span style='color:#3B6EA8 !important;'>if</span> is_transformed(vi, vn)"]):::boxStyle
-    E["f = from_internal_transform(vi, vn, dist)"]:::boxStyle
-    F["f = from_linked_internal_transform(vi, vn, dist)"]:::boxStyle
-    G["<span style='color:#3B6EA8 !important;'>x, logjac = with_logabsdet_jacobian(f, getindex_internal(vi, vn, dist))</span>"]:::boxStyle
-    H["<span style='color:#3B6EA8 !important;'>return</span> x, logpdf(dist, x) - logjac, vi"]:::boxStyle
-    
-    A -.->|<span style='color:#3B6EA8 ; background-color:#ffffff;'>@model</span>| B
-    B -.->|<span style='color:#000000 ; background-color:#ffffff;'>tilde-pipeline</span>| C
-    C --> D
-    D -->|<span style='color:#97365B ; background-color:#ffffff;'>false</span>| E
-    D -->|<span style='color:#97365B ; background-color:#ffffff;'>true</span>| F
-    E --> G
-    F --> G
-    G --> H
-
-    classDef boxStyle fill:#ffffff,stroke:#000000,font-family:Courier,color:#000000
-    linkStyle default stroke:#000000,stroke-width:1px,color:#000000
-```
-
-Here, `with_logabsdet_jacobian` is defined [in the ChangesOfVariables.jl package](https://juliamath.github.io/ChangesOfVariables.jl/stable/api/#ChangesOfVariables.with_logabsdet_jacobian), and returns both the effect of the transformation `f` as well as the log Jacobian term.
-
-Because we chose `f` appropriately, we find here that `x` is always the model representation; furthermore, if the variable was _not_ linked (i.e. `is_transformed` was false), the log Jacobian term will be zero.
-However, if it was linked, then the Jacobian term would be appropriately included, making sure that sampling proceeds correctly.
-
-## Why do we need to do this at runtime?
-
-Given that we know whether a `VarInfo` is linked or not, one might wonder why we need both `from_internal_transform` and `from_linked_internal_transform` at the point where the model is evaluated.
-Could we not, for example, store the required transformation inside the `VarInfo` when we link it, and simply reuse that each time?
-
-That is, why can't we just do
-
-```{mermaid}
-%%| echo: false
-%%| fig-width: 5
-
-%%{ init: { 'flowchart': { 'curve': 'linear', 'wrappingWidth': -1 } } }%%
-%%{ init: { 'themeVariables': { 'lineColor': '#000000' } } }%%
-graph TD
-      A["assume(varinfo, <span style='color:#3B6EA8 !important;'>@varname</span>(x), Normal())"]:::boxStyle
-      B["f = from_internal_transform(varinfo, varname, dist)"]:::boxStyle
-      C["x, logjac = with_logabsdet_jacobian(f, getindex_internal(varinfo, varname))"]:::boxStyle
-      D["<span style='color:#3B6EA8 !important;'>return</span> x, logpdf(dist, x) - logjac, varinfo"]:::dashedBox
-      
-      A --> B
-      B --> C
-      C --> D
-
-    classDef dashedBox fill:#ffffff,stroke:#000000,stroke-dasharray: 5 5,font-family:Courier,color:#000000
-    classDef boxStyle fill:#ffffff,stroke:#000000,font-family:Courier,color:#000000
-
-    linkStyle default stroke:#000000,stroke-width:1px,color:#000000
-```
-
-where `from_internal_transform` here only looks up a stored transformation function?
-
-Unfortunately, this is not possible in general, because the transformation function might not be a constant between different model evaluations.
-Consider, for example, the following model:
-
-```{julia}
-@model function demo_dynamic_constraint()
-    m ~ Normal()
-    x ~ truncated(Normal(); lower=m)
-    return (m=m, x=x)
-end
-```
-
-Here, `m` is distributed according to a plain `Normal()`, whereas the variable `x` is constrained to be in the domain `(m, Inf)`.
-Because of this, we expect that any time we sample from the model, we should have that `m < x` (in terms of their model representations):
-
-```{julia}
-model = demo_dynamic_constraint()
-vi = VarInfo(model)
-vn_m, vn_x = @varname(m), @varname(x)
-
-vi[vn_m], vi[vn_x]
-```
-
-(Note that `vi[vn]` is a shorthand for `getindex(vi, vn)`, so this retrieves the model representations of `m` and `x`.)
-So far, so good.
-Let's now link this `VarInfo` so that we end up working in an 'unconstrained' space, where both `m` and `x` can take on any values in `(-Inf, Inf)`.
-First, we should check that the model representations are unchanged when linking:
-
-```{julia}
-vi_linked = link(vi, model)
-vi_linked[vn_m], vi_linked[vn_x]
-```
-
-But if we change the value of `m`, to, say, a bit larger than `x`:
-
-```{julia}
-# Update the model representation for `m` in `vi_linked`.
-vi_linked[vn_m] = vi_linked[vn_x] + 1
-vi_linked[vn_m], vi_linked[vn_x]
-```
-
-::: {.callout-warning}
-This is just for demonstration purposes!
-You shouldn't be directly setting variables in a linked `varinfo` like this unless you know for a fact that the value will be compatible with the constraints of the model.
-:::
-
-Now, we see that the constraint `m < x` is no longer satisfied.
-Hence, one might expect that if we try to evaluate the model using this `VarInfo`, we should obtain an error.
-Here, `evaluate!!` returns two things: the model's return value itself (which we defined above to be a `NamedTuple`), and the resulting `VarInfo` post-evaluation.
-
-```{julia}
-retval, ret_varinfo = DynamicPPL.evaluate!!(model, vi_linked)
-getlogp(ret_varinfo)
-```
-
-But we don't get any errors!
-Indeed, we could even calculate the 'log probability density' for this evaluation.
-
-To understand this, we need to look at the actual value which was used during the model evaluation.
-We can glean this from the return value (or from the returned `VarInfo`, but the former is easier):
-
-```{julia}
-retval
-```
-
-We can see here that the model evaluation used the value of `m` that we provided, but the value of `x` was 'updated'.
-
-The reason for this is that internally in a model evaluation, we construct the transformation function from the internal to the model representation based on the *current* realizations in the model!
-That is, we take the `dist` in a `x ~ dist` expression _at model evaluation time_ and use that to construct the transformation, thus allowing it to change between model evaluations without invalidating the transformation.
-
-Knowing that the distribution of `x` depends on the value of `m`, we can now understand how the model representation of `x` got updated.
-The linked `VarInfo` does not store the model representation of `x`, but only its linked internal representation.
-So, what happened during the model evaluation above was that the linked internal representation of `x` – which was constructed using the _original_ value of `m` – was transformed back into a new model representation using a _different_ value of `m`.
-
-We can reproduce the 'new' value of `x` by performing these transformations manually:
-
-```{julia}
-# Generate a fresh linked VarInfo (without the new / 'corrupted' values)
-vi_linked = link(vi, model)
-# See the linked internal representations
-DynamicPPL.getindex_internal(vi_linked, vn_m), DynamicPPL.getindex_internal(vi_linked, vn_x)
-```
-
-Now we update the value of `m` like we did before:
-
-```{julia}
-vi_linked[vn_m] = vi_linked[vn_x] + 1
-vi_linked[vn_m]
-```
-
-When evaluating the model, the distribution of `x` is now changed, and so is the corresponding inverse bijector:
-
-```{julia}
-new_dist_x = truncated(Normal(); lower=vi_linked[vn_m])
-new_f_inv = DynamicPPL.invlink_transform(new_dist_x)
-```
-
-and if we apply this to the internal representation of `x`:
-
-```{julia}
-new_f_inv(DynamicPPL.getindex_internal(vi_linked, vn_x))
-```
-
-which is the same value as we got above in `retval`.
-
-## Conclusion
-
-In this chapter of the Turing docs, we've looked at:
-
-- why variables might need to be transformed;
-- how this is accounted for mathematically with the Jacobian term;
-- the basic API and functionality of Bijectors.jl; and
-- the higher-level usage of transforms in DynamicPPL and Turing.
-
-This will hopefully have equipped you with a better understanding of how constrained variables are handled in the Turing framework.
-With this knowledge, you should especially find it easier to navigate DynamicPPL's `VarInfo` type, which forms the backbone of model evaluation.
diff --git a/tutorials/bayesian-differential-equations/index.qmd b/tutorials/bayesian-differential-equations/index.qmd
index 40400e0aa..ab2e5ed0c 100755
--- a/tutorials/bayesian-differential-equations/index.qmd
+++ b/tutorials/bayesian-differential-equations/index.qmd
@@ -18,9 +18,14 @@ In practice, these equations often have unknown parameters we would like to esti
 The "[forward problem](https://en.wikipedia.org/wiki/Well-posed_problem)" of simulation consists of solving the differential equations for a given set of parameters, while the "[inverse problem](https://en.wikipedia.org/wiki/Inverse_problem)" of parameter estimation uses observed data to infer the unknown model parameters.
 Bayesian inference provides a robust approach to parameter estimation with quantified uncertainty.
 
+[DifferentialEquations.jl](https://docs.sciml.ai/DiffEqDocs/stable/) is the main Julia package for numerically solving differential equations.
+Its functionality is completely interoperable with Turing.jl, which means that we can directly simulate differential equations inside a Turing `@model`.
+DifferentialEquations.jl itself is an extremely large package.
+To avoid loading parts that we don't need, for now we'll only load a sub-component of it, OrdinaryDiffEq.jl.
+
 ```{julia}
 using Turing
-using DifferentialEquations
+using OrdinaryDiffEq
 # Load StatsPlots for visualizations and diagnostics.
 using StatsPlots
 using LinearAlgebra
@@ -99,9 +104,6 @@ For this tutorial, though, we will stick with simulated data.
 
 ## Direct Handling of Bayesian Estimation with Turing
 
-[DifferentialEquations.jl](https://docs.sciml.ai/DiffEqDocs/stable/) is the main Julia package for numerically solving differential equations.
-Its functionality is completely interoperable with Turing.jl, which means that we can directly simulate differential equations inside a Turing `@model`.
-
 For the purposes of this tutorial, we choose priors for the parameters that are quite close to the ground truth.
 As justification, we can imagine we have preexisting estimates for the biological rates.
 Practically, this helps us to illustrate the results without needing to run overly long MCMC chains.
@@ -240,11 +242,15 @@ $$
 where $\tau$ is a (positive) delay and $x(t-\tau)$ is the variable $x$ at an earlier time point $t - \tau$.
 
 The initial-value problem of the delayed system can be implemented as a `DDEProblem`.
+To use this, we'll have to load a different sub-package of the SciML ecosystem, [DelayDiffEq.jl](https://docs.sciml.ai/DelayDiffEq/stable/).
+
 As described in the [DDE example](https://diffeq.sciml.ai/stable/tutorials/dde_example/), here the function `h` is the history function that can be used to obtain a state at an earlier time point.
 Again we use parameters $\alpha = 1.5$, $\beta = 1$, $\gamma = 3$, and $\delta = 1$ and initial conditions $x(0) = y(0) = 1$.
 Moreover, we assume $x(t) = 1$ for $t < 0$.
 
 ```{julia}
+using DelayDiffEq
+
 function delay_lotka_volterra(du, u, h, p, t)
     # Model parameters.
     α, β, γ, δ = p
diff --git a/tutorials/bayesian-logistic-regression/index.qmd b/tutorials/bayesian-logistic-regression/index.qmd
index 8d46cf9ad..2ab4e04e2 100755
--- a/tutorials/bayesian-logistic-regression/index.qmd
+++ b/tutorials/bayesian-logistic-regression/index.qmd
@@ -21,20 +21,12 @@ In our example, we'll be working to predict whether someone is likely to default
 To start, let's import all the libraries we'll need.
 
 ```{julia}
-# Import Turing and Distributions.
-using Turing, Distributions
-
-# Import RDatasets.
+using Turing
 using RDatasets
-
-# Import MCMCChains, Plots, and StatsPlots for visualisations and diagnostics.
 using MCMCChains, Plots, StatsPlots
-
-# We need a logistic function, which is provided by StatsFuns.
 using StatsFuns: logistic
-
-# Functionality for splitting and normalising the data
-using MLDataUtils: shuffleobs, stratifiedobs, rescale!
+using MLUtils: splitobs
+using StatsBase: fit, transform!, ZScoreTransform
 
 # Set a seed for reproducibility.
 using Random
@@ -43,7 +35,8 @@ Random.seed!(0);
 
 ## Data Cleaning & Set Up
 
-Now we're going to import our dataset. The first six rows of the dataset are shown below so you can get a good feel for what kind of data we have.
+Now we're going to import our dataset.
+The first six rows of the dataset are shown below so you can get a good feel for what kind of data we have.
 
 ```{julia}
 # Import the "Default" dataset.
@@ -53,12 +46,15 @@ data = RDatasets.dataset("ISLR", "Default");
 first(data, 6)
 ```
 
-Most machine learning processes require some effort to tidy up the data, and this is no different. We need to convert the `Default` and `Student` columns, which say "Yes" or "No" into 1s and 0s. Afterwards, we'll get rid of the old words-based columns.
+Most machine learning processes require some effort to tidy up the data, and this is no different.
+We need to convert the `Default` and `Student` columns, which say "Yes" or "No" into 1s and 0s.
+Afterwards, we'll get rid of the old words-based columns.
 
 ```{julia}
 # Convert "Default" and "Student" to numeric values.
-data[!, :DefaultNum] = [r.Default == "Yes" ? 1.0 : 0.0 for r in eachrow(data)]
-data[!, :StudentNum] = [r.Student == "Yes" ? 1.0 : 0.0 for r in eachrow(data)]
+yesno = ["No", "Yes"]
+data[!, :DefaultNum] = indexin(data[!, :Default], yesno) .- 1
+data[!, :StudentNum] = indexin(data[!, :Student], yesno) .- 1
 
 # Delete the old columns which say "Yes" and "No".
 select!(data, Not([:Default, :Student]))
@@ -67,31 +63,40 @@ select!(data, Not([:Default, :Student]))
 first(data, 6)
 ```
 
-After we've done that tidying, it's time to split our dataset into training and testing sets, and separate the labels from the data. We separate our data into two halves, `train` and `test`. You can use a higher percentage of splitting (or a lower one) by modifying the `at = 0.05` argument. We have highlighted the use of only a 5% sample to show the power of Bayesian inference with small sample sizes.
+Our predictor variables are `StudentNum`, `Balance`, and `Income`, and our target variable is `DefaultNum`; we separate those out into `X` and `Y` for ease of use later on.
+We'll also convert them to `Matrix` and `Vector` types, respectively, by wrapping them in `Array`.
+
+```{julia}
+# `splitobs` later expects that `X` has observations in columns,
+# hence the transpose on `X`.
+X = Array(data[!, [:StudentNum, :Balance, :Income]])'
+Y = Array(data[!, :DefaultNum])
+size(X), size(Y)
+```
 
-We must rescale our variables so that they are centred around zero by subtracting each column by the mean and dividing it by the standard deviation. This rescaling ensures features are on comparable scales, which improves sampler initialisation and convergence. To do this we will leverage `MLDataUtils`, which also lets us effortlessly shuffle our observations and perform a [stratified split](https://en.wikipedia.org/wiki/Stratified_sampling) to get a representative test set.
+It's now time to split our dataset into training and testing sets.
+We separate our data into two partitions, `train` and `test`.
+You can use a higher percentage of splitting (or a lower one) by modifying the `at = 0.05` argument.
+Here, we are training on only 5% of the data in order to highlight the power of Bayesian inference with small sample sizes.
+To do the splitting we will leverage `MLUtils`, which also lets us effortlessly shuffle our observations and perform a [stratified split](https://en.wikipedia.org/wiki/Stratified_sampling) to get a representative test set.
 
 ```{julia}
-function split_data(df, target; at=0.70)
-    shuffled = shuffleobs(df)
-    return trainset, testset = stratifiedobs(row -> row[target], shuffled; p=at)
-end
+(train_X, train_Y), (test_X, test_Y) = splitobs((X, Y); at=0.05, shuffle=true, stratified=Y)
 
-features = [:StudentNum, :Balance, :Income]
-numerics = [:Balance, :Income]
-target = :DefaultNum
+# Let's check that the labels are distributed
+# similarly in the training and test sets.
+mean(train_Y), mean(test_Y)
+```
 
-trainset, testset = split_data(data, target; at=0.05)
-for feature in numerics
-    μ, σ = rescale!(trainset[!, feature]; obsdim=1)
-    rescale!(testset[!, feature], μ, σ; obsdim=1)
-end
+We must now rescale our numeric variables so that they are centred around zero by subtracting each column by the mean and dividing it by the standard deviation.
+This rescaling ensures features are on comparable scales, which improves sampler initialisation and convergence.
 
-# Turing requires data in matrix form, not dataframe
-train = Matrix(trainset[:, features])
-test = Matrix(testset[:, features])
-train_label = trainset[:, target]
-test_label = testset[:, target];
+Note here that we leave out the `StudentNum` variable (row 1) from the normalisation, since it is already binary and doesn't need to be rescaled.
+
+```{julia}
+dt = fit(ZScoreTransform, view(train_X, 2:3, :); dims=2)
+transform!(dt, view(train_X, 2:3, :))
+transform!(dt, view(test_X, 2:3, :))
 ```
 
 ## Model Declaration
@@ -102,24 +107,25 @@ Finally, we can define our model.
 
   - `x` is our set of independent variables;
   - `y` is the element we want to predict;
-  - `n` is the number of observations we have; and
-  - `σ` is the standard deviation we want to assume for our priors.
+  - `σ` is the (fixed) standard deviation we want to assume for our priors.
 
-Within the model, we create four coefficients (`intercept`, `student`, `balance`, and `income`) and assign a prior of normally distributed with means of zero and standard deviations of `σ`. We want to find values of these four coefficients to predict any given `y`.
+Within the model, we create four coefficients (`intercept`, `student`, `balance`, and `income`) and assign a prior of normally distributed with means of zero and standard deviations of `σ`.
+We want to find values of these four coefficients to predict any given `y`.
 
 The `for` block creates a variable `v` which is the logistic function. We then observe the likelihood of calculating `v` given the actual label, `y[i]`.
 
 ```{julia}
-# Bayesian logistic regression (LR)
-@model function logistic_regression(x, y, n, σ)
-    intercept ~ Normal(0, σ)
+@model function logistic_regression(x, y, σ)
+    N = size(x, 2)
+    @assert length(y) == N
 
+    intercept ~ Normal(0, σ)
     student ~ Normal(0, σ)
     balance ~ Normal(0, σ)
     income ~ Normal(0, σ)
 
-    for i in 1:n
-        v = logistic(intercept + student * x[i, 1] + balance * x[i, 2] + income * x[i, 3])
+    for i in 1:N
+        v = logistic(intercept + student * x[1, i] + balance * x[2, i] + income * x[3, i])
         y[i] ~ Bernoulli(v)
     end
 end;
@@ -127,7 +133,8 @@ end;
 
 ## Sampling
 
-Now we can run our sampler. This time we'll use [`NUTS`](https://turinglang.org/stable/docs/library/#Turing.Inference.NUTS) to sample from our posterior.
+Now we can run our sampler.
+Here we'll use [`NUTS`](https://turinglang.org/stable/docs/library/#Turing.Inference.NUTS) to sample from our posterior.
 
 ```{julia}
 #| output: false
@@ -135,24 +142,16 @@ setprogress!(false)
 ```
 
 ```{julia}
-#| output: false
-# Retrieve the number of observations.
-n, _ = size(train)
-
 # Sample using NUTS.
-m = logistic_regression(train, train_label, n, 1)
+m = logistic_regression(train_X, train_Y, 1.0)
 chain = sample(m, NUTS(), MCMCThreads(), 1_500, 3)
 ```
 
-```{julia}
-#| echo: false
-chain
-```
-
-::: {.callout-warning collapse="true"}
+::: {.callout-warning}
 ## Sampling With Multiple Threads
-The `sample()` call above assumes that you have at least `nchains` threads available in your Julia instance. If you do not, the multiple chains 
-will run sequentially, and you may notice a warning. For more information, see [the Turing documentation on sampling multiple chains.]({{<meta core-functionality>}}#sampling-multiple-chains)
+The `sample()` call above assumes that you have at least `nchains` threads available in your Julia instance.
+If you do not, the multiple chains will run sequentially, and you may notice a warning.
+For more information, see [the Turing documentation on sampling multiple chains]({{<meta core-functionality>}}#sampling-multiple-chains).
 :::
 
 ```{julia}
@@ -185,7 +184,7 @@ end
 
 Looks good!
 
-We can also use the `corner` function from MCMCChains to show the distributions of the various parameters of our logistic regression.
+We can also use the `corner` function from StatsPlots to show the distributions of the various parameters of our logistic regression.
 
 ```{julia}
 # The labels to use.
@@ -199,60 +198,65 @@ Fortunately the corner plot appears to demonstrate unimodal distributions for ea
 
 ## Making Predictions
 
-How do we test how well the model actually predicts whether someone is likely to default? We need to build a prediction function that takes the `test` object we made earlier and runs it through the average parameter calculated during sampling.
+How do we test how well the model actually predicts whether someone is likely to default?
+We need to build a prediction function that takes the `test` object we made earlier and runs it through the average parameter calculated during sampling.
 
-The `prediction` function below takes a `Matrix` and a `Chain` object. It takes the mean of each parameter's sampled values and re-runs the logistic function using those mean values for every element in the test set.
+The `prediction` function below takes a `Matrix` and a `Chain` object.
+It takes the mean of each parameter's sampled values and re-runs the logistic function using those mean values for every element in the test set.
 
 ```{julia}
-function prediction(x::Matrix, chain, threshold)
+using MCMCChains: MCMCChains
+
+function prediction(x::AbstractMatrix, chain::MCMCChains.Chains, threshold)
     # Pull the means from each parameter's sampled values in the chain.
     intercept = mean(chain[:intercept])
     student = mean(chain[:student])
     balance = mean(chain[:balance])
     income = mean(chain[:income])
 
-    # Retrieve the number of rows.
-    n, _ = size(x)
+    # Retrieve the number of observations.
+    n = size(x, 2)
 
     # Generate a vector to store our predictions.
-    v = Vector{Float64}(undef, n)
+    v = Vector{Bool}(undef, n)
 
     # Calculate the logistic function for each element in the test set.
     for i in 1:n
         num = logistic(
-            intercept .+ student * x[i, 1] + balance * x[i, 2] + income * x[i, 3]
+            intercept .+ student * x[1, i] + balance * x[2, i] + income * x[3, i]
         )
-        if num >= threshold
-            v[i] = 1
-        else
-            v[i] = 0
-        end
+        v[i] = num >= threshold
     end
     return v
-end;
+end
 ```
 
-Let's see how we did! We run the test matrix through the prediction function, and compute the [mean squared error](https://en.wikipedia.org/wiki/Mean_squared_error) (MSE) for our prediction. The `threshold` variable sets the decision boundary for classification. For example, a threshold of 0.07 will predict a default (value of 1) for any predicted probability greater than 0.07 and no default otherwise. Lower thresholds increase sensitivity but may increase false positives.
+Let's see how we did!
+We run the test matrix through the prediction function, and compute the [mean squared error](https://en.wikipedia.org/wiki/Mean_squared_error) (MSE) for our prediction.
+The `threshold` variable sets the decision boundary for classification.
+For example, a threshold of 0.07 will predict a default (value of 1) for any predicted probability greater than 0.07 and no default otherwise.
+Lower thresholds increase sensitivity but may increase false positives.
 
 ```{julia}
 # Set the prediction threshold.
 threshold = 0.07
 
 # Make the predictions.
-predictions = prediction(test, chain, threshold)
+predictions = prediction(test_X, chain, threshold)
 
 # Calculate MSE for our test set.
-loss = sum((predictions - test_label) .^ 2) / length(test_label)
+loss = sum((predictions - test_Y) .^ 2) / length(test_Y)
 ```
 
-Perhaps more important is to see what percentage of defaults we correctly predicted. The code below simply counts defaults and predictions and presents the results.
+Perhaps more important is to see what percentage of defaults we correctly predicted.
+The code below simply counts defaults and predictions and presents the results.
 
 ```{julia}
-defaults = sum(test_label)
-not_defaults = length(test_label) - defaults
+defaults = sum(test_Y)
+not_defaults = length(test_Y) - defaults
 
-predicted_defaults = sum(test_label .== predictions .== 1)
-predicted_not_defaults = sum(test_label .== predictions .== 0)
+predicted_defaults = sum(test_Y .== predictions .== 1)
+predicted_not_defaults = sum(test_Y .== predictions .== 0)
 
 println("Defaults: $defaults
     Predictions: $predicted_defaults
@@ -271,6 +275,5 @@ let
 end
 ```
 
-The above shows that with a threshold of 0.07, we correctly predict a respectable portion of the defaults, and correctly identify most non-defaults. This is fairly sensitive to a choice of threshold, and you may wish to experiment with it.
-
-This tutorial has demonstrated how to use Turing to perform Bayesian logistic regression.
\ No newline at end of file
+The above shows that with a threshold of 0.07, we correctly predict a respectable portion of the defaults, and correctly identify most non-defaults.
+This is fairly sensitive to a choice of threshold, and you may wish to experiment with it.
diff --git a/tutorials/bayesian-time-series-analysis/index.qmd b/tutorials/bayesian-time-series-analysis/index.qmd
index 1e8846c68..80399e64a 100755
--- a/tutorials/bayesian-time-series-analysis/index.qmd
+++ b/tutorials/bayesian-time-series-analysis/index.qmd
@@ -156,7 +156,7 @@ Finally, we plot prior predictive samples to make sure our priors make sense.
 end
 
 y_prior_samples = mapreduce(hcat, 1:100) do _
-    rand(decomp_model(t, cyclic_features, +)).y
+    rand(decomp_model(t, cyclic_features, +))[@varname(y)]
 end
 plot(t, y_prior_samples; linewidth=1, alpha=0.5, color=1, label="", title="Prior samples")
 scatter!(t, yf; color=2, label="Data")
@@ -297,7 +297,7 @@ Since we wrote our model to accept a combining operator, we can easily run the s
 yg = g.(t) .+ σ_true .* randn(size(t))
 
 y_prior_samples = mapreduce(hcat, 1:100) do _
-    rand(decomp_model(t, cyclic_features, .*)).y
+    rand(decomp_model(t, cyclic_features, .*))[@varname(y)]
 end
 plot(t, y_prior_samples; linewidth=1, alpha=0.5, color=1, label="", title="Prior samples")
 scatter!(t, yf; color=2, label="Data")
diff --git a/tutorials/gaussian-mixture-models/index.qmd b/tutorials/gaussian-mixture-models/index.qmd
index 217d56c6e..aaea5f5e0 100755
--- a/tutorials/gaussian-mixture-models/index.qmd
+++ b/tutorials/gaussian-mixture-models/index.qmd
@@ -336,9 +336,18 @@ model = gmm_marginalized(x);
 
 As we have summed out the discrete components, we can perform inference using `NUTS()` alone.
 
+:::{.callout-warning}
+# ForwardDiff
+
+In this example we are using Mooncake.jl as the automatic differentiation backend for `NUTS()`.
+If you want to replicate this Turing's default ForwardDiff backend, you will need to [enable NaN-safe mode](https://juliadiff.org/ForwardDiff.jl/stable/user/advanced/#Fixing-NaN/Inf-Issues), or else the `gmm_recover` model can run into issues with NaN values.
+:::
+
 ```{julia}
 #| output: false
-sampler = NUTS()
+import Mooncake
+
+sampler = NUTS(; adtype=AutoMooncake())
 chains = sample(model, sampler, MCMCThreads(), nsamples, nchains; discard_initial = burn);
 ```
 
diff --git a/tutorials/gaussian-processes-introduction/index.qmd b/tutorials/gaussian-processes-introduction/index.qmd
index f8f05e33c..f2962b16c 100755
--- a/tutorials/gaussian-processes-introduction/index.qmd
+++ b/tutorials/gaussian-processes-introduction/index.qmd
@@ -105,14 +105,20 @@ Unfortunately, there is not a simple way to enforce monotonicity in the samples
 In any case, you can judge for yourself whether you think this is the most useful visualisation that we can perform; if you think there is something better to look at, please let us know!
 
 Moving on, we generate samples from the posterior using the default `NUTS` sampler.
-We'll make use of [ReverseDiff.jl](https://github.com/JuliaDiff/ReverseDiff.jl), as it has better performance than [ForwardDiff.jl](https://github.com/JuliaDiff/ForwardDiff.jl/) on this example.
+We'll make use of [Mooncake.jl](https://github.com/chalk-lab/Mooncake.jl), as it has better performance than [ForwardDiff.jl](https://github.com/JuliaDiff/ForwardDiff.jl/) on this example.
 See the [automatic differentiation docs]({{< meta usage-automatic-differentiation >}}) for more info.
 
 ```{julia}
-using Random, ReverseDiff
+using Random
+using Mooncake: Mooncake
 
 m_post = m | (y=df.y,)
-chn = sample(Xoshiro(123456), m_post, NUTS(; adtype=AutoReverseDiff()), 1_000, progress=false)
+# Note that the struct `AutoMooncake()` is a very small struct
+# defined in ADTypes.jl, which just means 'attempt to use
+# Mooncake.jl for automatic differentiation'. This struct is
+# reexported by Turing. However, you must also import
+# Mooncake itself which allows the AD call to execute.
+chn = sample(Xoshiro(123456), m_post, NUTS(; adtype=AutoMooncake()), 1_000, progress=false)
 ```
 
 We can use these samples and the `posterior` function from `AbstractGPs` to sample from the posterior probability of success at any distance we choose:
diff --git a/tutorials/hidden-markov-models/index.qmd b/tutorials/hidden-markov-models/index.qmd
index c83c6882b..54456d606 100755
--- a/tutorials/hidden-markov-models/index.qmd
+++ b/tutorials/hidden-markov-models/index.qmd
@@ -175,7 +175,7 @@ The p-values on the test suggest that we cannot reject the hypothesis that the o
 
 While the above method works well for the simple example in this tutorial, some users may desire a more efficient method, especially when their model is more complicated.
 One simple way to improve inference is to marginalize out the hidden states of the model with an appropriate algorithm, calculating only the posterior over the continuous random variables.
-Not only does this allow more efficient inference via Rao-Blackwellization, but now we can sample our model with `NUTS()` alone, which is usually a much more performant MCMC kernel.
+Not only does this allow more efficient inference via Rao–Blackwellization, but now we can sample our model with `NUTS()` alone, which is usually a much more performant MCMC kernel.
 
 Thankfully, [HiddenMarkovModels.jl](https://github.com/gdalle/HiddenMarkovModels.jl) provides an extremely efficient implementation of many algorithms related to hidden Markov models. This allows us to rewrite our model as:
 
diff --git a/tutorials/infinite-mixture-models/index.qmd b/tutorials/infinite-mixture-models/index.qmd
index 464694389..676af6ee4 100755
--- a/tutorials/infinite-mixture-models/index.qmd
+++ b/tutorials/infinite-mixture-models/index.qmd
@@ -12,9 +12,16 @@ using Pkg;
 Pkg.instantiate();
 ```
 
-In many applications it is desirable to allow the model to adjust its complexity to the amount of data. Consider for example the task of assigning objects into clusters or groups. This task often involves the specification of the number of groups. However, often times it is not known beforehand how many groups exist. Moreover, in some applications, e.g. modelling topics in text documents or grouping species, the number of examples per group is heavy tailed. This makes it impossible to predefine the number of groups and requiring the model to form new groups when data points from previously unseen groups are observed.
+In many applications it is desirable to allow the model to adjust its complexity to the amount of data.
+Consider for example the task of assigning objects into clusters or groups.
+This task often involves the specification of the number of groups.
+However, often times it is not known beforehand how many groups exist.
+Moreover, in some applications, e.g. modelling topics in text documents or grouping species, the number of examples per group is heavy-tailed.
+This makes it impossible to predefine the number of groups and requiring the model to form new groups when data points from previously unseen groups are observed.
 
-A natural approach for such applications is the use of [non-parametric models](https://en.wikipedia.org/wiki/Nonparametric_statistics#Non-parametric_models), which can grow in complexity as more data are observed. This tutorial demonstrates how to use the Dirichlet process in a mixture of infinitely many Gaussians using Turing. For further information on Bayesian nonparametrics and the Dirichlet process, see the [introduction by Zoubin Ghahramani](http://mlg.eng.cam.ac.uk/pub/pdf/Gha12.pdf) and the book "Fundamentals of Nonparametric Bayesian Inference" by Subhashis Ghosal and Aad van der Vaart.
+A natural approach for such applications is the use of [non-parametric models](https://en.wikipedia.org/wiki/Nonparametric_statistics#Non-parametric_models), which can grow in complexity as more data are observed.
+This tutorial demonstrates how to use the Dirichlet process in a mixture of infinitely many Gaussians using Turing.
+For further information on Bayesian nonparametrics and the Dirichlet process, see the [introduction by Zoubin Ghahramani](http://mlg.eng.cam.ac.uk/pub/pdf/Gha12.pdf) and the book "Fundamentals of Nonparametric Bayesian Inference" by Subhashis Ghosal and Aad van der Vaart.
 
 ```{julia}
 using Turing
@@ -22,7 +29,8 @@ using Turing
 
 ## Mixture Model
 
-Before introducing infinite mixture models in Turing, we will briefly review the construction of finite mixture models. Subsequently, we will define how to use the [Chinese restaurant process](https://en.wikipedia.org/wiki/Chinese_restaurant_process) construction of a Dirichlet process for non-parametric clustering.
+Before introducing infinite mixture models in Turing, we will briefly review the construction of finite mixture models.
+Subsequently, we will define how to use the [Chinese restaurant process](https://en.wikipedia.org/wiki/Chinese_restaurant_process) construction of a Dirichlet process for non-parametric clustering.
 
 #### Two-Component Model
 
@@ -89,13 +97,15 @@ which resembles the model in the [Gaussian mixture model tutorial]({{<meta gauss
 
 The question now arises, is there a generalization of a Dirichlet distribution for which the dimensionality $K$ is infinite, i.e. $K = \infty$?
 
-But first, to implement an infinite Gaussian mixture model in Turing, we first need to load the `Turing.RandomMeasures` module. `RandomMeasures` contains a variety of tools useful in nonparametrics.
+But first, to implement an infinite Gaussian mixture model in Turing, we first need to load the `Turing.RandomMeasures` module.
+`RandomMeasures` contains a variety of tools useful in nonparametrics.
 
 ```{julia}
 using Turing.RandomMeasures
 ```
 
-We now will utilize the fact that one can integrate out the mixing weights in a Gaussian mixture model allowing us to arrive at the Chinese restaurant process construction. See Carl E. Rasmussen: [The Infinite Gaussian Mixture Model](https://www.seas.harvard.edu/courses/cs281/papers/rasmussen-1999a.pdf), NIPS (2000) for details.
+We now will utilize the fact that one can integrate out the mixing weights in a Gaussian mixture model allowing us to arrive at the Chinese restaurant process construction.
+See Carl E. Rasmussen: [The Infinite Gaussian Mixture Model](https://www.seas.harvard.edu/courses/cs281/papers/rasmussen-1999a.pdf), NIPS (2000) for details.
 
 In fact, if the mixing weights are integrated out, the conditional prior for the latent variable $z$ is given by:
 
@@ -103,7 +113,9 @@ $$
 p(z_i = k \mid z_{\not i}, \alpha) = \frac{n_k + \alpha K}{N - 1 + \alpha}
 $$
 
-where $z_{\not i}$ are the latent assignments of all observations except observation $i$. Note that we use $n_k$ to denote the number of observations at component $k$ excluding observation $i$. The parameter $\alpha$ is the concentration parameter of the Dirichlet distribution used as prior over the mixing weights.
+where $z_{\not i}$ are the latent assignments of all observations except observation $i$.
+Note that we use $n_k$ to denote the number of observations at component $k$ excluding observation $i$.
+The parameter $\alpha$ is the concentration parameter of the Dirichlet distribution used as prior over the mixing weights.
 
 #### Chinese Restaurant Process
 
@@ -190,10 +202,11 @@ In Turing we can implement an infinite Gaussian mixture model using the Chinese
     # Latent assignment.
     z = zeros(Int, length(x))
 
-    # Locations of the infinitely many clusters.
-    μ = zeros(Float64, 0)
+    # Locations of the infinitely many clusters. µ[i] represents the location
+    # of the cluster number z[i].
+    μ = zeros(Float64, length(x))
 
-    for i in 1:length(x)
+    for i in eachindex(x)
 
         # Number of clusters.
         K = maximum(z)
@@ -204,19 +217,18 @@ In Turing we can implement an infinite Gaussian mixture model using the Chinese
 
         # Create a new cluster?
         if z[i] > K
-            push!(μ, 0.0)
-
             # Draw location of new cluster.
-            μ[z[i]] ~ H
+            μ[i] ~ H
         end
 
         # Draw observation.
-        x[i] ~ Normal(μ[z[i]], 1.0)
+        x[i] ~ Normal(μ[i], 1.0)
     end
 end
 ```
 
-We can now use Turing to infer the assignments of some data points. First, we will create some random data that comes from three clusters, with means of 0, -5, and 10.
+We can now use Turing to infer the assignments of some data points.
+First, we will create some random data that comes from three clusters, with means of 0, -5, and 10.
 
 ```{julia}
 using Plots, Random
@@ -256,31 +268,39 @@ k = map(
 plot(k; xlabel="Iteration", ylabel="Number of clusters", label="Chain 1")
 ```
 
-If we visualise the histogram of the number of clusters sampled from our posterior, we observe that the model seems to prefer 3 clusters, which is the true number of clusters. Note that the number of clusters in a Dirichlet process mixture model is not limited a priori and will grow to infinity with probability one. However, if conditioned on data the posterior will concentrate on a finite number of clusters enforcing the resulting model to have a finite amount of clusters. It is, however, not given that the posterior of a Dirichlet process Gaussian mixture model converges to the true number of clusters, given that data comes from a finite mixture model. See Jeffrey Miller and Matthew Harrison: [A simple example of Dirichlet process mixture inconsistency for the number of components](https://arxiv.org/pdf/1301.2708.pdf) for details.
+If we visualise the histogram of the number of clusters sampled from our posterior, we observe that the model seems to prefer 3 clusters, which is the true number of clusters.
+Note that the number of clusters in a Dirichlet process mixture model is not limited a priori and will grow to infinity with probability one.
+However, if conditioned on data the posterior will concentrate on a finite number of clusters enforcing the resulting model to have a finite amount of clusters.
+It is, however, not given that the posterior of a Dirichlet process Gaussian mixture model converges to the true number of clusters, given that data comes from a finite mixture model.
+See Jeffrey Miller and Matthew Harrison: [A simple example of Dirichlet process mixture inconsistency for the number of components](https://arxiv.org/pdf/1301.2708.pdf) for details.
 
 ```{julia}
 histogram(k; xlabel="Number of clusters", legend=false)
 ```
 
-One issue with the Chinese restaurant process construction is that the number of latent parameters we need to sample scales with the number of observations. It may be desirable to use alternative constructions in certain cases. Alternative methods of constructing a Dirichlet process can be employed via the following representations:
+One issue with the Chinese restaurant process construction is that the number of latent parameters we need to sample scales with the number of observations.
+It may be desirable to use alternative constructions in certain cases.
+Alternative methods of constructing a Dirichlet process can be employed via the following representations:
 
-Size-Biased Sampling Process
+- Size-Biased Sampling Process:
 
-$$
-j_k \sim \mathrm{Beta}(1, \alpha) \cdot \mathrm{surplus}
-$$
+  $$
+  j_k \sim \mathrm{Beta}(1, \alpha) \cdot \mathrm{surplus}
+  $$
 
-Stick-Breaking Process
-$$
-v_k \sim \mathrm{Beta}(1, \alpha)
-$$
+- Stick-Breaking Process:
 
-Chinese Restaurant Process
-$$
-p(z_n = k | z_{1:n-1}) \propto \begin{cases}
-\frac{m_k}{n-1+\alpha}, \text{ if } m_k > 0\\\
-\frac{\alpha}{n-1+\alpha}
-\end{cases}
-$$
+  $$
+  v_k \sim \mathrm{Beta}(1, \alpha)
+  $$
+
+- Chinese Restaurant Process:
+
+  $$
+  p(z_n = k | z_{1:n-1}) \propto \begin{cases}
+  \frac{m_k}{n-1+\alpha}, \text{ if } m_k > 0\\\
+  \frac{\alpha}{n-1+\alpha}
+  \end{cases}
+  $$
 
-For more details see [this article](https://www.stats.ox.ac.uk/%7Eteh/research/npbayes/Teh2010a.pdf).
\ No newline at end of file
+For more details see [this article](https://www.stats.ox.ac.uk/%7Eteh/research/npbayes/Teh2010a.pdf).
diff --git a/tutorials/multinomial-logistic-regression/index.qmd b/tutorials/multinomial-logistic-regression/index.qmd
index 3cc306a0d..1377ad9a2 100755
--- a/tutorials/multinomial-logistic-regression/index.qmd
+++ b/tutorials/multinomial-logistic-regression/index.qmd
@@ -12,97 +12,90 @@ using Pkg;
 Pkg.instantiate();
 ```
 
-Multinomial logistic regression is an extension of logistic regression. Logistic regression is used to model problems in which there are exactly two possible discrete outcomes. Multinomial logistic regression is used to model problems in which there are two or more possible discrete outcomes.
+Multinomial logistic regression is an extension of logistic regression.
+Logistic regression is used to model problems in which there are exactly two possible discrete outcomes.
+Multinomial logistic regression is used to model problems in which there are two or more possible discrete outcomes.
 
-In our example, we'll be using the iris dataset. The iris multiclass problem aims to predict the species of a flower given measurements (in centimetres) of sepal length and width and petal length and width. There are three possible species: Iris setosa, Iris versicolor, and Iris virginica.
+In our example, we'll be using the iris dataset.
+The iris multiclass problem aims to predict the species of a flower given measurements (in centimetres) of sepal length and width and petal length and width.
+There are three possible species: *Iris setosa*, *Iris versicolor*, and *Iris virginica*.
 
 To start, let's import all the libraries we'll need.
 
 ```{julia}
-# Load Turing.
 using Turing
-
-# Load RDatasets.
-using RDatasets
-
-# Load StatsPlots for visualisations and diagnostics.
+using MCMCChains: Chains
 using StatsPlots
-
 # Functionality for splitting and normalising the data.
-using MLDataUtils: shuffleobs, splitobs, rescale!
-
+using MLUtils: shuffleobs, splitobs, load_iris
+using StatsBase: fit, ZScoreTransform, transform!
 # We need a softmax function which is provided by NNlib.
-using NNlib: softmax
-
+using LogExpFunctions: softmax
 # Functionality for constructing arrays with identical elements efficiently.
 using FillArrays
 
-# Functionality for working with scaled identity matrices.
-using LinearAlgebra
-
 # Set a seed for reproducibility.
 using Random
 Random.seed!(0);
 ```
 
-## Data Cleaning & Set Up
+## Data Cleaning and Set Up
 
-Now we're going to import our dataset. Twenty rows of the dataset are shown below so you can get a good feel for what kind of data we have.
+Now we're going to import our dataset.
+Twenty rows of the dataset are shown below so you can get a good feel for what kind of data we have.
 
 ```{julia}
 # Import the "iris" dataset.
-data = RDatasets.dataset("datasets", "iris");
+X, Y = load_iris()
+nobs = size(X, 2)
 
-# Show twenty random rows.
-data[rand(1:size(data, 1), 20), :]
+# Show 10 random rows of the outcomes.
+Y[rand(1:nobs, 10)]
 ```
 
-In this data set, the outcome `Species` is currently coded as a string. We convert it to a numerical value by using indices 1, 2, and 3 to indicate species setosa, versicolor, and virginica, respectively.
+In this data set, the outcome `Species` is currently coded as a string.
+We convert it to a numerical value by using indices 1, 2, and 3 to indicate species setosa, versicolor, and virginica, respectively.
 
 ```{julia}
-# Recode the `Species` column.
 species = ["setosa", "versicolor", "virginica"]
-data[!, :Species_index] = indexin(data[!, :Species], species)
-
-# Show twenty random rows of the new species columns
-data[rand(1:size(data, 1), 20), [:Species, :Species_index]]
+Y = Vector{Int64}(indexin(Y, species))
+Y[rand(1:nobs, 10)]
 ```
 
-After we've done that tidying, it's time to split our dataset into training and testing sets, and separate the features and target from the data. Additionally, we must rescale our feature variables so that they are centred around zero by subtracting each column by the mean and dividing it by the standard deviation. This standardisation improves sampler efficiency by ensuring all features are on comparable scales.
+After we've done that tidying, it's time to split our dataset into training and testing sets, and separate the features and target from the data.
+Additionally, we must rescale our feature variables so that they are centred around zero by subtracting each column by the mean and dividing it by the standard deviation.
+This standardisation improves sampler efficiency by ensuring all features are on comparable scales.
 
 ```{julia}
 # Split our dataset 50%/50% into training/test sets.
-trainset, testset = splitobs(shuffleobs(data), 0.5)
-
-# Define features and target.
-features = [:SepalLength, :SepalWidth, :PetalLength, :PetalWidth]
-target = :Species_index
-
-# Turing requires data in matrix and vector form.
-train_features = Matrix(trainset[!, features])
-test_features = Matrix(testset[!, features])
-train_target = trainset[!, target]
-test_target = testset[!, target]
+(train_features, train_target), (test_features, test_target) = splitobs(shuffleobs((X, Y)); at=0.5)
 
 # Standardise the features.
-μ, σ = rescale!(train_features; obsdim=1)
-rescale!(test_features, μ, σ; obsdim=1);
+dt = fit(ZScoreTransform, train_features; dims=2)
+transform!(dt, train_features)
+transform!(dt, test_features)
 ```
 
 ## Model Declaration
 
-Finally, we can define our model `logistic_regression`. It is a function that takes three arguments where
+Finally, we can define our model `logistic_regression`.
+It is a function that takes three arguments where
 
   - `x` is our set of independent variables;
   - `y` is the element we want to predict;
   - `σ` is the standard deviation we want to assume for our priors.
 
-We select the setosa species as the baseline class (the choice does not matter). Then we create the intercepts and vectors of coefficients for the other classes against that baseline. More concretely, we create scalar intercepts `intercept_versicolor` and `intersept_virginica` and coefficient vectors `coefficients_versicolor` and `coefficients_virginica` with four coefficients each for the features `SepalLength`, `SepalWidth`, `PetalLength` and `PetalWidth`. We assume a normal distribution with mean zero and standard deviation `σ` as prior for each scalar parameter. We want to find the posterior distribution of these, in total ten, parameters to be able to predict the species for any given set of features.
+We select the setosa species as the baseline class (the choice does not matter).
+Then we create the intercepts and vectors of coefficients for the other classes against that baseline.
+More concretely, we create scalar intercepts `intercept_versicolor` and `intersept_virginica` and coefficient vectors `coefficients_versicolor` and `coefficients_virginica` with four coefficients, one for each feature.
+This gives us a total of 10 parameters to estimate.
+We assume a normal distribution with mean zero and standard deviation `σ` as prior for each scalar parameter.
+We want to find the posterior distribution of these parameters to be able to predict the species for any given set of features.
 
 ```{julia}
 # Bayesian multinomial logistic regression
 @model function logistic_regression(x, y, σ)
-    n = size(x, 1)
+    n = size(x, 2)
     length(y) == n ||
         throw(DimensionMismatch("number of observations in `x` and `y` is not equal"))
 
@@ -113,8 +106,8 @@ We select the setosa species as the baseline class (the choice does not matter).
     coefficients_virginica ~ MvNormal(Zeros(4), σ^2 * I)
 
     # Compute the likelihood of the observations.
-    values_versicolor = intercept_versicolor .+ x * coefficients_versicolor
-    values_virginica = intercept_virginica .+ x * coefficients_virginica
+    values_versicolor = intercept_versicolor .+ (coefficients_versicolor' * x)
+    values_virginica = intercept_virginica .+ (coefficients_virginica' * x)
     for i in 1:n
         # the 0 corresponds to the base category `setosa`
         v = softmax([0, values_versicolor[i], values_virginica[i]])
@@ -125,7 +118,8 @@ end;
 
 ## Sampling
 
-Now we can run our sampler. This time we'll use [`NUTS`](https://turinglang.org/stable/docs/library/#Turing.Inference.NUTS) to sample from our posterior.
+Now we can run our sampler.
+Here we'll use [`NUTS`](https://turinglang.org/stable/docs/library/#Turing.Inference.NUTS) to sample from our posterior.
 
 ```{julia}
 #| output: false
@@ -133,21 +127,15 @@ setprogress!(false)
 ```
 
 ```{julia}
-#| output: false
 m = logistic_regression(train_features, train_target, 1)
 chain = sample(m, NUTS(), MCMCThreads(), 1_500, 3)
 ```
 
-
-```{julia}
-#| echo: false
-chain
-```
-
-::: {.callout-warning collapse="true"}
+::: {.callout-info}
 ## Sampling With Multiple Threads
-The `sample()` call above assumes that you have at least `nchains` threads available in your Julia instance. If you do not, the multiple chains
-will run sequentially, and you may notice a warning. For more information, see [the Turing documentation on sampling multiple chains.]({{<meta core-functionality>}}#sampling-multiple-chains)
+The `sample()` call above assumes that you have at least `nchains` threads available in your Julia instance.
+If you do not, the multiple chains will run sequentially, and you may notice a warning.
+For more information, see [the Turing documentation on sampling multiple chains.]({{<meta core-functionality>}}#sampling-multiple-chains)
 :::
 
 Since we ran multiple chains, we may as well do a spot check to make sure each chain converges around similar points.
@@ -158,34 +146,26 @@ plot(chain)
 
 Looks good!
 
-We can also use the `corner` function from MCMCChains to show the distributions of the various parameters of our multinomial logistic regression. The corner function requires MCMCChains and StatsPlots.
+We can also use the `corner` function from StatsPlots to show the distributions of the various parameters of our multinomial logistic regression.
+`corner(chain)` will show the distributions of all parameters, but here we will only show the first three to avoid cluttering the plot.
 
 ```{julia}
-# Only plotting the first 3 coefficients due to a bug in Plots.jl
-corner(
-    chain,
-    MCMCChains.namesingroup(chain, :coefficients_versicolor)[1:3];
-)
-```
-
-```{julia}
-# Only plotting the first 3 coefficients due to a bug in Plots.jl
-corner(
-    chain,
-    MCMCChains.namesingroup(chain, :coefficients_virginica)[1:3];
-)
+corner(chain, MCMCChains.namesingroup(chain, :coefficients_versicolor))
 ```
 
 Fortunately the corner plots appear to demonstrate unimodal distributions for each of our parameters, so it should be straightforward to take the means of each parameter's sampled values to estimate our model to make predictions.
 
 ## Making Predictions
 
-How do we test how well the model actually predicts which of the three classes an iris flower belongs to? We need to build a `prediction` function that takes the test dataset and runs it through the average parameter calculated during sampling.
+How do we test how well the model actually predicts which of the three classes an iris flower belongs to?
+We need to build a `prediction` function that takes the test dataset and runs it through the average parameter calculated during sampling.
 
-The `prediction` function below takes a `Matrix` and a `Chains` object. It computes the mean of the sampled parameters and calculates the species with the highest probability for each observation. Note that we do not have to evaluate the `softmax` function since it does not affect the order of its inputs.
+The `prediction` function below takes a matrix and a `Chains` object.
+It computes the mean of the sampled parameters and calculates the species with the highest probability for each observation.
+Note that we do not have to evaluate the `softmax` function since it does not affect the order of its inputs.
 
 ```{julia}
-function prediction(x::Matrix, chain)
+function prediction(x::AbstractMatrix{<:Real}, chain::MCMCChains.Chains)
     # Pull the means from each parameter's sampled values in the chain.
     intercept_versicolor = mean(chain, :intercept_versicolor)
     intercept_virginica = mean(chain, :intercept_virginica)
@@ -197,8 +177,8 @@ function prediction(x::Matrix, chain)
     ]
 
     # Compute the index of the species with the highest probability for each observation.
-    values_versicolor = intercept_versicolor .+ x * coefficients_versicolor
-    values_virginica = intercept_virginica .+ x * coefficients_virginica
+    values_versicolor = intercept_versicolor .+ (coefficients_versicolor' * x)
+    values_virginica = intercept_virginica .+ (coefficients_virginica' * x)
     species_indices = [
         argmax((0, x, y)) for (x, y) in zip(values_versicolor, values_virginica)
     ]
@@ -207,29 +187,28 @@ function prediction(x::Matrix, chain)
 end;
 ```
 
-Let's see how we did! We run the test matrix through the prediction function, and compute the accuracy for our prediction.
+Let's see how we did!
+We run the test matrix through the prediction function, and compute the accuracy for our prediction.
 
 ```{julia}
 # Make the predictions.
 predictions = prediction(test_features, chain)
 
 # Calculate accuracy for our test set.
-mean(predictions .== testset[!, :Species_index])
+mean(predictions .== test_target)
 ```
 
 Perhaps more important is to see the accuracy per class.
 
 ```{julia}
 for s in 1:3
-    rows = testset[!, :Species_index] .== s
+    rows = test_target .== s
     println("Number of `", species[s], "`: ", count(rows))
     println(
         "Percentage of `",
         species[s],
         "` predicted correctly: ",
-        mean(predictions[rows] .== testset[rows, :Species_index]),
+        mean(predictions[rows] .== test_target[rows])
     )
 end
 ```
-
-This tutorial has demonstrated how to use Turing to perform Bayesian multinomial logistic regression.
\ No newline at end of file
diff --git a/tutorials/variational-inference/index.qmd b/tutorials/variational-inference/index.qmd
index 70dfa5491..56f0b0951 100755
--- a/tutorials/variational-inference/index.qmd
+++ b/tutorials/variational-inference/index.qmd
@@ -57,7 +57,7 @@ using RDatasets
 
 using LinearAlgebra
 
-# Import the "Default" dataset.
+# Import the "mtcars" dataset.
 data = RDatasets.dataset("datasets", "mtcars");
 
 # Show the first six rows of the dataset.
@@ -137,11 +137,9 @@ test = Matrix(test_cut[:, remove_names]);
     mu = intercept .+ x * coefficients
     return y ~ MvNormal(mu, σ² * I)
 end;
-```
 
-```{julia}
 n_obs, n_vars = size(train)
-m = linear_regression(train, train_label, n_obs, n_vars);
+m = linear_regression(train, train_label, n_obs, n_vars)
 ```
 
 ## Basic Usage
@@ -150,7 +148,7 @@ For instance, the most commonly used family is the mean-field Gaussian family.
 For this, Turing provides functions that automatically construct the initialisation corresponding to the model `m`:
 
 ```{julia}
-q_init = q_meanfield_gaussian(m);
+q_init = q_meanfield_gaussian(m)
 ```
 
 `vi` will automatically recognise the variational family through the type of `q_init`.
@@ -159,6 +157,7 @@ Here is a detailed documentation for the constructor:
 ```{julia}
 @doc(Variational.q_meanfield_gaussian)
 ```
+
 As we can see, the precise initialisation can be customized through the keyword arguments.
 
 Let's run VI with the default setting:
@@ -258,6 +257,7 @@ Plots.plot!(iters, elbo_mf, xlabel="Iterations", ylabel="ELBO", label="callback"
 We can see that the ELBO values are less noisy and progress more smoothly due to averaging.
 
 ## Using Different Optimisers
+
 The default optimiser we use is a proximal variant of DoWG[^KMJ2023].
 For Gaussian variational families, this works well as a default option.
 Sometimes, the step size of `AdvancedVI.DoWG` could be too large, resulting in unstable behaviour.
@@ -312,7 +312,7 @@ This term, however, traditionally comes from the fact that full-rank families us
 In contrast to the mean-field family, the full-rank family will often result in more computation per optimisation step and slower convergence, especially in high dimensions:
 
 ```{julia}
-q_fr, info_fr, _ = vi(m, q_init_fr, n_iters; show_progress=false, callback)
+q_fr, info_fr, state_fr = vi(m, q_init_fr, n_iters; show_progress=false, callback)
 
 Plots.plot(elbo_mf, xlabel="Iterations", ylabel="ELBO", label="Mean-Field", ylims=(-200, Inf))
 
@@ -346,37 +346,20 @@ Now, we can, for example, look at expectations:
 avg = vec(mean(z; dims=2))
 ```
 
-The vector has the same ordering as the parameters in the model, *e.g.* in this case `σ²` has index `1`, `intercept` has index `2` and `coefficients` has indices `3:12`. If  you forget or you might want to do something programmatically with the result, you can obtain the `sym → indices` mapping as follows:
-
-```{julia}
-using Bijectors: bijector
-
-_, sym2range = bijector(m, Val(true));
-sym2range
-```
-
-For example, we can check the sample distribution and mean value of `σ²`:
+The vector has the same ordering as the parameters in the model: for example, in this case `σ²` will have index `1`, `intercept` has index `2` and `coefficients` has indices `3:12`.
 
-```{julia}
-histogram(z[1, :])
-avg[union(sym2range[:σ²]...)]
-```
-
-```{julia}
-avg[union(sym2range[:intercept]...)]
-```
-
-```{julia}
-avg[union(sym2range[:coefficients]...)]
-```
+:::{.callout-warning}
+Note that the ordering of the parameters in the vector is an internal detail and is not guaranteed to be consistent across different versions of Turing, nor is it guaranteed to obey semantic versioning.
+:::
 
 For further convenience, we can wrap the samples into a `Chains` object to summarise the results.
 
 ```{julia}
-varinf = Turing.DynamicPPL.VarInfo(m)
-vns_and_values = Turing.DynamicPPL.varname_and_value_leaves(Turing.DynamicPPL.values_as(varinf, OrderedDict))
+vnt = rand(m)
+vns_and_values = Turing.DynamicPPL.varname_and_value_leaves(OrderedDict(pairs(vnt)))
 varnames = map(first, vns_and_values)
 vi_chain = Chains(reshape(z', (size(z,2), size(z,1), 1)), varnames)
+describe(vi_chain)
 ```
 
 (Since we're drawing independent samples, we can simply ignore the ESS and Rhat metrics.)
diff --git a/usage/custom-distribution/index.qmd b/usage/custom-distribution/index.qmd
index 1b26170d8..453a5abec 100755
--- a/usage/custom-distribution/index.qmd
+++ b/usage/custom-distribution/index.qmd
@@ -18,11 +18,10 @@ Pkg.instantiate();
 This page shows a workflow of how to define a customised distribution, using our own implementation of a simple `Uniform` distribution as a simple example.
 
 ```{julia}
-#| output: false
-using Distributions, Turing, Random, Bijectors
+using Distributions, Turing, Random
 ```
 
-## Define the Distribution Type
+## Distribution type
 
 First, define a type of the distribution, as a subtype of a corresponding distribution type in the Distributions.jl package.
 
@@ -30,53 +29,93 @@ First, define a type of the distribution, as a subtype of a corresponding distri
 struct CustomUniform <: ContinuousUnivariateDistribution end
 ```
 
-## Implement Sampling and Evaluation of the log-pdf
+## Sampling and log-probability evaluation
 
 Second, implement the `rand` and `logpdf` functions for your new distribution, which will be used to run the model.
 
 ```{julia}
 # sample in [0, 1]
-Distributions.rand(rng::AbstractRNG, d::CustomUniform) = rand(rng)
+Base.rand(rng::AbstractRNG, ::CustomUniform) = rand(rng)
 
 # p(x) = 1 → log[p(x)] = 0
-Distributions.logpdf(d::CustomUniform, x::Real) = zero(x)
+Distributions.logpdf(::CustomUniform, x::Real) = zero(x)
 ```
 
-## Define Helper Functions
+## Bijectors
 
-In most cases, it may be required to define some helper functions.
+Once you have defined the above, you should be able to use your distribution in a Turing model and sample with `Prior()`.
 
-### Domain Transformation
+```{julia}
+@model function demo()
+    x ~ CustomUniform()
+end
 
-Certain samplers, such as `HMC`, require the domain of the priors to be unbounded. Therefore, to use our `CustomUniform` as a prior in a model we also need to define how to transform samples from [0, 1] to ℝ. To do this, we need to define the corresponding `Bijector` from `Bijectors.jl`, which is what `Turing.jl` uses internally to deal with constrained distributions.
+mean(sample(demo(), Prior(), 100))
+```
 
-To transform from [0, 1] to ℝ we can use the `Logit` bijector:
+However, to make this work with other samplers (and in particular HMC and NUTS), we also have to define the corresponding bijectors for our distribution.
+This is because HMC and NUTS operate in an unconstrained space.
 
-```{julia}
-Bijectors.bijector(d::CustomUniform) = Logit(0.0, 1.0)
-```
+Turing v0.43 onwards uses the `Bijectors.VectorBijectors` interface, [which is documented here](https://turinglang.org/Bijectors.jl/stable/vector/).
 
-In the present example, `CustomUniform` is a subtype of `ContinuousUnivariateDistribution`. The procedure for subtypes of `ContinuousMultivariateDistribution` and `ContinuousMatrixDistribution` is exactly the same. For example, `Wishart` defines a distribution over positive-definite matrices and so the `bijector` returns a `PDBijector` when called with a `Wishart` distribution as an argument. For discrete distributions, there is no need to define a bijector; the `Identity` bijector is used by default.
+The most important functions to define are `Bijectors.VectorBijectors.from_linked_vec` and `Bijectors.VectorBijectors.to_linked_vec`, which define how to transform from the constrained space to the unconstrained space and back, respectively.
+On top of that, you also need to define `ChangesOfVariables.with_logabsdet_jacobian` for the
+resulting function.
+(Bijectors reexports that function for convenience.)
 
-As an alternative to the above, for `UnivariateDistribution` we could define the `minimum` and `maximum` of the distribution:
+Specifically, `to_linked_vec` maps from samples (i.e. floats in `[0, 1]`) to a vector where every element is independent and unconstrained; and `from_linked_vec` is the inverse.
+*Note that both these functions take the distribution as the argument, and return the transformation function!*
+Then `with_logabsdet_jacobian` takes that function and *its* argument, and returns a tuple of the transformed value and the log-absolute-determinant of the Jacobian of the transformation.
+
+:::{.callout-note}
+## Jacobians
+
+If you are not familiar with Jacobians, this is explained in more detail at [Variable Transformations]({{< meta dev-transforms-distributions >}}).
+:::
+
+This API is most easily explained by example.
+The forward transform (`to_linked_vec`) can be accomplished with a logit:
 
 ```{julia}
-Distributions.minimum(d::CustomUniform) = 0.0
-Distributions.maximum(d::CustomUniform) = 1.0
-```
+import Bijectors
+using StatsFuns: logit, logistic, log1pexp
 
-and `Bijectors.jl` will return a default `Bijector` called `TruncatedBijector` which makes use of `minimum` and `maximum` to derive the correct transformation.
+function veclogit(x::Real)
+    return [logit(x)]
+end
 
-Internally, Turing basically does the following when it needs to convert a constrained distribution to an unconstrained distribution, e.g. when sampling using `HMC`:
+Bijectors.VectorBijectors.to_linked_vec(::CustomUniform) = veclogit
+
+Bijectors.with_logabsdet_jacobian(::typeof(veclogit), x) = begin
+    logit_x = logit(x)
+    return [logit_x], -logit_x
+end
+```
+
+Often it can be easier to create and dispatch on a callable struct; we'll demonstrate that
+for the inverse transform.
 
 ```{julia}
-dist = Gamma(2,3)
-b = bijector(dist)
-transformed_dist = transformed(dist, b) # results in distribution with transformed support + correction for logpdf
+import Bijectors
+
+struct OnlyLogistic end
+(::OnlyLogistic)(y::AbstractVector{<:Real}) = 1/(1 + exp(-y[1]))
+
+Bijectors.VectorBijectors.from_linked_vec(::CustomUniform) = OnlyLogistic()
+
+function Bijectors.with_logabsdet_jacobian(::OnlyLogistic, y::AbstractVector{<:Real})
+    yi = y[]
+    res = logistic(yi)
+    logjac = yi - (2 * log1pexp(yi))
+    return res, logjac
+end
 ```
 
-and then we can call `rand` and `logpdf` as usual, where
-  - `rand(transformed_dist)` returns a sample in the unconstrained space, and
-  - `logpdf(transformed_dist, y)` returns the log density of the original distribution, but with `y` living in the unconstrained space.
+Once you have defined these, you should be able to sample with HMC and NUTS as well:
+
+```{julia}
+sample(demo(), NUTS(), 100)
+```
 
-To read more about Bijectors.jl, check out [its documentation](https://turinglang.org/Bijectors.jl/stable/).
\ No newline at end of file
+There is a lot of functionality that is already in Bijectors.jl which you could reuse.
+In fact, for bounded univariate distributions Bijectors already defines default transforms, so in this specific instance the above code is not strictly necessary.
diff --git a/usage/external-samplers/index.qmd b/usage/external-samplers/index.qmd
index af742a0cc..41ca459e0 100755
--- a/usage/external-samplers/index.qmd
+++ b/usage/external-samplers/index.qmd
@@ -37,8 +37,8 @@ end
 Now we sample the model to generate some observations, which we can then condition on.
 
 ```{julia}
-(; x) = rand(funnel() | (θ=0,))
-model = funnel() | (; x);
+vnt = rand(funnel() | (θ=0,))
+model = funnel() | (; x=vnt[@varname(x)]);
 ```
 
 Users can use any sampler algorithm to sample this model if it follows the `AbstractMCMC` API.
@@ -146,4 +146,4 @@ In general, we recommend that the `AbstractMCMC` interface is implemented direct
 However, any DynamicPPL- or Turing-specific functionality is best implemented in a `MySamplerTuringExt` extension.
 
 [^1]: Xu et al., [AdvancedHMC.jl: A robust, modular and efficient implementation of advanced HMC algorithms](http://proceedings.mlr.press/v118/xu20a/xu20a.pdf), 2019
-[^2]: Zhang et al., [Pathfinder: Parallel quasi-Newton variational inference](https://arxiv.org/abs/2108.03782), 2021
\ No newline at end of file
+[^2]: Zhang et al., [Pathfinder: Parallel quasi-Newton variational inference](https://arxiv.org/abs/2108.03782), 2021
diff --git a/usage/mode-estimation/index.qmd b/usage/mode-estimation/index.qmd
old mode 100755
new mode 100644
index cbc64530a..5356125a7
--- a/usage/mode-estimation/index.qmd
+++ b/usage/mode-estimation/index.qmd
@@ -12,9 +12,12 @@ using Pkg;
 Pkg.instantiate();
 ```
 
-After defining a statistical model, in addition to sampling from its distributions, one may be interested in finding the parameter values that maximise for instance the posterior distribution density function or the likelihood. This is called mode estimation. Turing provides support for two mode estimation techniques, [maximum likelihood estimation](https://en.wikipedia.org/wiki/Maximum_likelihood_estimation) (MLE) and [maximum a posteriori](https://en.wikipedia.org/wiki/Maximum_a_posteriori_estimation) (MAP) estimation.
+After defining a statistical model, in addition to sampling from its distributions, one may be interested in finding the parameter values that maximise (for instance) the posterior density, or the likelihood.
+This is called mode estimation.
 
-To demonstrate mode estimation, let us load Turing and declare a model:
+Turing provides support for two mode estimation techniques, [maximum likelihood estimation](https://en.wikipedia.org/wiki/Maximum_likelihood_estimation) (MLE) and [maximum a posteriori](https://en.wikipedia.org/wiki/Maximum_a_posteriori_estimation) (MAP) estimation.
+
+We begin by defining a simple model to work with:
 
 ```{julia}
 using Turing
@@ -32,90 +35,164 @@ Once the model is defined, we can construct a model instance as we normally woul
 model = normal_model(2.0)
 ```
 
-Finding the maximum a posteriori or maximum likelihood parameters is as simple as
+In its simplest form, finding the maximum a posteriori or maximum likelihood parameters is just a function call:
 
 ```{julia}
 # Generate a MLE estimate.
 mle_estimate = maximum_likelihood(model)
+```
 
+```{julia}
 # Generate a MAP estimate.
 map_estimate = maximum_a_posteriori(model)
 ```
 
 The estimates are returned as instances of the `ModeResult` type.
-It has the fields `params` (which stores a mapping of `VarName`s to the parameter values found) and `lp` for the log probability at the optimum.
-For mode information, please see the docstring of `ModeResult`.
+It has the fields `params` (a `VarNamedTuple` mapping `VarName`s to the parameter values found) and `lp` for the log probability at the optimum.
+For more information, please see the docstring of `ModeResult`.
+
+You can access individual parameter values by indexing into the `params` field with `VarName`s:
+
+```{julia}
+map_estimate.params[@varname(x)]
+```
+
+If you need a vectorised form of the parameters, you can use `vector_names_and_params`, which return a tuple of two vectors: one of `VarName`s and one of the corresponding parameter values.
+(Note that these values are *always* returned in untransformed space.)
+
+```{julia}
+vector_names_and_params(map_estimate)
+```
+
+The `optim_result` field (which is not printed by default) contains the original result from the underlying optimisation solver, which is useful for diagnosing convergence issues and accessing solver-specific information:
 
 ```{julia}
-@show mle_estimate.params
-@show mle_estimate.lp;
+map_estimate.optim_result
 ```
 
 ## Controlling the optimisation process
 
-Under the hood `maximum_likelihood` and `maximum_a_posteriori` use the [Optimisation.jl](https://github.com/SciML/Optimisation.jl) package, which provides a unified interface to many other optimisation packages.
-By default Turing uses the [LBFGS](https://en.wikipedia.org/wiki/Limited-memory_BFGS) method from [Optim.jl](https://github.com/JuliaNLSolvers/Optim.jl) to find the mode estimate, but we can easily change that:
+### Solvers
+
+Under the hood, `maximum_likelihood` and `maximum_a_posteriori` use the [Optimization.jl](https://github.com/SciML/Optimization.jl) package, which provides a unified interface to many other optimisation packages.
+By default Turing uses the [LBFGS](https://en.wikipedia.org/wiki/Limited-memory_BFGS) method from [Optim.jl](https://docs.sciml.ai/Optimization/stable/optimization_packages/optim/) to find the mode estimate, but we can change that to any other solver by passing it as the second argument:
 
 ```{julia}
 using OptimizationOptimJL: NelderMead
-@show maximum_likelihood(model, NelderMead())
 
-using OptimizationNLopt: NLopt.LD_TNEWTON_PRECOND_RESTART
-@show maximum_likelihood(model, LD_TNEWTON_PRECOND_RESTART());
+maximum_likelihood(model, NelderMead())
 ```
 
-The above are just two examples, Optimisation.jl supports [many more](https://docs.sciml.ai/Optimisation/stable/).
+Optimization.jl supports [many more solvers](https://docs.sciml.ai/Optimization/stable/); please see its documentation for details.
+
+### Initial parameters
 
-We can also help the optimisation by giving it a starting point we know is close to the final solution (`initial_params`), or by specifying an automatic differentiation method (`adtype`).
+We can help the optimisation by giving it a starting point we know is close to the final solution.
+Initial parameters are specified using `InitFromParams`, and must be provided in model space (i.e. untransformed):
+
+```{julia}
+params = VarNamedTuple(; x=0.5)
+maximum_likelihood(model; initial_params=InitFromParams(params))
+```
+
+The default initialisation strategy is `InitFromPrior()`, which draws initial values from the prior.
+
+### AD backend
+
+You can also specify an automatic differentiation method using the `adtype` keyword argument:
 
 ```{julia}
-using OptimizationOptimJL: LBFGS
 import Mooncake
 
-maximum_likelihood(model, LBFGS(); initial_params=[0.1], adtype=AutoMooncake())
+maximum_likelihood(model; adtype=AutoMooncake())
 ```
 
-When providing values to arguments like `initial_params` the parameters are typically specified in the order in which they appear in the code of the model, so in this case first `s²` then `m`. More precisely it's the order returned by `Turing.Inference.getparams(model, DynamicPPL.VarInfo(model))`.
+### Linked vs unlinked optimisation
 
-::: {.callout-note}
-## Upcoming changes to the optimisation API
+By default, Turing transforms model parameters to an unconstrained space before optimising (`link=true`).
+There are two reasons why one might want to do this:
+
+ 1. This avoids discontinuities where the log-density drops to `-Inf` outside the support of a distribution.
+ 2. But more importantly, this avoids situations where the original sample contains values that depend on each other.
+    For example, in a `Dirichlet` distribution, the parameters must sum to 1.
+    That means that if we do not perform linking, these parameters cannot be varied completely independently, which can lead to numerical issues.
+    In contrast, when linking is performed, the parameters are transformed into a (shorter) vector of parameters that are completely unconstrained and independent.
 
-In Turing v0.43, the `initial_params` argument for optimisation will be changed to be a `DynamicPPL.AbstractInitStrategy` as described in [the sampling options page]({{< meta usage-sampling-options >}}#specifying-initial-parameters)).
+Note that the parameter values returned are always in the original (untransformed) space, regardless of the `link` setting.
 
-Furthermore, constraints must be specified as (ideally) a [`VarNamedTuple`]({{< meta usage-varnamedtuple >}}).
-All constraints specified will be interpreted as being in untransformed space.
+::: {.callout-note}
+## What does 'unconstrained' really mean?
+
+Note that the transformation to unconstrained space refers to the support of the *original* distribution prior to any optimisation constraints being applied.
+For example, a parameter `x ~ Beta(2, 2)` will be transformed from the original space of `(0, 1)` to the unconstrained space of `(-Inf, Inf)` (via the logit transform).
+However, it is possible that the optimisation still proceeds in a constrained space, if constraints on the parameter are specified via `lb` or `ub`.
+For example, if we specify `lb=0.0` and `ub=0.2` for the same parameter, then the optimisation will proceed in the constrained space of `(-Inf, logit(0.2))`.
 :::
 
-We can also do constrained optimisation, by providing either intervals within which the parameters must stay, or constraint functions that they need to respect.
-For instance, here's how one can find the MLE with the constraint that `x` must be between `0.0` and `0.2`:
+If you want to optimise in the original parameter space instead, set `link=false`.
 
 ```{julia}
-maximum_likelihood(model; lb=[0.0], ub=[0.2])
+maximum_a_posteriori(model; link=false)
 ```
 
-The arguments for lower (`lb`) and upper (`ub`) bounds follow the arguments of `Optimisation.OptimizationProblem`, as do other parameters for providing [constraints](https://docs.sciml.ai/Optimisation/stable/tutorials/constraints/), such as `cons`.
-Any extraneous keyword arguments given to `maximum_likelihood` or `maximum_a_posteriori` are passed to `Optimisation.solve`.
-Some often useful ones are `maxiters` for controlling the maximum number of iterations and `abstol` and `reltol` for the absolute and relative convergence tolerances:
+This is usually only useful under very specific circumstances, namely when your model contains distributions for which the mapping from model space to unconstrained space is dependent on another parameter's value.
+
+### Box constraints
+
+You can provide lower and upper bounds on parameters using the `lb` and `ub` keywords respectively.
+Bounds are specified as a `VarNamedTuple` and, just like initial values, must be provided in model space (i.e. untransformed):
+
+```{julia}
+lb = VarNamedTuple(; x=0.0)
+ub = VarNamedTuple(; x=0.2)
+maximum_likelihood(model; lb=lb, ub=ub)
+```
+
+Turing will internally translate these bounds to unconstrained space if `link=true`; as a user you should not need to worry at all about the details of this transformation.
+
+In this case we only have one parameter, but if there are multiple parameters and you only want to constrain some of them, you can provide bounds for the parameters you want to constrain and omit the others.
+
+Note that for some distributions (e.g. `Dirichlet`, `LKJCholesky`), the mapping from model-space bounds to linked-space bounds is not well-defined.
+In these cases, Turing will raise an error.
+If you need constrained optimisation for such variables, either set `link=false` or use `LogDensityFunction` with Optimization.jl directly.
+
+::: {.callout-note}
+## Generic constraints
+Generic (non-box) constraints are not supported by Turing's optimisation interface.
+For these, please use `LogDensityFunction` and Optimization.jl directly.
+:::
+
+### Solver options
+
+Any extra keyword arguments are passed through to `Optimization.solve`.
+Some commonly useful ones are `maxiters`, `abstol`, and `reltol`:
 
 ```{julia}
+params = VarNamedTuple(; x=-4.0)
 badly_converged_mle = maximum_likelihood(
-    model, NelderMead(); maxiters=10, reltol=1e-9
+    model, NelderMead(); initial_params=InitFromParams(params), maxiters=10, reltol=1e-9
 )
 ```
 
-We can check whether the optimisation converged using the `optim_result` field of the result:
+### Reproducibility
+
+To get reproducible results, pass an `rng` as the first argument:
 
 ```{julia}
-@show badly_converged_mle.optim_result;
+using Random: Xoshiro
+maximum_a_posteriori(Xoshiro(468), model)
 ```
 
-For more details, such as a full list of possible arguments, we encourage the reader to read the docstring of the function `Turing.Optimisation.estimate_mode`, which is what `maximum_likelihood` and `maximum_a_posteriori` call, and the documentation of [Optimisation.jl](https://docs.sciml.ai/Optimisation/stable/).
+This controls the random number generator used for parameter initialisation; the actual optimisation process is deterministic.
+
+For more details and a full list of keyword arguments, see the docstring of `Turing.Optimisation.estimate_mode`.
 
-## Analyzing your mode estimate
+## Analysing your mode estimate
 
-Turing extends several methods from `StatsBase` that can be used to analyse your mode estimation results. Methods implemented include `vcov`, `informationmatrix`, `coeftable`, `params`, and `coef`, among others.
+Turing extends several methods from `StatsBase` that can be used to analyse your mode estimation results.
+Methods implemented include `vcov`, `informationmatrix`, `coeftable`, `coef`, and `coefnames`.
 
-For example, let's examine our ML estimate from above using `coeftable`:
+For example, let's examine our MLE estimate from above using `coeftable`:
 
 ```{julia}
 using StatsBase: coeftable
@@ -125,13 +202,23 @@ coeftable(mle_estimate)
 Standard errors are calculated from the Fisher information matrix (inverse Hessian of the log likelihood or log joint).
 Note that standard errors calculated in this way may not always be appropriate for MAP estimates, so please be cautious in interpreting them.
 
+The Hessian is computed using automatic differentiation.
+By default, `ForwardDiff` is used, but if you are feeling brave you can specify a different backend via the `adtype` keyword argument to `informationmatrix`.
+(Note that AD backend support for second-order derivatives is more limited than for first-order derivatives, so not all backends will work here.)
+
+```{julia}
+using StatsBase: informationmatrix
+import ReverseDiff
+
+informationmatrix(mle_estimate; adtype=AutoReverseDiff())
+```
+
 ## Sampling with the MAP/MLE as initial states
 
 You can begin sampling your chain from an MLE/MAP estimate by wrapping it in `InitFromParams` and providing it to the `sample` function with the keyword `initial_params`.
 For example, here is how to sample from the full posterior using the MAP estimate as the starting point:
 
 ```{julia}
-#| eval: false
 map_estimate = maximum_a_posteriori(model)
 chain = sample(model, NUTS(), 1_000; initial_params=InitFromParams(map_estimate))
 ```
diff --git a/usage/probability-interface/index.qmd b/usage/probability-interface/index.qmd
index 3a1703d29..d65feb3ac 100644
--- a/usage/probability-interface/index.qmd
+++ b/usage/probability-interface/index.qmd
@@ -97,20 +97,6 @@ We can then calculate the joint probability of a set of samples (here drawn from
 logjoint(model, sample)
 ```
 
-For models with many variables `rand(model)` can be prohibitively slow since it returns a `NamedTuple` of samples from the prior distribution of the unconditioned variables.
-We recommend working with samples of type `DataStructures.OrderedDict` in this case (which Turing re-exports, so can be used directly):
-
-```{julia}
-Random.seed!(124)
-sample_dict = rand(OrderedDict, model)
-```
-
-`logjoint` can also be used on this sample:
-
-```{julia}
-logjoint(model, sample_dict)
-```
-
 The prior probability and the likelihood of a set of samples can be calculated with the functions `logprior` and `loglikelihood` respectively.
 The log joint probability is the sum of these two quantities:
 
@@ -118,10 +104,6 @@ The log joint probability is the sum of these two quantities:
 logjoint(model, sample) ≈ loglikelihood(model, sample) + logprior(model, sample)
 ```
 
-```{julia}
-logjoint(model, sample_dict) ≈ loglikelihood(model, sample_dict) + logprior(model, sample_dict)
-```
-
 ## Example: Cross-validation
 
 To give an example of the probability interface in use, we can use it to estimate the performance of our model using cross-validation.
@@ -133,7 +115,7 @@ For a more competent implementation, see [MLUtils.jl](https://juliaml.github.io/
 
 ```{julia}
 # Calculate the train/validation splits across `nfolds` partitions, assume `length(dataset)` divides `nfolds`
-function kfolds(dataset::Array{<:Real}, nfolds::Int)
+function kfolds(dataset::AbstractArray{<:Real}, nfolds::Int)
     fold_size, remaining = divrem(length(dataset), nfolds)
     if remaining != 0
         error("The number of folds must divide the number of data points.")
@@ -179,4 +161,4 @@ end
 cross_val(dataset)
 ```
 
-[^1]: See [ParetoSmooth.jl](https://github.com/TuringLang/ParetoSmooth.jl) for a faster and more accurate implementation of cross-validation than the one provided here.
\ No newline at end of file
+[^1]: See [ParetoSmooth.jl](https://github.com/TuringLang/ParetoSmooth.jl) for a faster and more accurate implementation of cross-validation than the one provided here.
diff --git a/usage/sampler-visualisation/index.qmd b/usage/sampler-visualisation/index.qmd
index f3661be6b..79adc54e1 100755
--- a/usage/sampler-visualisation/index.qmd
+++ b/usage/sampler-visualisation/index.qmd
@@ -26,10 +26,6 @@ using Plots
 using StatsPlots
 using Turing
 using Random
-using Bijectors
-
-# Set a seed.
-Random.seed!(0)
 
 # Define a strange model.
 @model function gdemo(x)
@@ -46,16 +42,16 @@ end
 # Define our data points.
 x = [1.5, 2.0, 13.0, 2.1, 0.0]
 
-# Set up the model call, sample from the prior.
+# Set up the model call.
 model = gdemo(x)
 
 # Evaluate surface at coordinates.
-evaluate(m1, m2) = logjoint(model, (m=m2, s²=invlink.(Ref(InverseGamma(2, 3)), m1)))
+evaluate(m1, m2) = logjoint(model, (m=m2, s²=exp(m1)))
 
 function plot_sampler(chain; label="")
     # Extract values from chain.
     val = get(chain, [:s², :m, :logjoint])
-    ss = link.(Ref(InverseGamma(2, 3)), val.s²)
+    ss = log.(val.s²) # Convert to unconstrained space
     ms = val.m
     lps = val.logjoint
 
@@ -77,7 +73,6 @@ function plot_sampler(chain; label="")
         μ_rng,
         evaluate;
         camera=(30, 65),
-        #   ticks=nothing,
         colorbar=false,
         color=:inferno,
         title=label,
@@ -95,8 +90,8 @@ function plot_sampler(chain; label="")
         legend=false,
         colorbar=false,
         alpha=0.5,
-        xlabel="σ",
-        ylabel="μ",
+        xlabel="log(s²)",
+        ylabel="m",
         zlabel="Log probability",
         title=label,
     )
@@ -114,86 +109,93 @@ setprogress!(false)
 
 ### Gibbs
 
-Gibbs sampling tends to exhibit a "jittery" trajectory. The example below combines HMC and PG sampling to traverse the posterior.
+Gibbs sampling tends to exhibit a "jittery" trajectory.
+The example below combines HMC and PG sampling to traverse the posterior.
 
 ```{julia}
-c = sample(model, Gibbs(:s² => HMC(0.01, 5), :m => PG(20)), 1000)
-plot_sampler(c)
+c1 = sample(Xoshiro(468), model, Gibbs(:s² => HMC(0.01, 5), :m => PG(20)), 1000)
+plot_sampler(c1)
 ```
 
 ### HMC
 
-Hamiltonian Monte Carlo (HMC) sampling is a typical sampler to use, as it tends to be fairly good at converging in an efficient manner. It can often be tricky to set the correct parameters for this sampler however, and the NUTS sampler is often easier to run if you don't want to spend too much time fiddling with step size and the number of steps to take. Note however that HMC does not explore the positive values μ very well, likely due to the leapfrog and step size parameter settings.
+Hamiltonian Monte Carlo (HMC) sampling is a typical sampler to use, as it tends to be fairly good at converging in an efficient manner.
+It can often be tricky to set the correct parameters for this sampler however, and the NUTS sampler is often easier to run if you don't want to spend too much time fiddling with step size and the number of steps to take.
+Note however that HMC does not explore the positive values μ very well, likely due to the leapfrog and step size parameter settings.
 
 ```{julia}
-c = sample(model, HMC(0.01, 10), 1000)
-plot_sampler(c)
+c2 = sample(Xoshiro(468), model, HMC(0.01, 10), 1000)
+plot_sampler(c2)
 ```
 
 ### HMCDA
 
-The HMCDA sampler is an implementation of the Hamiltonian Monte Carlo with Dual Averaging algorithm found in the paper "The No-U-Turn Sampler: Adaptively Setting Path Lengths in Hamiltonian Monte Carlo" by Hoffman and Gelman (2011). The paper can be found on [arXiv](https://arxiv.org/abs/1111.4246) for the interested reader.
+The HMCDA sampler is an implementation of the Hamiltonian Monte Carlo with Dual Averaging algorithm found in the paper ["The No-U-Turn Sampler: Adaptively Setting Path Lengths in Hamiltonian Monte Carlo"](https://arxiv.org/abs/1111.4246) by Hoffman and Gelman (2011).
 
 ```{julia}
-c = sample(model, HMCDA(200, 0.65, 0.3), 1000)
-plot_sampler(c)
+c3 = sample(Xoshiro(468), model, HMCDA(200, 0.65, 0.3), 1000)
+plot_sampler(c3)
 ```
 
 ### MH
 
-Metropolis-Hastings (MH) sampling is one of the earliest Markov Chain Monte Carlo methods. MH sampling does not "move" a lot, unlike many of the other samplers implemented in Turing. Typically a much longer chain is required to converge to an appropriate parameter estimate.
+Metropolis–Hastings (MH) sampling is one of the earliest Markov Chain Monte Carlo methods.
+MH sampling does not "move" a lot, unlike many of the other samplers implemented in Turing.
+Typically a much longer chain is required to converge to an appropriate parameter estimate.
 
 The plot below only uses 1,000 iterations of Metropolis-Hastings.
 
 ```{julia}
-c = sample(model, MH(), 1000)
-plot_sampler(c)
+c4 = sample(Xoshiro(468), model, MH(), 1000)
+plot_sampler(c4)
 ```
 
 As you can see, the MH sampler doesn't move parameter estimates very often.
 
 ### NUTS
 
-The No U-Turn Sampler (NUTS) is an implementation of the algorithm found in the paper "The No-U-Turn Sampler: Adaptively Setting Path Lengths in Hamiltonian Monte Carlo" by Hoffman and Gelman (2011). The paper can be found on [arXiv](https://arxiv.org/abs/1111.4246) for the interested reader.
+The No U-Turn Sampler (NUTS) is an implementation of the algorithm found in the paper ["The No-U-Turn Sampler: Adaptively Setting Path Lengths in Hamiltonian Monte Carlo"](https://arxiv.org/abs/1111.4246) by Hoffman and Gelman (2011).
 
 NUTS tends to be very good at traversing complex posteriors quickly.
 
 
 ```{julia}
-c = sample(model, NUTS(0.65), 1000)
-plot_sampler(c)
+c5 = sample(Xoshiro(468), model, NUTS(0.65), 1000)
+plot_sampler(c5)
 ```
 
-The only parameter that needs to be set other than the number of iterations to run is the target acceptance rate. In the Hoffman and Gelman paper, they note that a target acceptance rate of 0.65 is typical.
+The only parameter that needs to be set other than the number of iterations to run is the target acceptance rate.
+In the Hoffman and Gelman paper, they note that a target acceptance rate of 0.65 is typical.
 
-Here is a plot showing a very high acceptance rate. Note that it appears to "stick" to a mode and is not particularly good at exploring the posterior as compared to the 0.65 target acceptance ratio case.
+Here is a plot showing a very high acceptance rate.
+Note that it appears to "stick" to a mode and is not particularly good at exploring the posterior as compared to the 0.65 target acceptance ratio case.
 
 ```{julia}
-c = sample(model, NUTS(0.95), 1000)
-plot_sampler(c)
+c6 = sample(Xoshiro(468), model, NUTS(0.95), 1000)
+plot_sampler(c6)
 ```
 
 An exceptionally low acceptance rate will show very few moves on the posterior:
 
 ```{julia}
-c = sample(model, NUTS(0.2), 1000)
-plot_sampler(c)
+c7 = sample(Xoshiro(468), model, NUTS(0.2), 1000)
+plot_sampler(c7)
 ```
 
 ### PG
 
-The Particle Gibbs (PG) sampler is an implementation of an algorithm from the paper "Particle Markov chain Monte Carlo methods" by Andrieu, Doucet, and Holenstein (2010). The interested reader can learn more [here](https://rss.onlinelibrary.wiley.com/doi/full/10.1111/j.1467-9868.2009.00736.x).
+The Particle Gibbs (PG) sampler is an implementation of an algorithm from the paper ["Particle Markov chain Monte Carlo methods"](https://www.stats.ox.ac.uk/~doucet/andrieu_doucet_holenstein_PMCMC.pdf) by Andrieu, Doucet, and Holenstein (2010).
 
-The two parameters are the number of particles, and the number of iterations. The plot below shows the use of 20 particles.
+The `PG` sampler takes a single parameter, which is the number of particles.
 
 ```{julia}
-c = sample(model, PG(20), 1000)
-plot_sampler(c)
+c8 = sample(Xoshiro(468), model, PG(20), 1000)
+plot_sampler(c8)
 ```
 
-Next, we plot using 50 particles.
+We'll also try using 50 particles:
 
 ```{julia}
-c = sample(model, PG(50), 1000)
-plot_sampler(c)
+c9 = sample(Xoshiro(468), model, PG(50), 1000)
+plot_sampler(c9)
 ```
diff --git a/usage/submodels/index.qmd b/usage/submodels/index.qmd
index b77a54cd1..b60befdcb 100644
--- a/usage/submodels/index.qmd
+++ b/usage/submodels/index.qmd
@@ -126,22 +126,11 @@ end
 rand(Xoshiro(468), outer_with_retval())
 ```
 
-You can also manually access the value by looking inside the special `__varinfo__` object.
-
-::: {.callout-warning}
-This relies on DynamicPPL internals and we do not recommend doing this unless you have no other option, e.g., if the submodel is defined in a different package which you do not control.
+:::{.callout-note}
+If you are using a submodel that is defined by another package, and the submodel does not include the latent variables in its return value, it will not be possible to access the latent variables.
+This will be remedied with new syntax in Turing in the near future; keep an eye out!
 :::
 
-```{julia}
-@model function outer_with_varinfo()
-    x ~ to_submodel(inner())
-    # Access the value of x.a
-    a_value = __varinfo__[@varname(x.a)]
-    b ~ Normal(a_value)
-end
-rand(Xoshiro(468), outer_with_varinfo())
-```
-
 ## Example: linear models
 
 Here is a motivating example for the use of submodels.
diff --git a/usage/troubleshooting/index.qmd b/usage/troubleshooting/index.qmd
index 12c45dc80..528a6ac07 100755
--- a/usage/troubleshooting/index.qmd
+++ b/usage/troubleshooting/index.qmd
@@ -19,6 +19,45 @@ using Turing
 Turing.setprogress!(false)
 ```
 
+## NaN `Dual` numbers when using ForwardDiff
+
+ForwardDiff.jl is the default automatic differentiation backend for Turing.jl, and is used 'under the hood' in many of Turing's functions, such as MCMC sampling with HMC/NUTS, or optimisation.
+
+Since v1.0 of ForwardDiff, a number of changes were made to equality and comparison operators on ForwardDiff's `Dual` type, which can surface many errors that were previously hidden.
+In particular, the presence of `NaN` values in gradients can cause various functions to fail, even when the value of the gradient is not directly used.
+
+For example:
+
+```{julia}
+# This works when not using Dual numbers
+sigma = 0.0
+Normal(1.0, sigma)
+```
+
+```{julia}
+#| error: true
+using ForwardDiff: Dual
+
+# This fails when using Dual numbers that contain NaNs
+dual_sigma = Dual(0.0, NaN)
+Normal(1.0, dual_sigma)
+```
+
+If you are encountering `NaN`-related issues that did not happen before, you should try [enabling NaN-safe mode for ForwardDiff](https://juliadiff.org/ForwardDiff.jl/stable/user/advanced/#Fixing-NaN/Inf-Issues).
+Specifically, you need to run:
+
+```julia
+using ForwardDiff, Preferences
+set_preferences!(ForwardDiff, "nansafe_mode" => true)
+```
+
+and then restart your Julia session.
+
+Note that this creates a `Preferences.toml` or `LocalPreferences.toml` file on your system.
+Because of this, unfortunately, there is no configuration option that Turing can expose for this: you have to run the above code yourself (this is a limitation of ForwardDiff.jl).
+
+Alternatively, consider [switching to a different AD backend]({{< meta usage-automatic-differentiation >}}).
+
 ## Initial parameters
 
 > failed to find valid initial parameters in {N} tries. This may indicate an error with the model or AD backend...
@@ -169,20 +208,6 @@ Alternatively, you can use a different AD backend such as Mooncake.jl which does
 
 ## GrowableArray warnings
 
-::: {.callout-warning}
-# This section refers to a future version of DynamicPPL.jl
-
-This warning refers to one that is in the upcoming release of DynamicPPL v0.40.
-They are not currently available in released versions of DynamicPPL.jl and Turing.jl.
-:::
-
-```{julia}
-using DynamicPPL
-if pkgversion(DynamicPPL) >= v"0.40"
-    error("This page needs to be updated")
-end
-```
-
 > Returning a `Base.Array` with a presumed size based on the indices used to set values; but this may not be the actual shape or size of the actual `AbstractArray` that was inside the DynamicPPL model. You should inspect the returned result to make sure that it has the correct value.
 
 This warning is seen when using a `VarNamedTuple` — a mapping of `VarName`s to values — that contains indexed variables (such as `x[1]`) but does not know what the type of `x` is.
@@ -199,20 +224,20 @@ Dict(@varname(x[1]) => 1.0, @varname(x[2]) => 2.0)
 
 or
 
-```julia
+```{julia}
 @vnt begin
-    x[1] = 1.0
-    x[2] = 2.0
+    x[1] := 1.0
+    x[2] := 2.0
 end
 ```
 
 you should use
 
-```julia
+```{julia}
 @vnt begin
     @template x = Vector{Float64}(undef, 2)
-    x[1] = 1.0
-    x[2] = 2.0
+    x[1] := 1.0
+    x[2] := 2.0
 end
 ```
 
diff --git a/usage/varnamedtuple/index.qmd b/usage/varnamedtuple/index.qmd
index 356536a4e..952574894 100755
--- a/usage/varnamedtuple/index.qmd
+++ b/usage/varnamedtuple/index.qmd
@@ -10,23 +10,6 @@ using Pkg;
 Pkg.instantiate();
 ```
 
-::: {.callout-warning}
-# This page refers to a future version of DynamicPPL.jl
-
-The changes on this page are being implemented in DynamicPPL v0.40.
-They are not currently available in released versions of DynamicPPL.jl and Turing.jl.
-The documentation is being written in advance to minimise the delay between the release of the new version and the availability of documentation.
-
-Please see [this PR](https://github.com/TuringLang/DynamicPPL.jl/pull/1164) and [this milestone](https://github.com/TuringLang/DynamicPPL.jl/milestone/1) for ongoing progress.
-:::
-
-```{julia}
-using DynamicPPL
-if pkgversion(DynamicPPL) >= v"0.40"
-    error("This page needs to be updated")
-end
-```
-
 In many places Turing.jl uses a custom data structure, `VarNamedTuple`, to represent mappings of `VarName`s to arbitrary values.
 
 This completely replaces the usage of `NamedTuple`s or `OrderedDict{VarName}` in previous versions.
@@ -55,7 +38,7 @@ Currently, `VarNamedTuple` is defined in DynamicPPL.jl; it may be moved to Abstr
 Very often, `VarNamedTuple`s are constructed automatically inside Turing.jl models, and you do not need to create them yourself.
 Here is a simple example of a `VarNamedTuple` created automatically by Turing.jl when running mode estimation:
 
-```julia
+```{julia}
 using Turing
 
 @model function demo_model()
@@ -75,14 +58,14 @@ res.params
 As far as using `VarNamedTuple`s goes, they behave very similarly to `Dict{VarName}`s.
 You can access the stored values using `getindex`:
 
-```julia
+```{julia}
 res.params[@varname(x[1])]
 ```
 
 The nice thing about `VarNamedTuple`s is that they contain knowledge about the structure of the variables inside them (which is stored during the model evaluation).
 For example, this particular `VarNamedTuple` knows that `x` is a length-2 vector, so you can access
 
-```julia
+```{julia}
 res.params[@varname(x)]
 ```
 
@@ -90,7 +73,7 @@ even though `x` itself was never on the left-hand side of a tilde-statement (onl
 This is not possible with a `Dict{VarName}`.
 You can even do things like:
 
-```julia
+```{julia}
 res.params[@varname(x[end])]
 ```
 
@@ -118,14 +101,14 @@ We strongly recommend reading [the DynamicPPL docs](https://turinglang.org/Dynam
 
 To create a `VarNamedTuple`, you _can_ use the `VarNamedTuple` constructor directly:
 
-```julia
+```{julia}
 VarNamedTuple(x = 1, y = "a", z = [1, 2, 3])
 ```
 
 However, this direct constructor only works for variables that are top-level symbols.
 If you have `VarName`s that contain indexing or field access, we recommend using the `@vnt` macro, which is exported from DynamicPPL and Turing.
 
-```julia
+```{julia}
 using Turing
 
 vnt = @vnt begin
@@ -161,7 +144,7 @@ A template is an array that has the same type and shape as the variable that wil
 
 For example, if your model looks like this:
 
-```julia
+```{julia}
 @model function demo_template()
     # ...
     z = zeros(2, 2, 2)
@@ -177,7 +160,7 @@ To specify a template, you can use the `@template` macro inside the `@vnt` block
 The following example, for example, says that `z` inside the model will be a 3-dimensional `Base.Array` of size `(2, 2, 2)`.
 The fact that it contains zeros is irrelevant, so you can provide any template that is structurally the same.
 
-```julia
+```{julia}
 vnt = @vnt begin
     @template z = zeros(2, 2, 2)
     z[1] := 1.0
@@ -187,7 +170,7 @@ end
 Notice now that the created VarNamedTuple knows that `z` is a 3-dimensional array, so no warnings are issued.
 Furthermore, you can now index into it as if it were a 3D array:
 
-```julia
+```{julia}
 vnt[@varname(z[1, 1, 1])]
 ```
 
@@ -198,7 +181,7 @@ Any expressions in templates are only evaluated once.
 
 You can also omit the right-hand side, in which case the template will be assumed to be the variable with that name:
 
-```julia
+```{julia}
 # Declare this variable outside.
 z = zeros(2, 2, 2)
 
@@ -215,7 +198,7 @@ Multiple templates can also be set on the same line, using space-separated assig
 
 If you have nested structs or arrays, you need to provide templates for the *top-level symbol*.
 
-```julia
+```{julia}
 vnt = @vnt begin
     @template y = (a = zeros(2), b = zeros(3))
     y.a[1] := 1.0