Multiphoton and mixed-states simulation

#1

Hello!
I am using Perceval to simulate the performance of a real quantum photonic network where the information is encoded in the polarization. Thus, my input state would be a polarized and incoherent mixture of Fock States in the form: ρ = Σ p(n) |n><n|, which can be easily generated with the SVDistribution command. For instance:

P = [0.8, 0.15, 0.05] 
state = pcvl.SVDistribution()

for n in range(len(P)):
    state.add(pcvl.StateVector("|" + str(n) + "{P:H}"),  P[n])

The inconvenient is that the first release of the library cannot simulate modes with multiple polarized photons and the input state of the circuit has to be a BasicStates.
Despite I can always expand the SVDistribution on a basis of AnnotatedBasicStates, I cannot reduce the dimension of the Fock Space without compromising the correctness of my simulation.

Will the simulation of polarized multiphoton states be released soon? Otherwise I will have to start playing with the statevector.convert_polarized_state function. :smiley:
Thanks a lot!

#2

Hello @FGiorgino - thanks for using Perceval. I am working on that and plan to release an update for dealing with multiple polarized photons on a single mode next week - the key for that will be to use the “Stepper” backend. I will post on this thread how it will look like at the end of the week for your review.

Thanks again,
Jean

1 Like
#3

Hello @FGiorgino !
Here is the situation.

Initial design of Perceval was made for spatial mode encoding, with the assertion that it would be easy to map spatial to polarisation encoding. To support polarization, we are doubling the number of modes and the function convert_polarized_state is in charge of mapping input (and output) states. For input, today, it simply adds a simple HV state preparation unitary that converts |1,0> into Eh*|1_H,0>+Ev*|0,1_V>. The limitation is the one that we cannot have mixed states on a single mode.

However, there are easy cases where we can extend this:

  1. if on one mode with have i|H> and j|V> photons, we can simply omit the state preparation unitary and feeds these i,j photons directly on H and V modes. I think this will work for your purpose
  2. also, even if we keep the “state preparation unitary” for instance to feed a D-polarization (becoming (|H>+|V>)/√2, we could use the 2 input modes of this state preparation unitary to prepare other photons in an orthogonal basis - for instance - A-polarized photons on the same mode. 1. is in fact a special case where the state preparation unitary matrix is the identity matrix.

So in short, with these changes - we will able to have on the same mode any combination of photons coded on any orthogonal basis. If we want to go further - for instance having 3 photons in |H>, |V> and |D> polarization on the same input mode, then we will have to work with StateVectors…

Let us know if this works for you !

2 Likes
#4

Thanks @jsenellart and @nicolasheurtel for the kind replies!

I would definitely agree that working with StateVectors is the final solution and, as you wrote, with BasicStates it is only possible to express the photon content of your state in one basis.

If I understood correctly, I can either use the {|H>, |V>} basis (i.e. i photons in mode |H> and j photons in mode |V>) as you detailed in case 1. , or the {|D>, |A>} basis (i.e. i photons in mode |D> and j photons in mode |A>) as you detailed in case 2.
Of course this extends to any orthogonal basis.

I would be totally fine with this extension, because I need to feed the circuit with photons in one basis.
My concern is: during the execution of the circuit, might this basis limitation creates some problems?

Example:

  • Consider 2 modes circuit ;
  • I input |2{P:D}, 2{P:V}>
  • I apply a BS(η) getting, amongst other terms and regardless of the pre-factor, also |2{P:D}2{P:V}, 0>.

Does this causes troubles in the execution?
Actually this is more a curiosity, cause (now) in my circuit it does not happen for photons encoded in different basis to be in a single mode. But this will indeed be a useful feature to model, for instance, imperfect polarization rotators.

Thanks again for your precious help!

P.S. Thanks @jsenellart for the > correction on the other thread, I made here the same mistake lol. I swear I don’t always do it in my Python code :smiley:.

#5

I just realized that the problem I described before, might appear if the Stepper backend is used.

Indeed, because of the way the other backend are designed, when trying to compute the following matrix element:

input_states = [pcvl.AnnotatedBasicState("|2{P:D}, 2{P:V}>")]
output_states = [pcvl.AnnotatedBasicState(" |2{P:D}2{P:V}, 0>")]
pcvl.CircuitAnalyser(s_circuit, input_states=input_states, output_states=output_states)

I could get the AssertionError from the convert_polarized_state function because I tried to convert an output state containing a multiphoton component expressed in two different basis.

But honestly I’m not super familiar with the Stepper backend and the few times I’ve tried it the program failed. So, at the moment, I would just be fine with the extension of the code that @nicolasheurtel mentioned in his post.

#6

Hello @FGiorgino - we have just released (New Perceval Release : 0.4.0 - Encounter) a new version with the changes described by @nicolasheurtel :

Something like that will work:

input_state, prep_matrix = convert_polarized_state(pcvl.AnnotatedBasicState("|2{P:H}3{P:V},{P:D}{P:A}>"))

This is for the input and output, for output we think that we can also improve the usability - we are coming back to you with some ideas.

Thanks also for your feedback on the Stepper, feel free to send specific issues on GitHub issues here. We are working on the Stepper specifically for the next release with some new cool features…