Issue: #10 - Introduce a FidelityComputer class (see qutip-qtrl) for custom fidelity types

[Akhils777]

I have introduced a new FidelityComputer class in qutip-qoc, modeled after the implementation in qutip-qtrl, to support custom fidelity types.

Changes Made:

• Added a new module: fidcomp.py under src/qutip_qoc/

• Implemented the FidelityComputer class with support for user-defined/custom fidelity functions.

• Integrated the class by importing it in the existing test_fidelity.py file for testing purposes.

• All 11 existing test cases passed successfully using the new implementation.

• Additionally, I created 6 new test cases locally to validate edge cases and custom fidelity types — these also passed.

Notes:

• The 6 new tests are currently local and not pushed to the repo — they can be added if needed.

• No changes were made to the overall API structure; this class is modular and can be easily extended or plugged into future workflows.

[pmenczel]

Hi and thank you for your contribution. I admit I am a bit lost. You add a lot of functions and classes, could you explain a bit more the overall structure? In particular, there are fidelity functions and FidelityComputer classes, and functionality seems to be duplicated between them? I also compare with the old qutip-qtrl FidelityComputers, and it seems that you have added additional ones?

Note also that there are some fidelity functions already in core qutip, and we don't want to duplicate the logic in qutip-qoc if possible.

We generally try to avoid adding new dependencies. Is it necessary to include numba? Could jax be used instead, which is a dependency already? (The tests fail because of this problem.)

You have created many functions and classes, but they are not used anywhere. You write "all 11 existing test cases passed successfully using the new implementation" but, as far as I can tell, none of the new code is used in the tests? You import the new module in the test file, but that doesn't mean it will actually be used?

In particular, this does not seem to solve issue #10 (which to be fair does not have a great description). The goal of this issue would be to allow custom fidelities to be used in the optimize_pulses routine. Doing so would perhaps involve enhancing the Objective module, and does not even necessarily require exactly the FidelityComputer classes from qutip-qtrl.

This could still be quite useful, and thank you for your work. But it needs a better explanation of what it does and does not.

[ajgpitch]

Yes, I agree with Paul's comments. The fidelity functions are not used in the class, which seems to be mostly just a copy paste from Qtrl.

There is some justification for having specific fidelity functions in QOC, as it is possible that some some types of fidelity are not implemented in qutip's core - I did not find a way to compare unitaries for instance when I looked a few weeks ago. There could also efficiency benefits, there are many calls to the fidelity function, so needs to be fast.

There is no test in here of any custom fidelity.

However, this is a good start and gives us opportunity to think of how best to implement this feature in QOC.

[Akhils777]

Seeking Guidance: Where to Merge In-Progress FidelityComputer Refactor (Some Tests Failing)

Hi all,

I'm currently working on a significant refactor of the fidelity calculation system in qutip-qoc. The main goal of this work is to:

• Completely remove the dependency on qutip_qtrl.fid_computer

• Introduce a standalone and JAX-compatible FidelityComputer class

• Update existing optimization algorithms (GRAPE, CRAB) to use this new system

I've opened a feature branch (fidelity-computer) and most test cases are passing, but a few key ones are still failing:

• GRAPE state-to-state optimization

• CRAB state-to-state optimization

• Parameterized CRAB optimization

I'd like to ask for guidance on the best place to merge this WIP branch so others can review or collaborate, without affecting the stability of main. I noticed branches like patrick/ideas, 20-autmatically-convert-to-superoperat..., and others — but I’m not sure if any of these are used as a dev/integration branch.

Would it be appropriate to:

• Merge temporarily into a new dev/fidelity-computer branch from main?

• Use one of the existing branches for collaboration/testing?

• Hold off entirely until all test cases pass?

I’ll be continuing work to fix the remaining tests and will follow up with a stable PR once everything is resolved.

Thanks in advance for any guidance!

Best,
Akhil Pratap Singh

[pmenczel]

Hi and sorry for the slow replies. I see that you have opened another PR on the same topic. Should this one be closed then?

[ajgpitch]

@Akhils777 has declared that this supersedes #40, so I am closing this now.