Add number of repetitions

[philipstarkey]

Original report (archived issue) by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

---

A 'number of repetitions' feature would be quite handy. This feature should make experiment scripts being run for n times when in repetition mode and then stop. The main use case for this would be collecting a specific amount of statistics on measurements.

[philipstarkey]

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

---

Another way to do this, that might be a better workflow I think, is to define some globals in runmananger:

#!python

nreps = 5
repno = range(nreps)

with repno having the outer expansion setting. This way runmanager will create the desired number of repetitions up-front, rather than them being created by BLACS later.

I suspect this probably fits more with the idea of collecting data for statistics. BLACS's repeat mode is more often used in my experience to see how things are changing over time, say, whilst an adjustment is made to optical alignment or something like that, rather than for collecting a specific amount of data for statistical purposes. If you're actually planning to do a fixed number of repetitions per shot, then that seems to fit more logically to me in the "creating shots" part of the experiment process than in the "executing shots" part. It also means you can use runmanager's "shuffle" feature to randomise the shots, whereas otherwise BLACS repetitions of a list of shots will have the same order every time the shots are executed, leading to possible systematic errors in the statistics due to something that changes over time rather than with the input variables.

So I think I'm inclined to disagree with adding this functionality to BLACS unless there is some other useful use-case.

[philipstarkey]

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

---

I see your point and yes a global would work, but that would slow things down for very short experiments, where the shot time is smaller than the runmanager compilation time. Our experiments usually take between 1 and 2 seconds and we commonly run into runmanager being slower than blacs. To speed things up we commonly use the end of our shot to prepare the MOT for the next shot (to make use of blacs programming time). If however blacs finishes one shot before the next has finished compiling this time begins to vary and the start conditions of the next experiment might be affected. So I still think this feature would be a improvement.

[philipstarkey]

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

---

Ah, I see.

Relatedly, since you have such short shots, you might be interested in this recent change, which speeds up the time in-between shots a bit for BLACS.

There is a feature request at the moment for functionality to ensure reliable repetition rates of shots, as in, making sure that BLACS leaves enough time for programming, but then waits an additional amount of time so that it runs shots at fixed intervals. Part of ensuring reliable rep rates, as you point out is also ensuring that shots from runmanager are ready to go. That's something I hadn't realised.

So I think I can probably fix this as part of implementing that feature, without adding any more settings the user would have to configure (other than their desired repetition interval). Runmanager could see what the target rep rate is, compare it to how long it is taking it to compile shots and how long those shots are to last, and make sure it accumulates a sufficiently large pipeline of shots (likely only one or two) before starting to submit them to BLACS. If I do this right, then configuring a fixed rep rate would make this happen automatically.

It would also be more compatible with "keeping warm" of experiments In our lab for example. In our lab the experiment is in "repeat final" mode, indefinitely repeating the last shot that it had, just to keep the experiment warm and in a stable state. Then, we submit some new shots from runmanager. If the number of repetitions was configured in BLACS rather than in runmananger, BLACS would need some way of distinguishing between that last shot that it was repeating to keep warm (which is to be repeated indefinitely until new shots arrive), and the new shots, which are to be repeated a fixed number of times (but then the final shot repeated indefinitely again to keep warm). So BLACS would have to get a bit more clever there, and adding a "repeat 5 times" option would not really be sufficient to have reliable rep rates in the presence of a requirement to keep the experiment warm.

So, I think the solution might be pipelining from runmanager - unless you're saying that shots actually take longer to compile than they take to run? Because in that case no length of pipelined shots will be long enough. In this case, I think probably runmnaager should grow an option to generate repeated shots by copying files rather than running the re-compilation again - which would just be a performance optimisation because compilation is being slow. In either case I think it's useful for the repeated shots to be generated by runmanager rather than BLACS, but I understand the need to make shot compilation faster!

Incidentally, do you know what aspect of compilation is slow? I would be interested in making it faster if it is being a bottleneck.

[philipstarkey]

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: pstarkey).

---

I also agree that this should not be in BLACS (although once we get the plugin architecture fleshed out some more, you're welcome to write this yourself as an optional extra for people).

I believe the runmanager option will be suitable for you once we fix labscript issue 38 (labscript-suite-temp/labscript#38). Our complex BEC experiment compiles in 0.65 seconds when I implement a temporary fix. Note that the latest (untagged) version of labscript introduces even more delay to compilation, so I would avoid that too!

Can I ask you to check your compilation time with labscript changeset f5dadbb93aef (labscript-suite-temp/labscript@d12cd3f9cb2e1c71fec1c9f0f5ccd7c51f246e9d) (which I think should have fast compilation times) and let me know if implementing the repeats with runmanager is fast enough for you?

[philipstarkey]

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

---

• changed priority from "major" to "minor"

[philipstarkey]

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

---

We already implemented a change that is almost identical to that blacs speedup change you mentioned a while back.

Pipelining sounds great in the modified way you described.

Your reasoning behind not making this a feature of blacs seams quite reasonable. I will make a feature request for runmanager and resolve this one. Since I still think it should be a time improvement to just copy files rather then recompiling them.

And yes our compilation times are slower than our run times this could be due to the modifications made in our compile process, like the ramp collision check and shutter delays check you just backed out of. We had these implemented before I came to our group a few weeks ago so I don't know if compilation was faster before. Will definitely check if things are improved without them.

[philipstarkey]

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

---

• changed state from "new" to "closed"

Will move feature request to runmanager

[philipstarkey]

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

---

Removing the ramp and shutter checks didn't have much of a effect. Removing mercurial cut my compile time in half! Thanks for the tip @philipstarkey I guess compile times are fast enough without mercurial.