Upgrade TaylorSeries, TaylorIntegration and TaylorModels

[lbenet]

Closes #804

[lbenet]

I don't understand why the tests are broken; locally things behave better... Any advice?

[schillic]

We need to first propagate the new version through the dependencies. That would be at least LazySets, RangeEnclosures, and Flowstar. I started the process, but it will take some time.

FYI, to reproduce, you can use using TestEnv; TestEnv.activate(); to activate the test environment locally. This way you also do not have to add the package to the test environment.

[schillic]

We need to first propagate the new version through the dependencies. That would be at least LazySets, RangeEnclosures, and Flowstar. I started the process, but it will take some time.

I just ran the tests with the master version for these packages and then tests pass 🎉

[schillic]

There is an error with evaluate(X, tdom) where X is a Taylor model (see the test log). Looks like a bug in the other packages.
BoundsError: attempt to access 1-element Vector{HomogeneousPolynomial{IntervalArithmetic.Interval{Float64}}} at index [2]

[lbenet]

There is an error with evaluate(X, tdom) where X is a Taylor model (see the test log). Looks like a bug in the other packages. BoundsError: attempt to access 1-element Vector{HomogeneousPolynomial{IntervalArithmetic.Interval{Float64}}} at index [2]

I'll have a look...

[lbenet]

The problem is that evaluate (in TaylorSeries) is picking up the wrong method, so it is an inference method. I'll patch TaylorSeries this afternoon...

[schillic]

I do not understand why the documentation build does not find the new version.
(I know that it takes some time for packages to be available after a release, but we already skip this delay via JULIA_PKG_SERVER: '' in the build script. I suspected that we only skip it for the tests, but we also do for the documentation.)
Maybe we can try again tomorrow.

[schillic]

It still does not work. My current suspicion is that this is because of the cache that is being used by the build. Maybe when you push the new version for the small docstring changes it will skip the cache. Otherwise we can just build it locally and ignore it here.

EDIT: Locally the build runs through. So I propose we ignore it here.

[schillic]

Here is the current status wrt. known models:

• ReachabilityAnalysis: All models still work. This includes the Brusselator which used TMJets20.
• ClosedLoopReachability: All models still work.
• ARCH-COMP AINNCS: All models still work.
• ARCH-COMP NLN: All models except one still work. The one that does not work anymore is Spacecraft, which used TMJets20.
  • While looking at the model, I found that the version used here in ReachabilityAnalysis is inconsistent. It contains a new update but does not contain an older update. I opened two alternative PRs: Adapt Spacecraft settings to ARCH-COMP2020 #814 to undo the new update and Adapt Spacecraft settings to ARCH-COMP2022 #815 to add the older update.
  • I have not yet investigated whether different parameter settings with the other algorithms can be used.
    EDIT: I found a setting where the new algorithm works (was as easy as raising orderT by 1). However, the algorithm is a lot slower (130 seconds vs. 24 seconds).

[schillic]

I found a "fix" for the spacecraft benchmark, but it is a lot slower (see the previous comment). Still, I think the benefit of being able to use the new versions again outweighs this cost for me. @mforets, what is your opinion?

I would prefer to not use the algorithm names 1 and 2 and rather unify the structs and pass a new option. But I can take a look at this in a later step. So we should not make a release immediately.

So from my side, this PR is good to go. I will mark it as ready.

[lbenet]

Thanks @schillic for looking onto the performance consequences. I'll try to have a look onto that tomorrow.

I would prefer to not use the algorithm names 1 and 2 and rather unify the structs and pass a new option. But I can take a look at this in a later step. So we should not make a release immediately.

I like the proposal of making a more uniform API; yet, there are some differences wrt the parameters that each method uses, which may add some complications.

[schillic]

@lbenet I will merge and then do some renaming in a follow-up PR -> #818.