Jürgen Fuhrmann

Adapt to https://github.com/JuliaLang/julia/pull/48469 ?

2

Possibly we should adapt to https://github.com/JuliaLang/julia/pull/48469 .

Planned breaking changes for v3.0

6

- [ ] Remove old preconditioner interface, FactorizationStrategy - [ ] Don't re-export ForwardDiff.value - [ ] Don't export `data` function - [ ] Fight piracies - [ ] Full...

Think about alternative assembly using sparsity detection etc. based on DifferentiationInterface. First benchmarks show promising performance: https://github.com/JuliaDiff/DifferentiationInterface.jl/issues/774

DON'T MERGE! Run subset of tests with ForwardDiff 1.0

2

See https://github.com/WIAS-PDELib/VoronoiFVM.jl/pull/195#issuecomment-2787461073

... or finally implement a decent GridRegionEditor... In 3D, I have seen an integer overflow with the current default.

Currently, we access data using grid[T] where T is a type. However, this is occasionaly leads to tpype instabilities. By defining ``` (::Type{T})(grid::ExtendableGrid) where T

For 3D Makie plots, the axis limits are ignored when plotting from a Pluto notebook. Instead, the unit cube is assumed.

this is the newer version of PyPlot

Extend CI

2

See https://github.com/WIAS-PDELib/GridVisualize.jl/pull/39#issuecomment-2503998781 At least the julia side logic is realistic to be tested for CairoMakie, PyPlot, PlutoVista. So we should go for it.

Move SparseArrays dependency to extension

3

This should help to resolve https://github.com/SciML/LinearSolve.jl/issues/573