Hi All. I'd like to introduce Arpit Agrawal. He's a physics graduate student at UMD and recently joined my group at JQI/ARL. His background is in computer science and quantum information theory. He has a masters degree in physics from IIT-Bombay. The plan is that Arpit's thesis work will be focused on building a trapped-ion application layer on top of ARTIQ. Locally he will work with my lab and the Monroe labs. Discussions and code examples from labs currently running ARTIQ (Oxford and NIST) would help bootstrap this process. Since it sounds like there's interest from a couple groups in this sort of project I'd like to discuss ways of working together on this.
> One solution to both of these problems would be to maintain a public > repository > with some ‘generic ion trap’ example code, which might eventually include a > wide > variety of examples submitted by different groups. It would be important that > the > code be clean, well-commented, PEP 8 compliant, etc. One way of doing this > fairly > painlessly would be for NIST to work with a group that is switching to ARTIQ > and > help them write good, well documented code that can be published. Getting together basic examples is a good starting point. The longer term aim for Arpit's work is an extensible trapped ion control framework that provides some degree of modularity. Both code and social structures are needed that facilitate upstream contributions by trapped ion groups. As Robert points out there's an opportunity to avoid group-by-group fragmentation of common-use code. > For use as a general tutorial, the magtrap code that Raghu/NIST has written is > too complex and contains too many behaviors/design features that are specific > to > our particular experiment. Sounds like an opportunity to learn from what NIST has done and refine where boundaries lie between what's "specific to a particular experiment" and what's general use. > This tutorial needs to stand on its own, without requiring the authors of the > tutorial to be available to answer questions Agreed that whatever is published should stand on its own. No single group can handle the load of fielding community Q&A. Ideally the Q&A will take place in a public forum where M-Labs and the broader ARTIQ trapped ion community can all contribute. > We are willing to collaborate with such a group to provide some general > guidance > on how we have solved relevant problems, and offer advice on efficient code > structure, > which would provide a benefit for the group getting started with ARTIQ, and > then for > other new users as the tutorial takes shape. Sounds like a good opportunity. Let's talk if you have an interest in working together on this. > I suggest that any tutorial(s)/example code be hosted in a separate > repository from > ARTIQ itself. Agreed. > It seems to me that > everyone who has working code will likely claim that their code is too > complex and too specific and that there are other priorities. We have > to break out of that circle. Agreed. The modularity and generic nature of the ARTIQ codebase is a demonstration that this is possible. Involvement from M-Labs would help shape the development of the resulting trapped ion code. Arpit is making good progress at understanding the internals of ARTIQ. As an under-the-hood exercise he's currently working with M-Labs to write a driver for the Sinara Zotino DAC. He will also spend time in an established qubit labs at UMD that is using the Sandia PyIonControl. Maybe a visit to NIST for a couple days is in order to see how you're using ARTIQ on the magtrap? Refactoring the magtrap code into more polished example code could be part of his bootstrapping process. -Joe On Wed, Aug 30, 2017 at 11:10 AM, Robert Jördens via ARTIQ <artiq@lists.m-labs.hk> wrote: > On Mon, Aug 28, 2017 at 5:22 PM, Slichter, Daniel H. (Fed) via ARTIQ > <artiq@lists.m-labs.hk> wrote: >>> What about publishing Raghu's code? It seemed pretty clean from the quick >>> look I had at it during NACTI. >> >> For use as a general tutorial, the magtrap code that Raghu/NIST has written >> is too complex and contains too many behaviors/design features that are >> specific to our particular experiment. It would require substantial work to >> retool it for use as a proper introduction for people who are new to ARTIQ, >> and this sort of work has lower priority than our scientific projects at the >> current time. This tutorial needs to stand on its own, without requiring >> the authors of the tutorial to be available to answer questions; if we just >> post existing code, there will be a million different questions about >> minor/irrelevant details (we have had this experience a great deal already >> when people have looked at our code), making it a huge time sink for us and >> not very useful to new users. >> >> The reason we suggested a collaboration with a new group starting up with >> ARTIQ is that they are best equipped to provide an accurate representation >> of the sorts of questions/confusions/pitfalls that typical new users might >> have, and so they will be able to comment their code and/or structure the >> tutorial to address these most efficiently. We are willing to collaborate >> with such a group to provide some general guidance on how we have solved >> relevant problems, and offer advice on efficient code structure, which would >> provide a benefit for the group getting started with ARTIQ, and then for >> other new users as the tutorial takes shape. > > Let me start by pointing out that specifically those new groups that > you suggest should write the example code are actually the ones most > interested in example code. They and potential ARTIQ adopters would > also be the ones benefiting most. This has been a request since the > beginning and was one when you guys were setting up the first > experiments. Your analysis that the code writing should be fresh and > still present in the creator's head is correct. That's the best phase > for writing documentation and example code. It seems to me that > everyone who has working code will likely claim that their code is too > complex and too specific and that there are other priorities. We have > to break out of that circle. > > -- > Robert Jördens. > _______________________________________________ > ARTIQ mailing list > https://ssl.serverraum.org/lists/listinfo/artiq _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
