This was a surprisingly satisfying week. Work was actually fairly joyful. I did a fair bit of writing on small projects and email, some very useful reference chasing across two national labs, sent some software QA experience/advice(?) to a third national lab team, and dug up a 1988 DOE report on aerosol modeling written by people I worked with at my previous employer (I read the papers the report was based on maybe 10 years ago when I was recovering a standalone code that implemented the model.) It was good being reminded that I worked with some fabulously talented and decent people there (difficult to remember that sometimes because of a few abusive jackasses). It was nice having closure on a bunch of small incremental tasks after months of endless death-march reports.

There's just so much work that needs to be done on a tight schedule, there's no way to do everything to the degree of completion necessary to eliminate risk, but I'm working with people who are smart and capable and on the same page. Communication is pretty decent for how geographically scattered the team is. It's hectic but not chaotic and people still treat each other with respect and dignity despite the aggressive schedule and the stress. It's nice feeling trusted and appreciated after the misery of 2008-2017. I feel I'm still crawling out of that hole and that I'm incredibly lucky to be working with such a great bunch of people now.

The obscure report I unexpectedly dug up has the cheerful friendly title "Modifications for the Development of the MAAP-DOE Code, Volume VIII: Resolution of the Outstanding Nuclear Fission Product Aerosol Transport and Deposition issues WBS 3.4.2" https://www.osti.gov/servlets/purl/6300735

My first real world exposure to scientific software development and software engineering was two summers interning at FAI writing diagnostic routines for version 3 of the MAAP severe accident analysis code. I had my first encounter with system administration in the form of George Hauser, the gentleman in charge of FAI's small VAX cluster. This was the days of having a dedicated reliable and trustworthy terminal on your desk (IIRC it was an actual VT-220). Code editing was interactive but code was generally run in batch. Jobs might take hours or days to complete which would monopolize your terminal if run interactively. The practice was to run a job interactively for the first few minutes of a scenario to confirm it didn't immediately crash, then run the full case as a batch job, basically the same as running sbatch with Slurm but in the early 90s.

Now we have an unreliable overly complex insecure graphical terminal that serves ads, spies on you, and changes application UIs every few days without warning. Progress!

The terminal used dark mode by default. An elegant weapon for a more civilized age.

One of the mathematical terms and concepts I'm still trying to wrap my head around is the discussion on aerosol coagulation surrounding Eq. 2-1, specifically the "kernel" function k(v, vbar):

For applied math, statistics, and related engineering/physics people who might be reading this, where would I look to get an accessible explanation of this population_1/collision kernel/population_2 technique? Doing a web search on "kernel" is ... unhelpful. I think I understand what is being expressed here but I want to see a more introductory step-by-step derivation or explanation because this makes my head hurt.

Do I need to read that statistical mechanics text that starts off with the bleak reminder that both Ludwig Boltzmann and Paul Ehrenfesr died by suicide "and now it is our turn to study statistical mechanics."?

I mean, given my usual choice of reading material, I should've predicted this.

Luckily I take out most of my self-destructive urges while playing Obenseuer so I have somewhat innoculated myself against the potential harms of this subject. If the topic gets overwhelming I'll fire up the game and drink some laundry detergent just to see what happens. :)

#IHaveBrainProblems

@arclight I'm pretty sure it's one of these https://en.wikipedia.org/wiki/Kernel_(statistics) . Which one should become clear from context, so for example, if your distribution is parametric, you can slide past the kernels used for the ones that aren't.

Re: statistical mechanics, you have to make a call. You're doing it, so you can say, "I'm just doing a little of this. I do not have time to learn this self-harm-inducing subject. I just need to get through this little bit and then forget I ever had to." Or you can say, "This is a territory. Learning something about its history and its shape can help me navigate it," or "This is what I wish I'd done as a career!"

It's probably gonna be somewhere between the first and second, but don't discount the third.

Kernel (statistics) - Wikipedia

@arclight the math is utterly beyond me, but I’m curious about how that report would have been typeset in 1988.
@cphansen That's a good question. The DOE and NRC reports from that era all have a distinct style; the typography is more advanced than what you'd get from a typewriter but it's clearly not TeX or troff.