I was just curious about the use case for strip_solution.
I noticed that my files were too big when saving whole ode solutions using jld2 and whenever I loaded back the file using jldopen, the REPL was riddled with reconstructing things. Sometimes I could access individual fields like sol.u but not sol itself. So, I ended up creating a struct with just retcode, u and t fields and saving that.
What other information does strip_solution retain which might be useful for any later post processing? Is it better to just create a struct which saves the relevant information?
It should be effectively the same as doing that, since it removes all function information and only retains the algorithm information required for interpolation.
If the interpolation information is stored, does that mean that I can still call sol(t) on stripped solution where t is not part of the sampled points?
Edit: Turns out I cannot do that. Then how is the “algorithm information required for interpolation” used?
You should be able to? @jClugstor you didn’t accidentally strip the algorithm as well?
Yeah alg gets set to nothing, so does prob. It’s in the issue description to strip alg since it has function information.
I think the issue here is actually that prob is set to nothing and the interpolation tries to use sol.prob.p here. Solution might be to set every field in prob that can have functions to nothing, but keep prob.p?
That should probably be optional. Most algs do not have any function information, and none would be involved in the reconstruction at least.
The p isn’t used, even in the interpolation, if f isn’t used (i.e. if not lazy).
It still seems to use prob.p as input to sol.interp, whether the interpolation is lazy or not, here’s an issue