pitt-diamond-qtech / quantum-pulse

pulse sequences for NV center quantum computing and sensing experiments
3 stars 9 forks source link

AWG waveform memory is limited and sequences and file writing need to take that into account #4

Open gurudevdutt opened 4 years ago

gurudevdutt commented 4 years ago

This is a difficult issue which may require some serious rewriting of the code. So first we should create tests with pytest that will fail when the sequences and files get too long for waveform memory, and then come up with algorithm to pass the tests.

gurudevdutt commented 4 years ago

Further thoughts about this: typical sequences that will need this are those which have very long delays in them or where a group of pulses is repeated many many times. to fix the long delay times might just require changing the clock rate for those parts, since effectively all channels are off during those times. For the second problem, it might be better simply to use the loop and jump table options of the AWG. But that solution might also allow to fix the first problem so we should investigate that and see. The issue is how does the code recognize those parts of the sequence and know to incorporate these solutions

gurudevdutt commented 4 years ago

<@UQ85HQFV5> <@UPQ151274> I'm trying to brainstorm an algorithm to handle the long sequences for the AWG which exceed its memory limit (issue4) .The problem is I would ideally like to separate out this part which depends on the specific AWG from the Sequence class implementation which is meant to interpret the sequence given by the user and create data from it, but not worry about transferring it to the AWG or other hardware related issues. Looking back at my current implementation of the sequence class, I see that I have used the AWG clock rate as a parameter to the Sequence class which means there is some dependence anyway. This may actually be good , since I could imagine now in the AWGFile class taking a sequence object which is too long, and chopping it up into smaller sequences or even finding a repeating block of either pulses or simply long delays (where everything is off) and decreasing the clock rate for those stretches so that the file gets shorter. In the first simplest algorithm, we could search for stretches of data that are 0 in all the channels and then create a sequence object which has 0's but at a lower clock rate and then write that to the AWG . It seems that I cannot seem to cleanly separate the hardware from the data in this implementation, although I need to think some more about the exact algorithm. Before i go ahead and pseudocode it, do you guys have any other thoughts on this, or idea of how to more cleanly separate the two parts? View in Slack