Hacker News: btrettel

New comment by btrettel in "U.S. Army Corps of Engineers Bay Model"

btrettel — Thu, 04 Jun 2026 13:34:16 +0000

Even if it wasn't a large size, it likely wouldn't be great. During my PhD on sprays, I did some (unpublished) experiments using isopropyl alcohol to reduce the surface tension. The nozzles I used were around 1 mm in diameter as I recall. I did not anticipate that the room would fill up with isopropyl alcohol vapor and (probably) tiny droplets. I wore a mask and maybe left the room while each trial was running. Breathing that likely wasn't great for my lungs.

New comment by btrettel in "Fluid Simulation for Dummies (2006)"

btrettel — Wed, 03 Jun 2026 23:14:20 +0000

Fluid dynamicist here. The word "compressible" has multiple meanings and this might be confusing you. You don't need compressible flows in the sense of high Mach numbers. There are other models where the flow is variable density, but thermodynamic and hydrodynamic pressure are decoupled to remove the pressure waves that make high Mach number flows hard. There's also the Boussinesq approximation for buoyancy when the density varies only a small amount. I'm not particularly familiar with atmospheric models, but I'm sure they don't use the high Mach number form. "Incompressible" methods are common for the second class of model I mentioned, though how to use them so might not be obvious.

New comment by btrettel in "Ask HN: Who wants to be hired? (June 2026)"

btrettel — Mon, 01 Jun 2026 17:24:01 +0000

Location: United States (Open to any US location)

Remote: Yes, open to remote, hybrid, or in office

Willing to relocate: Yes

Technologies: Fortran, Python (Matplotlib, Numpy, Pandas, Scipy), OpenMP, Git/GitHub, Linux, Bash, others...

Résumé/CV: Available on request

Email: cxrqnw5z@trettel.us

GitHub: https://github.com/btrettel

Personal website: http://trettel.us/

I'm Ben Trettel, an experienced mechanical engineer with a PhD, specializing in computational fluid dynamics, design optimization, and verification & validation of computer simulations.

I am particularly interested in opportunities to build cutting-edge physical products where computational simulation and design optimization are key.

New comment by btrettel in "The Religion of Speed"

btrettel — Fri, 29 May 2026 18:26:38 +0000

I think the type of speed that you're referring to is different from the type of speed the linked article is referring to. I'm not sure what the best way to distinguish the two is. With slow software, you're presumably getting a right answer, just slower. In my job, people who work quickly often produce a wrong answer.

New comment by btrettel in "C extensions, portability, and alternative compilers"

btrettel — Mon, 25 May 2026 17:03:06 +0000

One approach for testing with multiple compilers that I use on some Fortran projects (where testing against multiple compilers seems more common than in C) is to use a variable from the command line to specify the compiler, for example:

    make FC=ifx check

On my Fortran projects, that will run the tests with Intel's Fortran compiler. The Makefile has logic to automatically change compiler flags as appropriate. I default to the GNU Fortran compiler, so `FC` isn't required.

I have made a script to run through a series of compilers by alternating between `make check` and `make clean`.

I have separate Makefiles for GNU Make and NMAKE/jom. My Fortran code works fine on various Linux distributions and Windows, though I'll add that achieving that is probably easier with Fortran than C. I've also tried a BSD Make that worked (on Ubuntu at least). My Makefiles are pretty close to the intersection of POSIX and NMAKE, so the main differences between the different Make versions are the conditional statements needed to handle the different compiler flags and the include statements (as I put the compiler flags in separate files).

New comment by btrettel in "Time to talk about my writerdeck"

btrettel — Sat, 23 May 2026 21:01:31 +0000

I had a similar setup in 2023, but the computer was reformatted after I moved. I wrote a HN comment about the setup before: https://news.ycombinator.com/item?id=37792204

I liked it and intend to use a similar setup in the future. There were quite a few "rough edges", unfortunately. In retrospect, a tiling window manager would have been a better choice.

