zlacker

SLAC Computer Science Research Dept. | Software Engineer | Menlo Park, CA | Full-time, Relocation Available

As part of a collaboration between the Computer Science Research Dept. at SLAC and the LCLS-II project, we're looking for a full-time engineer to help us build a high-performance monitoring system that will be used every single day once the machine comes up. This is a mission-critical system. The monitoring system will ingest between 100s of GB/s to 1 TB/s of data and be responsible for rendering it to the user in a way that will enable the science users to drive their experiments. Performance is obviously a goal here, but so are maintainability and extensibility. Building a system with low technical debt is a must for this project.

That project will be about 50% of your time; the other 50% will be more flexible and may involve engineering work on the next-generation runtime system Legion, which is a major project within our group. (http://legion.stanford.edu/)

Everything we do is open source.

We expect the monitoring system to be built primarily in Python and C++ on Linux using some combination of UI technologies (Qt), fault-tolerant storage technologies (Redis), high-performance compute (MPI or Legion), and high-performance networking (to interface with the data acquisition system).

For more information about the department, see:

https://www6.slac.stanford.edu/news/2016-05-26-slac%E2%80%99...

For more information on LCLS-II, see:

https://portal.slac.stanford.edu/sites/lcls_public/lcls_ii/P...

We're working to put the official job ad out now. Please contact eslaught@slac.stanford.edu if you are interested (subject line "AMI Project") and I will forward the link when it is ready.

>>eslaug+(OP)
Would you consider Rust or Go implementations?

>>iandan+Gv
One constraint is that the scientists would like this system to be something they can maintain on their own, and that (for better or worse) means using languages they are comfortable with. Python is obviously popular in science, and C++ seems to be the current de facto "fast" language of choice. It's likely we'll develop two versions of the system, of which one can be more "researchy" and therefore able to take on more technical risk. However, we'll still want to be strategic about what that risk is so that if the research side of the project is successful it could in theory become the production system.

>>eslaug+(OP)
Official job ad is up now:

https://chk.tbe.taleo.net/chk01/ats/careers/requisition.jsp?...