Pausable Dashboard Experiment

dreens

Hi there,

So let's say I want to set up some beefy scans in an experiment that will run via the dashboard, but due to some instability in my system, I will occasionally need to pause the experiment (to go re-lock a laser, to re-optimize ion-laser overlap, etc.)

One way to do this would be to have my experiment call a non-kernel function every few seconds which checks for user input on some extra dialogue window I setup myself outside of the dashboard. That window could have a pause button, and maybe a few other callbacks for backing up a few datapoints, changing other variables (like histogram separation thresholds assigning 0/1 for the qubit).

But I'd rather do it through the dashboard, since this seems like the whole point of a dashboard. Any tips?

Thanks,
Dave

sb10q

Here's one way to do it: make your long scan experiment call scheduler.pause() at appropriate moments. Then when you want to pause it, schedule another experiment in the same pipeline (which may do nothing, or do something to help you relock the lasers etc.) with a higher priority, which will keep running until you terminate it (if it also calls scheduler.pause(), you can use the "graceful termination" feature)

dreens

Hey thanks, that works pretty well. I guess I could also have my experiment re-pull constants from a file if it finds that it was actually paused by the scheduler when it re-runs. That way thresholds can be updated during the pausing and so on.

sb10q

You should be able to call self.get_dataset to retrieve updated values and should not need an additional file.

dreens

Interesting... so datasets are sort of global with respect to different experiments scheduled via the dashboard? Do they also persist if the dashboard is closed and reopened? (which would make them potentially suitable for storing long term information relevant to the experiment such as carrier frequencies, pulse lengths, etc)

dreens

Also, more related to the actual question at hand- I like the idea of running something with higher priority as a way to pause a dashboard experiment which makes regular calls to pause and check_pause. But what if I want the experiment to pause itself??

One nice reason to do this would be to have a long and detailed spectroscopy run check back on a known line frequency now and then, to make sure that the spectroscopic lightsource hasn't come unlocked. If the program found this to be the case, it would ideally pause itself, wait for me to relock the laser and run some higher priority script to update the known line frequencies in case of any drift, and then go back to operation.

The problem I'm encountering is that if I just have the experiment call an RPC that waits around for user input, if too much time passes it just throws a ConnectionReset Error once it finally receives user input (for example 20 minutes later) and tries to get going.

sb10q

The dashboard is just a network client. Datasets are managed by the master, and always persist across a dashboard restart, and sometimes persist (if you use the persist argument in the set_dataset call) across a master restart.

dreens The problem I'm encountering is that if I just have the experiment call an RPC that waits around for user input, if too much time passes it just throws a ConnectionReset Error once it finally receives user input (for example 20 minutes later) and tries to get going.

This isn't normal. I suppose the connection failing is the one to the core device. This can be due to a high packet loss rate on your network, or to this bug: https://github.com/m-labs/artiq/issues/1125

ngkiaboon

dreens If it's not too much trouble, can I have a copy of your code that does this pause through RPC and a brief description on how to use it? I need something for my experiment as well. Thanks in advance!

dreens

Hey thanks sb10q. These ConnectionReset Errors came to a head recently (2 per minute). I addressed it by power cycling an "unmanaged media converter" from FS.com sitting between the computer and the kasli for converting RJ45 to SFP. I was thinking to replace this device, and the fiber that connects it to the Kasli, with an RJ45 to GBIC1000T converter that sits right in the Kasli's SFP slot. Galvanic link and all, but if lets me run without all the dropped packets...

sb10q

Galvanic link? Isn't there a transformer behind every RJ45 port?

dreens

Indeed. Never knew this before, very nice, thank you.

dreens

Hi Kia, good to hear from you and sorry I missed this. I just checked the box in my settings to make sure I get an email next time someone replies to a thread I'm in. Code is a little cluttered right now but here is the key idea:

# This is called by the checkAndReload function to prevent overexposure of the trap to the PI beams.
def userInput(self):
    a = ''
    while a!='go':
        print('Type ''go'' and then ENTER to continue:\a') 
        a = input('')

Your core device can call this rpc as long as you pause the scheduler before, and be sure to break_realtime just after it runs. The input command will lock the shell where you run artiq_master from, and the "\a" will even make your system beep at you to let you know something is up. If you wanted you could pull up a window or something, but this mostly works and is easy. It is a bit weird because the master shell will like remember anything you type there, so if you type "go" and then enter a bunch of times, it will remember that and pull it out of std input hours later when it attempts to pause.

Cheers.