I found Midnight Command to be great for this, with its integrated file manager, file viewer (mcview), editor (mcedit), and diff (mcdiff).

I didn't realize how much I relied on a unified clipboard until I didn't have one any longer. mcedit's clipboard was a file (or one of them was?), so I had to adjust some workflows.

The biggest problem came from my need to view a lot of PDF files. I had a framebuffer PDF viewer that was pretty clunky. It did not work with tmux and PDF files could not be opened directly from Midnight Commander as I recall. This specifically is why I'm thinking about a tiling window manager as I won't have to pick a clunky PDF viewer and the remainder will just work.

New comment by btrettel in "Princeton mandates proctoring for in-person exams, upending 133 year precedent"

btrettel — Thu, 14 May 2026 22:08:27 +0000

My PhD was in mechanical engineering. I don't want to get more specific than that on the subject in case it identifies the lecturer. I guess I used the phrase "lecturer" to distinguish him from my PhD advisor.

New comment by btrettel in "Princeton mandates proctoring for in-person exams, upending 133 year precedent"

btrettel — Thu, 14 May 2026 01:16:10 +0000

I had a similar experience when I was a TA at UT Austin that I wrote about on HN years ago: https://news.ycombinator.com/item?id=23163472

New comment by btrettel in "The missing catalogue: why finding books in translation is still so hard"

btrettel — Sat, 18 Apr 2026 15:03:38 +0000

Thanks for the reply. You're right that the data for this is very fragmented. Victor was looking at Crossref metadata. I think he always had what he was doing on Codeberg, though I'm not sure. I was looking at arXiv and 1960s to 1980s printed translation indices listing translations on paper that are today in archives uncatalogued at the Library of Congress, British Library, and other libraries/archives. (The indices list which libraries have each translation and what it says is accurate for the Library of Congress in my experience.) OCR was not cooperating on turning my scans of the translation indices into something I could parse, despite the indices having a regular structure indicating that they were computer-generated. LLMs likely would help with that now, but all of this was pre-ChatGPT. My plan was to automatically convert the bibliographic data in the indices to DOIs, but as it turns out, a large fraction of the articles in the indices do not have DOIs. We ultimately did not consolidate these sources.

Anyhow, it's obviously a huge task and I don't expect you to build this. I was just curious if you had thought about it as you clearly have a lot of relevant infrastructure in place. If I ever get the time and interest to work on this again, I'll reach out to you.

New comment by btrettel in "The missing catalogue: why finding books in translation is still so hard"

btrettel — Fri, 17 Apr 2026 16:15:49 +0000

Have you all considered adding scientific articles to your bibliographic database? Finding existing translations of scientific articles can be a real pain. I know because I spent a lot of time doing that during my PhD [1].

For a while I was collaborating with Victor Venema in the volunteer organization Translate Science [2] to try to create a bibliographic database of scientific translations, but unfortunately Victor died, and I became too busy to continue.

[1] https://academia.stackexchange.com/a/93209/31143

[2] https://translate-science.codeberg.page/

New comment by btrettel in "The peril of laziness lost"

btrettel — Mon, 13 Apr 2026 00:49:05 +0000

I think so too. If unclear, I don't use LLMs for coding at the moment and was just commenting on what I've seen from others who do in computational fluid dynamics.

Edit: Let me add that while I think it would be easy to instruct a LLM to do what I'd like, LLMs don't do these things by default despite them being recognized as best practices, and I'm not confident in LLMs getting the data or references right for validation tests. My own experience is that LLMs are pretty bad when it comes to reproducing citations, and they tend to miss a lot of the literature.

New comment by btrettel in "The peril of laziness lost"

btrettel — Sun, 12 Apr 2026 22:55:03 +0000

