-
Notifications
You must be signed in to change notification settings - Fork 320
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
initial project plan #1
Conversation
If you're not familiar with github's pull requests, the easiest way to look at this doc is to click on "Files changed," then "Display the rich diff" to see the markdown rendered, but then go back to "Display the source diff" and click on the plus sign next to a line number in order to comment on a particular line. |
@chrede88 I take it merging means you agree with all this? Comments from all are still welcome here. In the future, assuming the pull request is made by a core contributor who's authorized to merge (which is mostly going to be me I imagine) let's follow this protocol:
Even if it's generally just me writing most of this, I'll still try to get someone else to peek at each new piece of code - I'll try to spread it around so nobody is overloaded but everyone stays in the loop. |
Hehe.. Sure:) wasn't sure how we were supposed to act! Sent from my iPhone
|
@alexcjohnson looking good - I say let's dance! 💃 @majacassidy @spauka is there anyone from your teams who still needs to be added to the github team? |
A phone app to check the current measurement/fridge status would make me double 👯 during phase 3 |
Hi Guen, Looks good :) Could you also add Christian Dickel to the QCodes group? His Github id is Cheers, Adriaan On Fri, Jun 12, 2015 at 10:04 PM Guen P [email protected] wrote:
|
Hey, Everything looks great! Is there still a plan to present something at the meeting in a few weeks? Will there be anything extra to prepare before then? I'll let you know if there is anyone to add shortly... Sebastian |
There won’t be anything formal at the meeting (too early). Alan and I will be meeting with the PIs to get buy-in and agreement on strategy for development and release. We’ll keep everyone informed as to results. From: Sebastian Pauka [mailto:[email protected]] Hey, Everything looks great! Is there still a plan to present something at the meeting in a few weeks? Will there be anything extra to prepare before then? I'll let you know if there is anyone to add shortly... Sebastian — |
Hi All, Can you please add my student Damaz de Jong (github ID: Damazter) to the group. He is doing a lot of the advanced code development from our side. For an 'app' for checking on measurements/fridges, we use freeboard together with dweet. It will take you less than 30 mins to get set up and be dweeting the status of your fridges/measurements that you can view in a browser. As an example, our fridge monitoring board is here: More info on dweet is at dweet.io. There is a python package 'dweepy' that allows you to send your messages. The latest version of the code for handling dweets for an Oxford fridge is available on Damaz's github account. Best, Maja |
@majacassidy that looks pretty cool 💃 thanks! |
@AdriaanRol : @cdickel has been invited but hasn't accepted yet. @majacassidy : I've invited @damazter - thanks! And dweet / freeboard does look pretty cool. |
fyi, I've forked the code I've been using to take data here: @alexcjohnson I'd like to implement threading or multiprocessing to speed up my data acq. I tried using the instrument server (based on rpyc) but it's giving me virtual memory issues.. so now I just load the instrument channels in the same process as the experiment, but would like to do that separately so I can talk to the same set of instrument channels from multiple notebooks. do you have any advice on how to make the instrument channels live in their own process? would you use threading or a socket or..? (same goes for a 'plotting' and 'data storage' process) Also, I happened to pass by the lab in Delft last week and here's some results/ideas from talking to @damazter and @AdriaanRol
|
@guenp just so you know, Alex is on vacation (driving down the left coast of the U.S.) and will then be moving until mid-July, so don't expect a speedy response. I saw him here last week in Seattle but he's now pretty much incommunicado. |
@guenp thanks for the input! I don't have any a priori conclusion about the best way to separate the processes. I've never used rpyc but it may be worthwhile to pursue that a little as it should be more flexible than the other solutions I'm aware of - we may just need to be careful to keep its connections lightweight - though that would sacrifice some of the flexibility 😾 in which case we might be better off going back to straight sockets or via a message queue (might be the most robust solution, but not the lightest, and then we have to worry about extra installation dependencies) |
* beginnings of vna driver extension to get spectroscopy mode working * debug spec mode on ZNB * measuting with ZNB * removed T3 specific modifications, now in wrappers pr #1 * removed unused imports, time and partial * The znb may return a float so round before casting to an int
Codecov Report
@@ Coverage Diff @@
## master #1 +/- ##
========================================
Coverage ? 79.9%
========================================
Files ? 49
Lines ? 6673
Branches ? 0
========================================
Hits ? 5332
Misses ? 1341
Partials ? 0 |
* [DEM-564] Create a new HDAWG8 driver from ZI example
Typofix: changed 'NOR' to 'NORM', so it works
sync my fork to upstream master
Pull master from core QCoDeS
Integrate Change from estebans pr
Use one thread per instrument
@qdev-dk/qcodes this is a long time coming as I'm still disentangling myself from my other job 😄 - but here's the general outline that we came up with at the meeting a few weeks ago. Comments, additions, corrections are all welcome!
@guenp I haven't figured out the correspondence between all the real people and their github ids - anyone else we still need?