[Feature] Time-dependent generator proposal

[vytautas-a]

Closes #395

[RolandMacDoland]

1. HamEvo can be modified to accept TDGenerator objects as generator and then in the backend it can be checked whether pyq or Schrodinger equation solver must handle the simulation. In this way HamEvo act as a placeholder that potentially can store time-dependent blocks.

Wouldn't it be easier to just consider time-dependence as a parameter ? And we can pass values just like any other parameter currently ? Ie. reuse the TimeEvolutionBlock ?

2. Do we allow TDGenerator objects to be part of the circuit on their own, without being encapsulated in HamEvo?

Not sure. It would make for non-unitary computations right ?

3. Do we create a separate backend for Schrodinger equation solvers or integrate them into pyq?

I would rather integrate it in PyQ because: 1) we've got that elsewhere and 2) it would make a nice addition to PyQ and make it a complete DA backend. But this needs to be thoroughly discussed.

4. What is the place of TDGenerator in the hierarchy of blocks, e.g., should it inherit from AbstractBlock or be completely standalone?

If we follow the TimeEvolutionBlock route, it naturally inherits from AbstractBlock.

[vytautas-a]

TDGenerator as a class is mainly for encapsulating schedule of generators (essentially, when to use what blocks) and doing operations on these schedules. But underlying blocks are parametrized blocks already now.

TimeEvolutionBlock if I understand correctly, currently is just some kind of a placeholder class that doesn't have it's own functionality. I could move all the stuff from my TDGenerator to TimeEvolutionBlock.

[jpmoutinho]

Thanks @vytautas-a! This is a good start!

Do we create a separate backend for Schrodinger equation solvers or integrate them into pyq?

I also think integrating something into PyQ would be the best.

HamEvo can be modified to accept TDGenerator objects as generator and then in the backend it can be checked whether pyq or Schrodinger equation solver must handle the simulation. In this way HamEvo act as a placeholder that potentially can store time-dependent blocks.

Do we allow TDGenerator objects to be part of the circuit on their own, without being encapsulated in HamEvo?

What is the place of TDGenerator in the hierarchy of blocks, e.g., should it inherit from AbstractBlock or be completely standalone?

I have a few thoughts on this but we can discuss it in a call :)

[vytautas-a]

One more thought: if we want to support mixing the new time-dependent HamEvo block with ordinary blocks in the same circuit, it would make sense to all the blocks derived from HamEvo and assign them a constant generator with some default "duration". This way all the blocks would have proper time treatment, however if the HamEvo generator is found to be constant the usual pyq simulation would take place for these blocks. Thus, we would use ODE solver only where it is needed.

[RolandMacDoland]

One more thought: if we want to support mixing the new time-dependent HamEvo block with ordinary blocks in the same circuit, it would make sense to all the blocks derived from HamEvo and assign them a constant generator with some default "duration". This way all the blocks would have proper time treatment, however if the HamEvo generator is found to be constant the usual pyq simulation would take place for these blocks. Thus, we would use ODE solver only where it is needed.

True, although I think this should be set when instantiating the block right ? Say, X(0) would implicitly set the generator time parameter to be the right phase to realise the unitary, which might also be backend dependent. Or am I missing something here ?