What I've observed in computational fluid dynamics is that LLMs seem to grab common validation cases used often in the literature, regardless of the relevance to the problem at hand. "Lid-driven cavity" cases were used by the two vibe coded simulators I commented on at r/cfd, for instance. I never liked the lid-driven cavity problem because it rarely ever resembles an actual use case. A way better validation case would be an experiment on the same type of problem the user intends to solve. I think the lid-driven cavity problem is often picked in the literature because the geometry is easy to set up, not because it's relevant or particularly challenging. I don't know if this problem is due to vibe coders not actually having a particular use case in mind or LLMs overemphasizing what's common.

LLMs seem to also avoid checking the math of the simulator. In CFD, this is called verification. The comparisons are almost exclusively against experiments (validation), but it's possible for a model to be implemented incorrectly and for calibration of the model to hide that fact. It's common to check the order-of-accuracy of the numerical scheme to test whether it was implemented correctly, but I haven't seen any vibe coders do that. (LLMs definitely know about that procedure as I've asked multiple LLMs about it before. It's not an obscure procedure.)

New comment by btrettel in "The peril of laziness lost"

btrettel — Sun, 12 Apr 2026 21:19:38 +0000

Similar to bragging about LOC, I have noticed in my own field of computational fluid dynamics that some vibe coders brag about how large or rigorous their test suites are. The problem is that whenever I look more closely into the tests, the tests are not outstanding and less rigorous than my own manually created tests. There often are big gaps in vibe coded tests. I don't care if you have 1 million tests. 1 million easy tests or 1 million tests that don't cover the right parts of the code aren't worth much.

New comment by btrettel in "How Close Is Too Close? Applying Fluid Dynamics Research Methods to PC Cooling"

btrettel — Fri, 10 Apr 2026 13:35:53 +0000

I do CFD in my day job, though not for electronics cooling. I don't think this is as easy as you imagine. It's relatively easy to make pretty pictures, but just because the picture is pretty doesn't mean that it's physical accurate or mathematically correct. Lack of resolution could be an issue, but there are plenty of more subtle problems as well. Jet impingement is known to cause problems with turbulence models, though some models claim to solve the issue. Plus, turbulence modeling isn't always predictive, and might require a certain amount of calibration any time a model is used in a new scenario. Add on top of that the fact that the computational cost of these simulations often is extremely high, even with turbulence models. Maybe people building PCs have plenty of unused CPUs and GPUs, though.

Unfortunately, I don't think CFD and turbulence modeling are things that you can just start doing well without learning a lot before starting.

New comment by btrettel in "Ask HN: Who wants to be hired? (April 2026)"

btrettel — Wed, 01 Apr 2026 19:58:47 +0000

Location: United States (Open to any US location)

Remote: Yes, open to remote, hybrid, or in office

Willing to relocate: Yes

Technologies: Fortran, Python (Matplotlib, Numpy, Pandas, Scipy), OpenMP, Git/GitHub, Linux, Bash, others...

Résumé/CV: Available on request

Email: 7b8ci3kl@trettel.us

GitHub: https://github.com/btrettel

Personal website: http://trettel.us/

I'm Ben Trettel, an experienced mechanical engineer with a PhD, specializing in computational fluid dynamics, design optimization, and verification & validation of computer simulations.

I am particularly interested in opportunities to build cutting-edge physical products where computational simulation and design optimization are key.

New comment by btrettel in "An industrial piping contractor on Claude Code [video]"

btrettel — Sat, 21 Mar 2026 18:10:57 +0000

I agree, my immediate reaction was that mechanical engineer is not a trades worker.

I majored in mechanical engineering at college. We had a required programming class. A lot of people like myself already knew how to program before we took the class too. We also had a required electronics class. My experience is that most folks with CS degrees would be surprised by the breadth of what mechanical/aerospace/chemical/etc. engineers learn.

New comment by btrettel in "Ask HN: Who wants to be hired? (March 2026)"

btrettel — Mon, 02 Mar 2026 16:16:56 +0000

Location: United States (Open to any US location)

Remote: Yes, open to remote, hybrid, or in office

Willing to relocate: Yes

