23 ms·

Speaking of BNL/CERN, there is the code SixTrack which is/was used for both RHIC and LHC for collimation studies and long-term tracking. That's the worst I've

Speaking of BNL/CERN, there is the code SixTrack which is/was used for both RHIC and LHC for collimation studies and long-term tracking. That's the worst I've ever seen. There were a few files of "normal" length but the main sixtrack source file was fifty-five thousand lines long and featured a custom-written preprocessor's directives throughout (since Fortran has no preprocessor, or for some other erason) that allowed different features to be enabled at compile time. And this was used to design the LHC collimation system and to check the machine's dynamic aperture. I should also add that this is recent/still the case. P.S. agreed about Twitter, I always wonder what these people are like in real life.

earthscienceman 5y ago
I imagined some people would crop up with experience at RHIC/CERN. I never touched the SixTrack code directly but I've heard legend. The compile time features was a constant on all the projects I touched there and was such a hilarious relic. "The code is flexible! Just know these completely undocumented flags or spend months grokking the dense/obtuse/scattered source files and you can make the code do anything you want, all these hard coded constants will change". As ugly as things like SixTrack were, I vaguely trust them just because there were usually a lot of eyes on them... even if they were hideous. The more obscure chunks of code that were somewhere in the analysis chain were the ones that really terrified me. I worked on a lot of the code for simulating detector upgrades (I won't get more specific than that) and that was a terrifying place. Designing entire multi-billion dollar detectors systems based on hundreds of different pieces of code and output data that were glued together with no over-arching design or integration. The code 'review' usually came down to "that output looks good"... or not... Related to this, I now work in the atmospheric sciences, and a completely-unrelated-but-oddly-similar problem exists in the various modeling communities. So many fragmented pieces of code glued together and untouched or touched with no real computing oversight. So many wasted computing cycles. So many failure points.
- ethbr0 5y ago
  RHIC/CERN seems like the perfect storm of incredibly intelligent and motivated people, coupled with time pressures and a lack of software development knowledge. Add in the fact that their "business" logic requires a PhD, and you've got an extremely limited subset of software developers who even could work on the code. Most places, you'd figure people just wouldn't be smart enough to Rube Goldberg their way into a functional program. But someone who does high energy physics as their primary job is assuredly capable of torture a compiler as thoroughly as they want. F.ex. look at the issues: https://github.com/SixTrack/SixTrack/issues https://github.com/SixTrack/SixTrack/issues > remove gamma_e from calculation of kick by elens. the gamma_e factor comes from moving from the electron frame to the lab frame. It is actually compensated by the lorentz transformation applied to the electron current density You know you're in for fun when the docs start with "SixTrack is wonderful, but it is bloody complicated." https://twiki.cern.ch/twiki/bin/view/LHCAtHome/SixTrackDoc https://twiki.cern.ch/twiki/bin/view/LHCAtHome/SixTrackDoc

earthscienceman 5y ago

I imagined some people would crop up with experience at RHIC/CERN. I never touched the SixTrack code directly but I've heard legend. The compile time features was a constant on all the projects I touched there and was such a hilarious relic. "The code is flexible! Just know these completely undocumented flags or spend months grokking the dense/obtuse/scattered source files and you can make the code do anything you want, all these hard coded constants will change". As ugly as things like SixTrack were, I vaguely trust them just because there were usually a lot of eyes on them... even if they were hideous. The more obscure chunks of code that were somewhere in the analysis chain were the ones that really terrified me. I worked on a lot of the code for simulating detector upgrades (I won't get more specific than that) and that was a terrifying place. Designing entire multi-billion dollar detectors systems based on hundreds of different pieces of code and output data that were glued together with no over-arching design or integration. The code 'review' usually came down to "that output looks good"... or not... Related to this, I now work in the atmospheric sciences, and a completely-unrelated-but-oddly-similar problem exists in the various modeling communities. So many fragmented pieces of code glued together and untouched or touched with no real computing oversight. So many wasted computing cycles. So many failure points.

ethbr0 5y ago
RHIC/CERN seems like the perfect storm of incredibly intelligent and motivated people, coupled with time pressures and a lack of software development knowledge. Add in the fact that their "business" logic requires a PhD, and you've got an extremely limited subset of software developers who even could work on the code. Most places, you'd figure people just wouldn't be smart enough to Rube Goldberg their way into a functional program. But someone who does high energy physics as their primary job is assuredly capable of torture a compiler as thoroughly as they want. F.ex. look at the issues: https://github.com/SixTrack/SixTrack/issues https://github.com/SixTrack/SixTrack/issues > remove gamma_e from calculation of kick by elens. the gamma_e factor comes from moving from the electron frame to the lab frame. It is actually compensated by the lorentz transformation applied to the electron current density You know you're in for fun when the docs start with "SixTrack is wonderful, but it is bloody complicated." https://twiki.cern.ch/twiki/bin/view/LHCAtHome/SixTrackDoc https://twiki.cern.ch/twiki/bin/view/LHCAtHome/SixTrackDoc