Sample.run fails with up to date master branches and newest version of qubit server on windows

[thchwhite]

After running into some initial problems, I updated redheatdos to the newest version of every piece of software including the manager and qubit server (downloaded of bintray). Now any time I try to run any scan I get the following error message:

Error                                     Traceback (most recent call last)
<ipython-input-13-ce295c67616b> in <module>()
----> 1 bq.t1(s, ['q4'])

C:\src\pyle\pyle\dataking\batch_qubit.pyc in t1(Sample, measure, delay, state, stats, name, save, collect, noisy, **kwargs)
    641
    642     data = sweeps.grid(func, axes, dataset=dataset, save=save, noisy=noisy,
--> 643                        **kwargs)
    644
    645     if collect:

C:\src\pyle\pyle\dataking\sweeps.pyc in grid(func, axes, dataset, **kw)
    321         dataset=dataset,
    322         abortPrefix=[1],
--> 323         **kw
    324     )
    325

C:\src\pyle\pyle\dataking\sweeps.pyc in _run(func, sweep, save, dataset, abortab
le, abortPrefix, collect, noisy, pipesize)
    220         params = dataset.params
    221         name = dataset.name
--> 222         data = np.vstack(it)
    223         kwargs = {'number': dataset.num, 'path': dataset.path} if save else {}
    224         return pyle.datavault.LocalDataSet(data, independents, dependents,

C:\Python27\lib\site-packages\numpy\core\shape_base.pyc in vstack(tup)
    228
    229     """
--> 230     return _nx.concatenate([atleast_2d(_m) for _m in tup], 0)
    231
    232 def hstack(tup):

C:\src\pyle\pyle\datasaver.pyc in capture(self, iterable)
    146         """
    147         with self as dataset:
--> 148             for data in iterable:
    149                 dataset.add(data)
    150                 yield data

C:\src\pyle\pyle\pipeline.pyc in gen()
    104             runners.append(runner)
    105             if len(runners) >= size:
--> 106                 done, result = advance()
    107                 if done:
    108                     yield result

C:\src\pyle\pyle\pipeline.pyc in advance()
     85             # loop over runners, advancing until one completes
     86             for runner in itertools.cycle(runners):
---> 87                 runner.advance()
     88                 if runner.done:
     89                     break

C:\src\pyle\pyle\pipeline.pyc in advance(self)
    128         if not self.done:
    129             try:
--> 130                 self.gen.next()
    131             except _DefGen_Return, e:
    132                 self.done = True

C:\src\pyle\pyle\pipeline.pyc in _run(gen)
    178             elif is_generator(result):
    179                 try:
--> 180                     for _ in _run(result):
    181                         yield
    182                     result = None

C:\src\pyle\pyle\pipeline.pyc in _run(gen)
    175                     result = result.result()
    176                 except Exception, e:
--> 177                     result = gen.throw(e)
    178             elif is_generator(result):
    179                 try:

C:\src\pyle\pyle\dataking\batch_qubit.pyc in func(curr_delay)
    636         jt_alg.compile()
    637
--> 638         data = yield Sample.run(jt_alg, stats, dataFormat='iqRaw')
    639         probs = ro.unpack_readout_probs(data, qubits, measure)
    640         returnValue(probs)

Error: (1) java.lang.RuntimeException: cannot convert data from '(*cb)' to '<*(v
v)|*c>' [payload=None]

Here I have used batch_qubit as an example

[maffoo]

It looks like the problem is with some recent decorator changes in pylabrad (https://github.com/labrad/pylabrad/commit/7f4f327e5b283536089a2b97bb0b713e7ca29c12). The dac calibration server's correct_iq_ft setting looks like the following:

In [5]: cxn.dac_calibration.correct_iq_ft
Out[5]: 
LabRAD Setting: "DAC Calibration" >> "Correct IQ FT" (ID=31)

Correct IQ data specified in the frequency domain.

This allows for sub-nanosecond timing resolution.

Args:
    data (list of tuple or list of complex): The frequency-domain IQ
        sequence to be deconvolved.
    zero_ends (boolean): If true, the first and last 4 nanoseconds will
        be set to the deconvolved zero value to ensure microwaves are off.

Returns:
    A tuple of deconvolved I DAC values and Q DAC values.

Accepts:
    *(v, v): I/Q data
    *c: I/Q data
    *(v, v): I/Q datab
    *c: I/Q datab

Returns:
    (*i, *i): Dual channel DAC values

Note in particular the accepted types: *(v, v): I/Q datab and *c: I/Q datab. Those should be *(vv)b and *cb, but it looks like the individual argument type strings are just getting concatenated so that the b just becomes part of the comment on the first param.

I'll file an issue on pylabrad, but for now can you try downgrading pylabrad to 0.95.1 on the machine where the servers are running? That should let you run until we get things fixed up in pylabrad.

[thchwhite]

This seems to have solved the problem. Thanks for the help!

-Ted

On Sun, May 22, 2016 at 9:50 PM, Matthew Neeley notifications@github.com wrote:

It looks like the problem is with some recent decorator changes in pylabrad (). The dac calibration server's correct_iq_ft setting looks like the following:

In [5]: cxn.dac_calibration.correct_iq_ft Out[5]: LabRAD Setting: "DAC Calibration" >> "Correct IQ FT" (ID=31)

Correct IQ data specified in the frequency domain.

This allows for sub-nanosecond timing resolution.

Args: data (list of tuple or list of complex): The frequency-domain IQ sequence to be deconvolved. zero_ends (boolean): If true, the first and last 4 nanoseconds will be set to the deconvolved zero value to ensure microwaves are off.

Returns: A tuple of deconvolved I DAC values and Q DAC values.

Accepts: (v, v): I/Q data c: I/Q data (v, v): I/Q datab c: I/Q datab

Returns: (i, i): Dual channel DAC values

Note in particular the accepted types: (v, v): I/Q datab and c: I/Q datab. Those should be (vv)b and cb, but it looks like the individual argument type strings are just getting concatenated so that the b just becomes part of the comment on the first param.

I'll file an issue on pylabrad, but for now can you try downgrading pylabrad to 0.95.1 on the server machine where the servers are running? That should let you run until we get things fixed up in pylabrad.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/martinisgroup/servers/issues/348#issuecomment-220886867

[maffoo]

@thchwhite, you can really show your thanks by reviewing the relevant pylabrad PR: https://github.com/labrad/pylabrad/pull/257 :)

[maffoo]

nvm, gonna leave this open until the pylabrad fix is in.

[jwenner]

@maffoo, looks like it's been merged in?

[maffoo]

Since I'm encouraging people to use release versions from PyPI, let's wait until we have a new pylabrad release.

[maffoo]

Released pylabrad 0.95.4 with the fix. Closing.