Technologies: Fortran, Python (Matplotlib, Numpy, Pandas, Scipy), OpenMP, Git/GitHub, Linux, Bash, others...

Résumé/CV: Available on request

Email: 7b8ci3kl@trettel.us

GitHub: https://github.com/btrettel

Personal website: http://trettel.us/

I'm Ben Trettel, an experienced mechanical engineer with a PhD, specializing in computational fluid dynamics, design optimization, and verification & validation of computer simulations. Also, I am knowledgeable about patent law from time spent at the USPTO as a patent examiner.

I am particularly interested in opportunities to build cutting-edge physical products where computational simulation and design optimization are key.

New comment by btrettel in "Shift from passive documentation to active enforcement"

btrettel — Sat, 28 Feb 2026 00:59:20 +0000

Nice work. I made a similar (but much less capable) Python script [1] for my own use before and I can say that a tool like this is useful to keep the docs in sync with the code.

My script only detects whether a checksum for a segment of code doesn't match, using directives placed in the code (not a separate file as you've done). For example:

    #tripwire$ begin 094359D3 Update docs section blah if necessary.
    [...]
    #tripwire$ end

Also, my script knows nothing about pull requests and is basically a linter. So it's definitely not as capable.

[1] https://github.com/btrettel/flt/blob/main/py/tripwire.py

***

Edit: I just checked my notes. I might have got the idea for my script from this earlier Hacker News comment: https://news.ycombinator.com/item?id=25423514

New comment by btrettel in "Morgan Stanley predicts AI won't let you retire early"

btrettel — Fri, 27 Feb 2026 03:24:10 +0000

Where's the report referred to here? I'm doing Google searches including `site:morganstanley.com` for a bunch of quotes in this article and I can't find any single report that contains all of what's mentioned. I couldn't find anything by browsing their website either. I'm wondering if a lot of this is AI hallucination.

New comment by btrettel in "Ask HN: Why doesn't HN have a rec algorithm?"

btrettel — Tue, 24 Feb 2026 04:16:53 +0000

It's mostly navigating the PDF directories or notes repository, full-text search of my notes, or (less frequently) searching Zotero for bibliographic data. I don't use tagging for this and I'll address full-text search of the documents in a bit. I can't say that either direct navigation or text search of the notes is dominant as I do a lot of both. Having multiple ways to find information is good for redundancy as if one way fails, you can try another. So I don't think the balanced approach I have will change in the future.

For navigating the directories, I have a Python script called cdref that will search the directory names, which has proved to be very useful. If there's one match, it'll go directly to that directory, and if there are multiple, a TUI will pop up and allow me to select the directory I want.

I haven't found full-text search of the documents themselves to be particularly useful because terminology varies, frequently what I'm looking for isn't in the text (could be a figure, for instance), and probably thousands of my documents haven't been OCRed. I think that relying too heavily on full-text search of the documents assumes that other people will organize information in a way useful to me, which isn't realistic [1]. Full-text search of the documents is a part of my system, still, but it's mostly used to find things to put in the directories or notes so that I can easily find the documents again without having to remember the right keywords. (Though I also often keep track of useful keywords.)

Often I won't remember where I keep some things or even if I have a directory or note on something at all. So I might accidentally create a redundant directory or note. But frequently I later realize that and use it as an opportunity to increase the connectivity of my directories and notes through symlinks. Then if I go to the "wrong" place, a symlink will send me where I should go. And if something pops into my head as related, I add a symlink or a note in the README file for a particular directory. (The README files in the directories are separate from the version controlled notes but will eventually merge, as I indicated.) Over the years, I've accumulated a lot of connections like this.

With all of this said, I think the important thing is to find a system that works for you that you can slowly scale over time. It doesn't need to look like my system. I've iteratively developed a system that works for me over 10+ years at this point. The scale is easy if you have a system you contribute a bit to on a regular basis over a long period of time.

[1] I've been also looking into having a large local bibliographic database to in part as an alternative to online scientific search engines like Google Scholar because I don't want to assume such services will always be available.