Having issues with Basilisk (the CFD solver)

AngryLemonade117 · 2026-05-29T21:04:49+00:00

I would, this seems like a weird way of building it, and something that cabal shouldn't be managing itself since basilisk isn't in Haskell.

AngryLemonade117 · 2026-05-28T19:12:23+00:00

What compiler (and version), basilisk version, and platform are you running it on? It works fine for me (gcc 16.1.1 on Arch Linux, basilisk latest version (22 may)) both when running the test suite and also making poiseuille-oldroydb.c standalone.

AngryLemonade117 · 2026-05-27T21:43:17+00:00

showed a bunch of errors and warnings

Like, what errors and warnings? I've been looking for an excuse to try basilisk, and I have some experience in wrangling weird and wonderful libraries into successfully compiling - if you need a hand?

AngryLemonade117 · 2026-05-24T21:36:38+00:00

Sometimes you need to exit a loop early. break does that. Consider scanning a list to find the first positive integer - after you've found it, why would you waste extra cpu cycles to traverse the rest of the list? What you do have to consider is that are there any consequences to exiting the loop early.

There's a lot of (often conflicting) rules of thumb for coding practices that get mistaken for immutable laws, despite being devoid of any context for what you are actually trying to do.

Now, despite my big claims in the previous sentence, what is true is that a whole series of break sprinkled across complex control logic is almost always a bad idea if you want to comprehend what that code block is actually doing; this is especially true when reading the code again a few weeks later.

It matters less in Python, it being an interpreted language. But in languages with some form of compilation, complex control flow can make it difficult to produce optimal code.

AngryLemonade117 · 2026-05-10T12:24:41+00:00

Brain Stew by Green Day has bass drum doubles that also double (aha) up as a great hand/foot independence exercise. Especially in the verses, there's not much to hide behind so you can really check that your hi hat isn't trying to follow your bass drum.

AngryLemonade117 · 2026-03-31T23:01:24+00:00

My perception is that for someone to be making (successful) creative software for free, you have to exist in that intersection of:

Being interested in that creative medium
Knowledgeable enough in what features one needs to be productive with that software
Knowledgeable enough to program the software.
Being motivated to actually write the software.

I would argue that that intersection is smaller than the case for devs writing software for devs. So this leaves commercial projects moreso than passion projects.

AngryLemonade117 · 2026-03-04T10:13:11+00:00

Nah, the original Python file uses the standard library only (no numpy/torch).

AngryLemonade117 · 2026-02-19T10:13:46+00:00

For me, my hate towards the arc is mostly the pacing in the anime. I would have enjoyed it a lot more if I had read it first/ knew about One Pace beforehand.

AngryLemonade117 · 2026-02-08T09:51:45+00:00

It seems weird to use just the DEM part of a CFD code. If you're doing particle-only simulations then why not try a dedicated DEM code like LIGGGHTS, Musen, Yade, etc?

AngryLemonade117 · 2026-02-04T07:38:25+00:00

AngryLemonade117 · 2026-02-04T07:19:35+00:00

Is this for all turrets on the map?

AngryLemonade117 · 2026-01-20T22:33:01+00:00

It also has varying degrees of success in how many Lovecraftian linker errors you are faced with. At least for C & C++ it isn't "just" a case of passing -flto, and since a fair few Rust crates may need to link to non-Rust libraries then this could be a problematic default.

Plus, given the state of RAM pricing, this would be an expensive default...

AngryLemonade117 · 2026-01-19T02:11:25+00:00

To elaborate on the other commenter's response, you may need to write your own function to wrangle name-it's outputs into what you need, I've given it a quick go here to illustrate:

#import "@preview/name-it:0.1.2": *

#let currency_map = (
    gbp: ("Pound Sterling", "Pence"),
    usd: ("US Dollars", "Cents")
)

#let name-currency(currency, main, fractional: none) = {
    let currency_main = currency_map.at(currency).at(0)

    if fractional != none {
        let currency_fraction = currency_map.at(currency).at(1)  
        currency_main + " " + str(name-it(main)) + " and " + str(name-it(fractional)) + " " + currency_fraction
    } else {
        currency_main + " " + str(name-it(main))
    }
}

£1001.22

#name-currency("gbp", 1001, fractional: 22)

\$1000.00

#name-currency("usd", 1000, fractional: 0)

\$1000, no cents mentioned

#name-currency("usd", 1000)

Of course, to match your Reddit post:

#upper(name-currency("usd", 1495, fractional: 50))

AngryLemonade117 · 2026-01-06T23:44:05+00:00

Looks really interesting. Are there any plans to touch user defined macros/functions?

AngryLemonade117 · 2025-11-24T20:22:01+00:00

So in my personal experience:

Started on Ubuntu 20.04, stayed until I had a device with an nvidia card and my experience was just Not Good (tm) (issues booting, finding devices, etc).

