Qiskit-terra: result.get_counts(schedule) raises QiskitError

[lcapelluto]

Information

• Qiskit Terra version: master
• Python version:
• Operating system:

What is the current behavior?

In qiskit-terra qiskit.result.result.Result._get_experiment, there is an assumption that Schedules always have names. This isn't true, so trying to get results from a batch job execution gives an error.

Steps to reproduce the problem

When I run

job = execute(list_of_schedules, backend)
result = job.result()
result.get_counts(list_of_schedules[0])

I get the error:

QiskitError: 'Data for experiment "None" could not be found.'

because of these lines:

        # Key is a QuantumCircuit/Schedule or str: retrieve result by name.
        if isinstance(key, (QuantumCircuit, Schedule)):
            key = key.name

where schedule.name is None.

What is the expected behavior?

I should get my data from the result for the given Schedule.

Suggested solutions

We could remove the option to get results by Schedule as a key, and instead only take the index of the experiment for Schedules. We could force Schedules to have a name, but that adds unnecessary work on the user's side, so I don't prefer that. We could try to find a different way to match Schedules to their results rather than by Schedule name.

Extra info

This is how I actually made my batch of schedules.

# dt ~= 3.5e-9 from backend
experiments = []
for t in np.round(np.linspace(500e-9 / dt, 20_000e-9 / dt, 40)):
    schedule = Schedule()
    schedule += x_pulse << int(t)    # x_pulse and measure from CmdDef
    schedule += measure << int(t) + x_pulse.duration
    experiments.append(schedule)

[taalexander]

I think we should follow the same pattern as QuantumCircuit and automatically generate a name if not provided.

[taalexander]

In general, I think we should move towards have a common name generation mechanism between the various qiskit modules.

[lcapelluto]

I feel like this auto name generation leads to some of the confusion that was discussed last week, where names are sometimes used to specify type, sometimes used because the user wants to give an object a customized display name for plots or visualization, sometimes they're mixed up with labels, and sometimes they're used for other execution-altering info, like matching a pulse to the IQ values that will be played. I'm biased towards thinking name usage should be for "custom display name" purposes.

I do agree that there should be consistency where possible. Still, I believe that it's not obvious that adding the line experiments[10].name = "My Favorite Schedule!" would later cause result.get_counts(experiments[10]) to error. (Ik Schedules are immutable and we don't expect the name to change, my point is elsewhere.) On the other hand, if Schedules had a randomly generated .id/.pk, then I wouldn't be so surprised if I shot myself in the foot by messing with that.

[taalexander]

I agree that there is a need for strings for two purposes:

1. Transport: In this case a unique ID is typical, but there may be cases where the user wishes to set this. It does not need to be pretty and should follow some pattern.
2. Display: In this case, a user-facing string is desired.

Currently, they are the same thing for pulses. I think this problem is encountered through Qiskit.

[ajavadia]

Still, I believe that it's not obvious that adding the line experiments[10].name = "My Favorite Schedule!" would later cause result.get_counts(experiments[10]) to error.

This should not error. Something like this is doable in circuits. When you look up a result by result.get_counts(experiment_instance), this actually tries to match experiment_instance.name with a name among all the result experiments. In Qobj and Result, it is assumed all circuits/schedules have a unique name. I think being able to look up a result by experiment_instance, and not just experiment_index, is a useful convenience.

[taalexander]

I agree it is useful and this is how it works for a schedule as well. The
problem is that schedules do not autogenerated a name if one is not
provided at instantiation like is done with QuantumCircuit, or commands.

On Sun, Jul 21, 2019, 10:50 PM Ali Javadi-Abhari [e-mail]
wrote:

Still, I believe that it's not obvious that adding the line
experiments[10].name = "My Favorite Schedule!" would later cause
result.get_counts(experiments[10]) to error.

This should not error. Something like this is doable in circuits. When you
look up a result by result.get_counts(experiment_instance), this actually
tries to match experiment_instance.name with a name among all the result
experiments. In Qobj and Result, it is assumed all circuits/schedules have
a unique name. I think being able to look up a result by
experiment_instance, and not just experiment_index, is a useful convenience.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Qiskit/qiskit-terra/issues/2753?email_source=notifications&email_token=AAL3LNW7I3WEKOD6B5HA6GTQAUN6VA5CNFSM4H66UGXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2OTWGA#issuecomment-513620760,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAL3LNXGT6KVOLYI7HRGOQDQAUN6VANCNFSM4H66UGXA
.

[taalexander]

Is this still a problem?

[taalexander]

bump

[lcapelluto]

afaik, yes

[willhbang]

Anyone working on this? If not, i'll give it a shot.

Based on the discussion, it sounds like the correct fix (for now?) is to follow the auto name generation behavior of other Qiskit modules.
There's the open question for whether we need to define separate names throughout Qiskit to distinguish between an ID/reference and display names. Should we consider that outside the scope of this issue?

[taalexander]

I do not believe anyone is working on this and we welcome the help! I think you have the right approach to a fix, and I agree that this issue of ID/reference is out of scope here but does need to be addressed.

[lcapelluto]

Hello @willhbang! Any update on this?

[willhbang]

@lcapelluto waiting on review in my PR, i'll bump it