SOFTWARE DEVELOPMENT FOR EXPERIMENT CONTROL

点击翻译按钮获取中文摘要

This subproject is one of many research subprojects utilizing the resources provided by a Center grant funded by NIH/NCRR. The subproject and investigator (PI) may have received primary funding from another NIH source, and thus could be represented in other CRISP entries. The institution listed is for the Center, which is not necessarily the institution for the investigator. Objectives  The increasing use of the automounters and the steady Mail-in operation continue to place new and interesting demands on the flexibility and robustness of our systems. Therefore, we work continually to add features when need arises, while maintaining a modular and easily maintained architecture. Important objectives this year have included improving the use of the experiment-tracking database, PXDB, for scheduling and monitoring of the flow of users to the beamlines, and making a firm connection to the lab-wide databases of personnel data. We have increasing interest in more intelligence in the software systems, and continue to participate in, and in some cases to drive, the collaboration with the European dna automated data-collection project (http://www.dna.ac.uk/). Results  During this year we published a major paper on our software systems. We have made numerous small changes to the recently restructured CBASS, our experimental-control software. For example, we have created a new graphic for the CBASS Graphical User Interface in which the diffraction resolution at the edges and corners of the detector image are shown dynamically as one changes the detector distance; there are now resolution-based controls to accomplish this. There is also now control at X25 direct from CBASS for beam attenuators, beam size (slits), goniometer head x, y, and z, and the beamstop position. We are increasingly involved and increasingly satisfied with the dna collaboration. We stimulated the European members to incorporate the LBL code Labelit into dna as an indexing routine, and now have nearly perfect success in indexing images through use of default setup parameters. The simple way to employ this is simply to use the code "dna Strategy" for a crystal. Two diffraction images are recorded, one at the current position of the crystal, and one 90 deg from that. They are indexed independently and together, the results are checked for consistency, a Bravais lattice is deduced, and a strategy for data collection is proposed that takes all of the indexing results into account. This can be used either for a manually mounted crystal or for a series of crystals mounted by an automounter. The Mail-in scientists use it essentially all of the time, and automount robot users employ it regularly too. Expanded use of the automounters has led to ideas for expanded control. The operator may choose to watch the whole process, centering the crystal with the "click-to-center" utility, or she may trust to the ESRF-based C3D crystal-centering code. There is an option to shift from continuous automated control to a new "manual" mode, within which the software will mount the sample and determine the directory structure for the data, but will leave the rest up to the user for operations such as running energy scans. We have made two major upgrades to the database system PXDB. The first is to complete the connection to the BNL-wide databases that contain contact information for users. One database, connected to BNL Human Resources division, is that with information about BNL employees who use the beamlines. The other is for outsiders: the Guest Information System. We put a lot of effort into working this out, and it's now transparent  there is only one authoritative record of each of our users' data, and we keep a read-only copy, refreshed monthly, in our PXDB. The second major upgrade was to produce a live operations calendar for the six beamlines. Because it all operates within the password-protected Administrator environment of the PXDB it means that any PXOperator or beamline scientist may manipulate the calendar. The functions are to choose a beamline, to select a range of dates and times, and to select a research group from the list of registered groups. Then the administrator can indicate the type of visit  Rapid Access (a few days or weeks into the future), Quick ID Project (a few hours into the future), or Mail-In. Information about the experiment, such as whether the automounter will be used, will be transmitted to the responsible scientist and the PXOperators who will "start" the users. The users themselves may log into the PXDB to interrogate the calendar to find detailed information about their group's visit, and information about which PXRR staff will be assisting in the visit. There is a range of other capabilities, including keeping track of whether the user has accepted the offer of a running period, etc. Finally, there are two new administrative functions. The Crystal Summary screen shows a complete description and current location of all of a group's crystals within a puck or cane. This leads further to a screen showing all of the sweeps taken just for that crystal. This is useful especially for Mail-in scientists to keep track of total exposure, etc., as crystals are taken from one beamline or automounter to another. The Project Summary screen shows nicely formatted information about each project existing in the PXDB. This allows us administrators to get a feel for the scope of operations in the PXRR for reporting purposes. Plans  We will continue to refine every aspect of the integrated software environment, in an effort that is driven by suggestions and comments from our staff and users. We have put significant work into the development of an offline (web-based) data-collection request queue. The idea is for a PX Operator to be the only human at a beamline, but that there might be one, or even more, off-site clients working with crystals. The PXOp would know to focus on several automounter cassettes (pucks). The remote users would select certain crystals in certain pucks, and the PXOp would mount them and activate the request. Each user might select crystals for testing on a first cycle, then might request full data collection on a second cycle. In a corollary effort we are working to create a mechanism by which a user might define in advance particular spots on a large crystal that should be used for data collection, and to queue these up with the software we just described. We believe this will go a long way to combating degradation of data from crystal damage. Since this approach is entirely web based, security concerns and risks are drastically reduced. However we are working to build a live remote-operation system wherein users would have a view of beamline operation that is identical to the one inside the NSLS. The catch is cybersecurity, and we're working to sort this out. Significance  This software-development program is absolutely central to the PXRR's entire program of methods development, service to the community, and collaborative research. The operations staff and the experimenters interact with this software as a unified environment constantly. We take it very seriously and do the work in a professional, well documented, and well archived way. The modular structure has the dual property of allowing several people to work on different components of the system, and making it extremely adaptable to new ideas and new hardware. John M. Skinner, Matt Cowan, Rick Buono,William Nolan, Heinz Bosshard, Howard H. Robinson, Annie H¿roux, Alexei S. Soares, Dieter K. Schneider, and Robert M. Sweet. (2006) Integrated software for macromolecular crystallography synchrotron beamlines II: revision, robots and a database. Acta Cryst.. D62, 13401347.