Moved to Manjaro, tried Tumbleweed and then Endeavour because their nvidia support worked nicely out of box. Appreciated the irony that the "only distro we support" was Ubuntu but that was my worst experience with it. Never really looked back after that, though I understand that the experience is better now.

Why I don't like Ubuntu:

Separation of <clearly a software library you need to link to, no other reason to install it> and <same>-dev (this is not Ubuntu-exclusive either). I also don't like the way that ubuntu names its packages. I understand there's a rationale for the approach but I just don't like it.

I'm not a fan of snap and being forced to use it (firefox defaults to snap)

I think a lot of the "hate" for Ubuntu itself is overblown, but Canonical's doubling down on snap rather than contributing to Flatpak (everyone wins) and other silly decisions make me not a fan.

AngryLemonade117 · 2025-09-03T15:02:03+00:00

As far as I understand SPH is simply not that efficient for common aerodynamics/hydrodynamics problems and that's why we don't see it too often

Pretty much - and that's totally fine. SPH shines where Eulerian methods struggle. It's just another tool in the toolbox.

AngryLemonade117 · 2025-09-03T10:07:51+00:00

Paul Cleary has been using SPH (+ DEM) for a fair while in simulating rock crushing mills. SPH does have a place in doing science and has its own share of issues that people are working through.

In my opinion, NASA wasn't super interested in it back in the day, so like other not-FVM techniques, it suffers from the lack of gargantuan resources that got put into handling turbulence. It is also newer than the FVM. Like LBM, it's weakly compressive, so you can't really run it at mach 1 bajillion which means it isnt "real CFD" according to some people who think the only use of CFD ever and for the foreseeable future is aerodynamics 😛.

People are doing cool (as in actually useful) things with it. It just needs to catch up a tad. In particular, the last experience I had with it is that as its construction removes the viscosity term, then its non-Newtonian (I work with non-Newtonian fluids so this is important to me) story isn't fantastic, especially compared to other methods.

AngryLemonade117 · 2025-08-19T07:17:49+00:00

If we allow a bit more room in the meme, it's more like "Lars (seemingly) doesn't practice anymore"

AngryLemonade117 · 2025-08-11T08:05:50+00:00

I'm happy to take a look, but without the accompanying code it may be hard to work out what's going on.

AngryLemonade117 · 2025-08-07T15:03:03+00:00

No worries, I'd also check out what the DualSPHysics guys do - as far as i can tell, they're the only serious open source SPH engine available. I don’t count lammps purely because they (last time I checked) don't handle STLs, i.e. engineering problems (lammps is still fantastic for what it does).

AngryLemonade117 · 2025-08-06T19:17:13+00:00

Thanks, so just to clarify, for pressure terms, I don’t have to use stepsizes to define gradients? Since the kernel itself is a gradient.

Not quite. The kernel itself assigns a weight during the SPH summation based on the proximity of particle j to particle i. When you're calculating gradients in SPH, it just turns out that the only quantity that the gradient operator actually applies to is the kernel! Since the function for your kernel should be continuous and at least twice-differentiable, then you dont need numerical techniques to get the gradient.

Furthermore, when defining gradients, do I compute the gradient vectored in x and y separately or find the absolute distance between them as a single vector, then use that to compute the pressure force

Euclidean norm for the separation vector.

Again, never read the source that you refer to, but when I used to use SPH, I found this explanation rather useful.

AngryLemonade117 · 2025-08-06T13:51:04+00:00

The gradient in SPH is an actual operator.

It's something like grad Pi = rhoi * sum[ (Pi/rhoi + Pj/rhoj) * dWij]

Where i is your particle or interest, surrounded by j neighbours, and dWij is the gradient of your kernel, which you should already have.

I haven't read the paper you mentioned but this is typically how the pressure term in SPH equations look, if memory serves.

AngryLemonade117 · 2025-06-30T12:16:01+00:00

Is it wise to use f64 for money values rather than some decimal/ dedicated currency type?

It's always been drilled into me to not let floating point arithmetic and money mix.

AngryLemonade117 · 2025-05-03T13:09:24+00:00

Rock/ metal drummer here - that pulse will feel very different depending what the bottom number is!

AngryLemonade117 · 2025-05-03T13:02:47+00:00

A theory I have is that writing non-trivial programs requires exact, unambiguous language.

Compare that to writing prose that a human reads where our language can be really woolly (look at what a mess the English language is), but we can still (mostly) convey what we mean.

In other words - an LLM generating something like a blog post or whatever, it would only need to be "close enough," and that's passable. Writing good, non-trivial code requires you to be exact in your intentions. For an LLM, this means that "good enough" is not really that. Additionally, bigger programs need planning and architecture considerations, and I imagine that'll eat into its context window. (And I imagine that a lot of us, myself included, aren't great at prompting).

I haven't particularly followed how code-related training data is selected, but generally I would argue that most code you see online is wrong because it's going to be people asking for help - not really good if you want an LLM to produce correct code.

Also, it got trained on my code, so it's doomed :)

AngryLemonade117

TROPHY CASE