1 / 26

Synchrotron Software Expert: Freelance Consulting, Development, Training & More

Experienced professional with 20 years at ESRF, specializing in synchrotron software control. Offering services in software development and training. Partnered with diverse institutes. Noteworthy case studies shared.

sharonrafael
Download Presentation

Synchrotron Software Expert: Freelance Consulting, Development, Training & More

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TXO • freelance mxCuBE & more

  2. About • Worked at ESRF for roughly 20 years • Worked at basically all BLs and particularly MX beamlines • Pushed for automation projects from 2002 • Funded TXO ( TXOlutions.com ) in September 2011 • Personal and professional project • Freelance and more • Combined with exotic destinations (NGO work)

  3. Domain of expertise • Consulting , Development , Training • in • Software for experiment control in synchrotrons and small x-ray sources

  4. Assets • Proven experience in experiment control • Programming: Python, C/C++, Graphical interfaces • SPEC

  5. Portfolio Regular customer - CSS / Certified Scientific Software spec projects with Bessy, Pohang Acc., Indus2 mx software with MaxLab (I911-3) and Alba (Xaloc) Industrial - Xenocs

  6. mxCuBE and more • Do you remember? It was back in 2003 • It was already a big improvement • We also thought it was already quite complex :

  7. Components (2003)

  8. mxCuBE seen from ESRF • Automation key-stone • Integrated in the general ESRF strategy for software and instrumentation developments (and I mean, not only for MX beamlines)

  9. mxCuBE and ... • mxCuBE (at ESRF) is : • a graphical Python/Qt application based on BLISS framework • Underlying control of hardware done with spec and Tango • Collection routines (partly) done with spec macros

  10. If you want mxCuBE • You need: • A synchrotron, a beamline, a computer • Select and install all the hardware you will use • Install a number of pieces of software • Configure everything • And.... glue them all together with some dose of expertise !! • Test, validate, adapt • and then upgrade from time to time

  11. ... and more Complexity #1 - Features / Integration • Autocentring • EDNA • ISPyB • MD2 • Kappa and STAC • User login • Sample changer • Tango servers • Detector software • Remote access • Beamline alignment • SPEC • Taco • Crystal ranking • ADXV • Spiralcollection • Energyscan • PyMCA • Tango • Screening of crystals • CCP4 • Collectionqueue • Powder • Annealing • XRF analysis • Thumbnails Beamcentering Transmission Workflow Barcodes SR Machine info Cryo Resolution Radiationdamage Submitfeedback User office Holderlength ....

  12. Complexity #2 - Software internals • Bricks • Hardware Repository Server • Hardware Objects • Socket communication • Events • xmlrpc • LDAP • Qwt • Khoros • zmq • xmlconfiguration • Jive • ....

  13. Complexity #3 - Hardware • Icepap • Pilatus • Attenuators • Slits • i0 monitors • ..... (alright... you got the idea... )....

  14. Complexity #4 - Collaboration • Collaboration required at least at three levels: • Internal: MX group, BLISS, ISG, SciSoft, SEG • On site: EMBL / ESRF • Between partner institutes: MaxLab, Bessy, Alba, ESRF, Soleil

  15. MXCUBE @ ESRF

  16. Some notes out of this afternoon presentation • High degree of stardisationforusers (samecollect GUI) throughmxCuBE • Little automation (centring, EDNA, ISPyB) • Notclearto me howmuchqueues are usedoutside ESRF • Commonneedsmentioned (at least at twosites) • CATS irelecsamplechanger in mxCuBE • Centring in mxCuBE (autocentring) • UpgrademxCuBEwithoutoverwriting local changes • ISPyB

  17. REAL STORIES FROM THE FIELD / LESSONS LEARNT • Case Study 1: I911-3 @ MaxLab • Following ESRF choices. Perspective after some years. • Case Study 2: Xaloc @ Alba • Integrating mxCuBE technology within a different technical context

  18. Partners • ESRF had (and has) always a commitment to share developments • Initial strategy (MaxLab, Bessy) • Copy faithfully the choices made at ESRF • ESRF staff helped and trained MaxLab and Bessy staff • Conclusion: Good benefit for scientists and users. Standard cannot be stronger • Weakness of the model: • Local choices and constraints • Local expertise is limited (“alien” technology) • Evolution of the software / Local changes (overwritten) redesign rather than configure • ESRF staff availability

  19. CASE STUDY 1 - MAXLAB • I911-3 • Initially copied all ESRF choices (everything ! including the rackable PC model) • It has been running experiments with mxCuBE for years • First version needed adapting mxCuBE: • No sample changer, no ISPyB, no control of attenuators... • Some software developments were made locally, integrated. Proved the modularity of mxCuBE is good.

  20. C.S. 1 - MAXLAB (2) • But... • Software got frozen. No upgrades • ESRF kept adding features that did not get to Lund • New instruments (like sample changer arm) different from ESRF need to be integrated • Changes in staff made that the limited local expertise in mxCuBE became even more scarce

  21. C.S.1 - MAXLAB (3) • Situation after a first intervention: • Assessment of needs done • Number of bugs solved from very first version installation • Latest mxCuBE version v2.0 is now functioning and able to do collections but... many of the features (remember complex. slide no 1) are not yet available (they never were) • Still needs work (quite) • Good help from ESRF, EMBL, Maatel

  22. C.S. 1 - MAXLAB (4) After the intervention is finished: • Evolution/Upgrade will require effort • Local expertise still missing • Future upgrades will still be painful • MaxLab has chosen Sardana for Max-IV ( see next C.S.)

  23. CASE STUDY 2 - ALBA • Xaloc beamline • Freshly and successfully started • Local control system, software choices different from ESRF (Sardana, no SPEC, Qt4...) • The core of mxCuBE needs to be rewritten • Basic Data collection is already running with new system • Clear, committed goal to share and to profit the most of the collaboration

  24. C.S. 2 - ALBA (2) • ALBA will use, as such, software blocks like: • EDNA • PyMCA • C3D • .... • Willingtoprofit of experience in collectionsequences... but... how? • Workingnowonmulticollect, autocentring....

  25. Thoughts for discussion • Thought #1: How to make software Upgradable and Customizable? • Implementation (encapsulation, abstraction) • Interface between componentd (clear, stable, documented) - the train interoperability case • Configuration! Beyond the design mode (it would have ease the move from v1 to v2) • Multiple integration options always better than one (example of EMBL software) • Thought #2: How to make expertise to develop or to make it available? • Networking, communication, training • Thought #3: How to share developments? • Delegation, specialization, Or even.. why not...subcontracting (ahem) • Thought #4: The case of ISPyB ?

  26. TXO This presentation was brought to you by: • http://www.txolutions.com/

More Related