CompatHelper: bump compat for SciMLOperators to 1, (keep existing compat)

[github-actions]

This pull request changes the compat entry for the SciMLOperators package from 0.3, 0.4 to 0.3, 0.4, 1.
This keeps the compat entries for earlier versions.

Note: I have not tested your package with this new compat entry.
It is your responsibility to make sure that your package tests pass before you merge this pull request.

[codecov]

Codecov Report

❌ Patch coverage is 90.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 94.07%. Comparing base (7a6cc50) to head (455b24d).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/time_evolution/time_evolution.jl	88.88%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #470      +/-   ##
==========================================
- Coverage   94.08%   94.07%   -0.01%     
==========================================
  Files          51       51              
  Lines        3533     3530       -3     
==========================================
- Hits         3324     3321       -3     
  Misses        209      209              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Krastanov]

Hi, folks! This one seems to be a blocker for adding a QuantumToolbox backend to QuantumSymbolics. It seems QuantumSymbolics/QuantumOptics has a dependency on a more recent version of SciMLOperators, causing a clash in our downgrade check. It is potentially solvable on our end, but I wanted to first check whether you have plans to merge this in the near future, as it will simplify our work.

See QuantumSavory/QuantumSymbolics.jl#121 (comment)

[ytdHuang]

@Krastanov

This is an issue that troubled us for a long time since SciMLOperators releases v1.

It returns incorrect results in some of our runtests.
Also, a huge extra memory allocation is detected compare to v0.4 when using it with OrdinaryDiffEq.

And we don't know what the problem is and how to fix it...

[Krastanov]

Ah, that is frustrating... Some of your team are at JuliaCon right now, right? Let's meet up and corner Chris about it. In the meantime we will see whether there is some simple workaround we can use in QuantumSymbolics. Let's grab a meal together before/after the quantum mini symposium and we can discuss more.

[ytdHuang]

@Krastanov

Yes, unfortunately, I cannot attend JuliaCon this time.
But @albertomercurio should be there.

[albertomercurio]

Hi @Krastanov, yes I'm at JuliaCon, so we can discuss about it.

I was planning to fix it after the conference. I don't expect huge changes, at least in the QuantumToolbox.jl side. I may expect to make some changes directly in SciMLOperators, as they have some regressions since v1.0:

• Memory allocations when solving ODE with ScaledOperator SciML/SciMLOperators.jl#247

[albertomercurio]

Ok, the previous PR in SciMLOperators.jl has been merged. I now opened this new one

• Improve IdentityOperator and ScaledOperator actions SciML/SciMLOperators.jl#289

With all these changes all my local tests pass. So, let's wait a new release of SciMLOperators and we should be ready to merge this PR.

[albertomercurio]

The SciMLOperators has released v1.4, should we set SciMLOperators == 1.4 and also trigger all CI pipelines to make sure everything works ?

In principle yes, in practice I have also asked to update SciMLBase, so that we can remove the custom method for SDEFunction, as done in this PR

• Add methods for SDEFunction in case of SciMLOperators v1+ SciML/SciMLBase.jl#1072

But I can write a comment to remove that definition once a new version of SciMLBase is released.

[albertomercurio]

The quality error is due to piracy, as we are defining a new method for SDEFunction. This should be fixed with the new release of SciMLBase.jl. Should we still merge it, or wait?

The Makie error is related to a newer version of Makie itself, which can be now installed probably due to compatibility with SciMLOperators.jl. I reduced the Makie version in the compat file. We can fix it separately in another PR. As you can see they have some deprecated functions.

[ytdHuang]

I agree with the Makie issue.

For the SciMLBase piracy issue, since this PR SciML/SciMLBase.jl#1072 is merged already.

Maybe we should also wait SciMLBase to release new version and also bump our [compat] for SciMLBase ?

Up to you.