<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Ramping up</title>
	<atom:link href="http://www.quantumdiaries.org/2012/03/27/ramping-up/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.quantumdiaries.org/2012/03/27/ramping-up/</link>
	<description>Thoughts on work and life from particle physicists from around the world.</description>
	<lastBuildDate>Wed, 19 Jun 2013 09:34:24 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Aidan Randle-Conde</title>
		<link>http://www.quantumdiaries.org/2012/03/27/ramping-up/#comment-64717</link>
		<dc:creator>Aidan Randle-Conde</dc:creator>
		<pubDate>Sun, 15 Apr 2012 00:47:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.quantumdiaries.org/?p=21311#comment-64717</guid>
		<description><![CDATA[Hi Xezlec, sorry for the late reply.  When things get busy here they get very busy, and while blogging is a lot of fun it&#039;s purely recreational!  Acoustics sounds like it could get intractable very quickly without the right kind of help, definitely a field where we&#039;d like to see software engineers at the wheel.  The more experience a particle physicist has, the more they realize that most of what they do is software design.

In the past couple of decades a good working knowledge of computing has become deeply entrenched.  It&#039;s almost certainly not intentional.  I worked on the first large HEP experiment to use a C++, and it was initially developed in-house.  ATLAS learned from this experience and got professionals to set up the bulk of the framework.  Since then most of the new development and maintenance has been the responsibility of the physicists.  Insane?  Maybe, but there&#039;s a lot of inertia at this point and changing the arrangement would require a huge overhaul of how we work.  Particle physicists may be many things, but at the top of the list you&#039;ll usually hear the words &quot;arrogant&quot; and &quot;skeptical&quot;.  One must pry the code from our cold, dead hands!

We use quite a few tools to help us debug, including gdb and valgrind, but we usually print output to the terminal first, which is much quicker and cheaper.  As you can imagine there are occasionally problems, such as runaway processes consuming 95% of the memory of a node, but 100% of all the CPUs.  Sometimes I think it would be better if worked more like you do, with a well defined separation of roles.  Then again I suppose that would spoil some of the fun.  Last night I ran some jobs over the data on a whim to satisfy my curiosity.  That wouldn&#039;t be possible if there was a person between me and analyzing the data.]]></description>
		<content:encoded><![CDATA[<p>Hi Xezlec, sorry for the late reply.  When things get busy here they get very busy, and while blogging is a lot of fun it&#8217;s purely recreational!  Acoustics sounds like it could get intractable very quickly without the right kind of help, definitely a field where we&#8217;d like to see software engineers at the wheel.  The more experience a particle physicist has, the more they realize that most of what they do is software design.</p>
<p>In the past couple of decades a good working knowledge of computing has become deeply entrenched.  It&#8217;s almost certainly not intentional.  I worked on the first large HEP experiment to use a C++, and it was initially developed in-house.  ATLAS learned from this experience and got professionals to set up the bulk of the framework.  Since then most of the new development and maintenance has been the responsibility of the physicists.  Insane?  Maybe, but there&#8217;s a lot of inertia at this point and changing the arrangement would require a huge overhaul of how we work.  Particle physicists may be many things, but at the top of the list you&#8217;ll usually hear the words &#8220;arrogant&#8221; and &#8220;skeptical&#8221;.  One must pry the code from our cold, dead hands!</p>
<p>We use quite a few tools to help us debug, including gdb and valgrind, but we usually print output to the terminal first, which is much quicker and cheaper.  As you can imagine there are occasionally problems, such as runaway processes consuming 95% of the memory of a node, but 100% of all the CPUs.  Sometimes I think it would be better if worked more like you do, with a well defined separation of roles.  Then again I suppose that would spoil some of the fun.  Last night I ran some jobs over the data on a whim to satisfy my curiosity.  That wouldn&#8217;t be possible if there was a person between me and analyzing the data.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Xezlec</title>
		<link>http://www.quantumdiaries.org/2012/03/27/ramping-up/#comment-61168</link>
		<dc:creator>Xezlec</dc:creator>
		<pubDate>Wed, 28 Mar 2012 22:13:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.quantumdiaries.org/?p=21311#comment-61168</guid>
		<description><![CDATA[Interesting.

We do acoustics.

Regarding memory leaks, hopefully you&#039;re aware that there are tools that solve these kinds of problems for you.  Tools like dmalloc and valgrind will tell you exactly where your leaks are.

I&#039;ve heard of this DIY attitude before... I once went to a seminar where the speaker had to spend a few minutes convincing the audience that you should use existing fft libraries instead of rolling your own!  That dropped my jaw a few inches.  I hope he succeeded in persuading them.]]></description>
		<content:encoded><![CDATA[<p>Interesting.</p>
<p>We do acoustics.</p>
<p>Regarding memory leaks, hopefully you&#8217;re aware that there are tools that solve these kinds of problems for you.  Tools like dmalloc and valgrind will tell you exactly where your leaks are.</p>
<p>I&#8217;ve heard of this DIY attitude before&#8230; I once went to a seminar where the speaker had to spend a few minutes convincing the audience that you should use existing fft libraries instead of rolling your own!  That dropped my jaw a few inches.  I hope he succeeded in persuading them.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aidan Randle-Conde</title>
		<link>http://www.quantumdiaries.org/2012/03/27/ramping-up/#comment-61112</link>
		<dc:creator>Aidan Randle-Conde</dc:creator>
		<pubDate>Wed, 28 Mar 2012 12:16:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.quantumdiaries.org/?p=21311#comment-61112</guid>
		<description><![CDATA[Hey Xezlec!  To answer the first question, we have sophisticated algorithms that reconstruct the tracks left by charged particles and group them into primary vertices.  This way we can separate the events based on their physical location along the beam axis.  The overlap of two bunches is about 15cm in the z-direction, so our resolution is fine enough.  There are sometimes problems (two events can be merged giving one  primary vertex, or one event can be split giving two  primary vertices, but these effects tend to be rate.)  Using this information we can keep track of which particles came from which event in the reconstruction.  It&#039;s not perfect, but it&#039;s usually good enough.  (You can see an example shown in the CERN Courier/Institute of Physics: http://images.iop.org/objects/ccr/cern/51/10/19/CCcat2_10_11.jpg)

In response to the second question: tell me about it!  Most physicists learn how to code through example, with very little (if any) formal training.  I&#039;ve seen code that would make you wince.  (A while back I wrote a post about the kinds of bugs we tend to get and how they drive us crazy (http://www.quantumdiaries.org/2011/06/27/quantum-bugs/)  I&#039;m guessing that we&#039;d have a lot less trouble with these if we had professional programmers!  Having said all that, we do have some very talented coders here and they tend to be responsible for the overall structure of larger projects.  I once sat down and watching as one of these experts pulled my code apart, rearranged it and put it back together.  He explained every step and made me think about things I&#039;d never even considered about making the code more robust and futureproof.  The end result was a module that worked pretty much perfectly, and I&#039;ve never had any problems with the parts of the code he wrote.  (It was still heartbreaking to see all my labor be ripped apart before my eyes, but life is tough in the world of programming!)

Three of the major factors that inform the decision to make the physicists take responsibility for the code are that whoever writes the code must be very knowledgeable in specific areas of the field they&#039;re working in.  I&#039;m not sure how much of this we can do with matlab (probably a lot) but there have been several instances in the past where the existing tools just weren&#039;t good enough, and this lead particle physicists to develop tools such as ROOT (our main analysis framework) Roofit (a fitting package tailored to particle physics), TMVA (a multivariate analyzer) and StatPatterRecognitiion (another multivariate analyzer).  Now each one of these packages could have been developed in cooperation with more experienced software engineers, but the decision was made, for better or for worse) to write it all ourselves.  It comes with benefits and penalties, of course.

The second reason is simply a matter of time.  We have bleeding edge software (I call it hemorrhaging edge, especially when we get memory leaks!) and if we get physicists to change the code we can get very rapid changes at very short notice (ie a physicist will stay in the lab until 2am at no extra cost to get the result out if there&#039;s a hard deadline.)

The third reason is that we are extremely skeptical of what our code actually does.  It&#039;s very easy to use a &quot;black box&quot; application and get a biased answer without realizing it, so we like to be able to go through our code with a fine tooth comb and fully understand what it&#039;s doing.

This attitude that we should do it all ourselves goes further than just software development, we also write our own papers, whereas in most other industries/fields there are secretaries that write the LaTeX documents for us.  We write our own papers and if you&#039;ve ever seen an internal review process you can tell!  It seems that our best software starts with good developers, and our best papers end with good editors.  And yes, it&#039;s normal to spend about a week discussing what colors to use in the plots for the papers!

What kind of physicists do you work with?  It would be interesting to hear how other fields handle their software!]]></description>
		<content:encoded><![CDATA[<p>Hey Xezlec!  To answer the first question, we have sophisticated algorithms that reconstruct the tracks left by charged particles and group them into primary vertices.  This way we can separate the events based on their physical location along the beam axis.  The overlap of two bunches is about 15cm in the z-direction, so our resolution is fine enough.  There are sometimes problems (two events can be merged giving one  primary vertex, or one event can be split giving two  primary vertices, but these effects tend to be rate.)  Using this information we can keep track of which particles came from which event in the reconstruction.  It&#8217;s not perfect, but it&#8217;s usually good enough.  (You can see an example shown in the CERN Courier/Institute of Physics: <a href="http://images.iop.org/objects/ccr/cern/51/10/19/CCcat2_10_11.jpg" rel="nofollow">http://images.iop.org/objects/ccr/cern/51/10/19/CCcat2_10_11.jpg</a>)</p>
<p>In response to the second question: tell me about it!  Most physicists learn how to code through example, with very little (if any) formal training.  I&#8217;ve seen code that would make you wince.  (A while back I wrote a post about the kinds of bugs we tend to get and how they drive us crazy (<a href="http://www.quantumdiaries.org/2011/06/27/quantum-bugs/" rel="nofollow">http://www.quantumdiaries.org/2011/06/27/quantum-bugs/</a>)  I&#8217;m guessing that we&#8217;d have a lot less trouble with these if we had professional programmers!  Having said all that, we do have some very talented coders here and they tend to be responsible for the overall structure of larger projects.  I once sat down and watching as one of these experts pulled my code apart, rearranged it and put it back together.  He explained every step and made me think about things I&#8217;d never even considered about making the code more robust and futureproof.  The end result was a module that worked pretty much perfectly, and I&#8217;ve never had any problems with the parts of the code he wrote.  (It was still heartbreaking to see all my labor be ripped apart before my eyes, but life is tough in the world of programming!)</p>
<p>Three of the major factors that inform the decision to make the physicists take responsibility for the code are that whoever writes the code must be very knowledgeable in specific areas of the field they&#8217;re working in.  I&#8217;m not sure how much of this we can do with matlab (probably a lot) but there have been several instances in the past where the existing tools just weren&#8217;t good enough, and this lead particle physicists to develop tools such as ROOT (our main analysis framework) Roofit (a fitting package tailored to particle physics), TMVA (a multivariate analyzer) and StatPatterRecognitiion (another multivariate analyzer).  Now each one of these packages could have been developed in cooperation with more experienced software engineers, but the decision was made, for better or for worse) to write it all ourselves.  It comes with benefits and penalties, of course.</p>
<p>The second reason is simply a matter of time.  We have bleeding edge software (I call it hemorrhaging edge, especially when we get memory leaks!) and if we get physicists to change the code we can get very rapid changes at very short notice (ie a physicist will stay in the lab until 2am at no extra cost to get the result out if there&#8217;s a hard deadline.)</p>
<p>The third reason is that we are extremely skeptical of what our code actually does.  It&#8217;s very easy to use a &#8220;black box&#8221; application and get a biased answer without realizing it, so we like to be able to go through our code with a fine tooth comb and fully understand what it&#8217;s doing.</p>
<p>This attitude that we should do it all ourselves goes further than just software development, we also write our own papers, whereas in most other industries/fields there are secretaries that write the LaTeX documents for us.  We write our own papers and if you&#8217;ve ever seen an internal review process you can tell!  It seems that our best software starts with good developers, and our best papers end with good editors.  And yes, it&#8217;s normal to spend about a week discussing what colors to use in the plots for the papers!</p>
<p>What kind of physicists do you work with?  It would be interesting to hear how other fields handle their software!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Xezlec</title>
		<link>http://www.quantumdiaries.org/2012/03/27/ramping-up/#comment-61031</link>
		<dc:creator>Xezlec</dc:creator>
		<pubDate>Wed, 28 Mar 2012 02:29:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.quantumdiaries.org/?p=21311#comment-61031</guid>
		<description><![CDATA[I have a couple questions.

First of all, how on Earth do you tell which stuff came from which events with a pileup of 20-30?

Second, why do particle physicists write their own code?  I&#039;m a software engineer, and my job is to write the software for the physicists at my company.  They mock things up in Matlab sometimes, but ultimately we write, maintain, and optimize the production code, and it&#039;s a lot of work, even for a dedicated development team!  It just seems odd to have a bunch of physicists wasting their time on something other than their own field.  I mean, physicists lack the training of a real programmer or engineer.  They also don&#039;t necessarily have time to stay up to date with the latest technologies in the software world.]]></description>
		<content:encoded><![CDATA[<p>I have a couple questions.</p>
<p>First of all, how on Earth do you tell which stuff came from which events with a pileup of 20-30?</p>
<p>Second, why do particle physicists write their own code?  I&#8217;m a software engineer, and my job is to write the software for the physicists at my company.  They mock things up in Matlab sometimes, but ultimately we write, maintain, and optimize the production code, and it&#8217;s a lot of work, even for a dedicated development team!  It just seems odd to have a bunch of physicists wasting their time on something other than their own field.  I mean, physicists lack the training of a real programmer or engineer.  They also don&#8217;t necessarily have time to stay up to date with the latest technologies in the software world.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: [blog post] Ramping up &#171; aidan@cern</title>
		<link>http://www.quantumdiaries.org/2012/03/27/ramping-up/#comment-60888</link>
		<dc:creator>[blog post] Ramping up &#171; aidan@cern</dc:creator>
		<pubDate>Tue, 27 Mar 2012 14:45:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.quantumdiaries.org/?p=21311#comment-60888</guid>
		<description><![CDATA[[...] Read more&#8230; Share this:TwitterFacebookLike this:LikeBe the first to like this post. [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Read more&#8230; Share this:TwitterFacebookLike this:LikeBe the first to like this post. [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
