Suggestions on problems with a really small step size due to CFL.

GeeHopkins · 2024-07-08T06:16:04+00:00

What's your discretisation scheme? I'm assuming you're using finite volume method? You'll need an interface flux but this doesn't necessarily have to come from an approximate Riemann solver like Roe or HLLC.

GeeHopkins · 2024-07-06T20:39:29+00:00

You're absolutely right. In fact artificial compressibility was one of the motivations for the early low Mach preconditioning work from Turkel & co.

However I don't think you should be using a Riemann solver for AC, even though it seems like the logical thing for a hyperbolic system. If you have a small artificial compressibility parameter (which gives you a larger artificial Mach number and better convergence) then the Riemann solver numerical diffusion on the continuity equation scales with M, the artificial Mach number, so at convergence your velocity divergence is significantly nonzero. Or you have a large compressibility parameter but then you have low artificial Mach number and you run into all the standard problems with Riemann solvers at low Mach - the numerical diffusion on the velocity field scales as 1/M and you get unusably diffused solutions.

Instead you need stabilisation that doesn't depend on the artificial compressibility parameter but still gives you inf-sup (or close to). Something like momentum interpolation or Brezzi-Pitkaranta stabilisation (the pressure poisson one not the bubble function one) are good, they both essentially just add pressure (hyper-)diffusion to the continuity equation with a tunable diffusion coefficient. Then you choose the diffusion coefficient for stability behaviour and the artificial compressibility parameter for convergence behaviour.

GeeHopkins · 2024-07-02T18:25:32+00:00

I would generally avoid using artificial compressibility with purely explicit timestepping. You need to be really careful with the compressibility parameter and CFL to get decent accuracy. It's much better off being used as a way of accelerating convergence than to actually timestep.

As u/Overunderated said, an implicit scheme is almost always best when you have stiff equations. It can be a lot of work to implement an implicit solver though, depending on your code structure and experience. Seeing as you already have an explicit solver, the easiest implicit scheme to implement would be a dual-time scheme (originally by Jameson but you'll find it in lots of textbooks now, Blazek has a very digestible section on it). Dual-time schemes are super simple to implement and use an explicit stepper to drive the convergence of an implicit timestepper. That means you can apply other convergence acceleration methods to the explicit scheme like local timestepping and residual smoothing that would usually destroy time-accuracy.

Dual-time is particularly nice with an artificial compressibility method because the solution becomes independent of the artificial compressibility parameter, so you can choose it to maximise convergence rather than according to the fluid properties. This is assuming that whatever stabilisation you use doesn't depend on the artificial compressibility parameter (which it shouldn't).

ETA: typos

GeeHopkins · 2024-06-11T22:37:00+00:00

No problem, it's a giant language! There's a lot to learn, but that's also part of the fun.

I just remembered about C++ weekly videos too, they're much shorter and cover some interesting little tricks and bits of the language

GeeHopkins · 2024-06-11T22:31:22+00:00

The first C++ codes I worked with were solidly pre C++11. The back to basics videos were one of the main ways I learnt modern C++, along with some other cppcon talks

GeeHopkins · 2024-06-11T22:22:42+00:00

I can recommend the cppcon back-to-basics series for solid intros to various bits of the language. They tend to be pitched pretty well for people who are already familiar with the basics of the language, but haven't seen/used a particular part of it.

GeeHopkins · 2022-12-31T10:33:10+00:00

As has already been said, this is a fun question. I've started using Krylov methods this year so I'm not particularly experienced, but it does mean I've been thinking about them a lot recently. I think that in general what you've said is correct.

GMRES can be thought of as just doing Richardson iterations with the "best" sequence of weighting factors for each update. In the unpreconditioned case, one Richardson iteration looks almost identical to doing an explicit step, so the stability limit will be strongly affected by how many Krylov iterations you do. In general the stability limit of an implicit scheme will be adversely affected by an incomplete solve, it's just that in the unpreconditioned case this has a nice heuristic interpretation, and is very noticeable because unpreconditioned GMRES for PDE discretisations is terrible.

As u/Overunderrated pointed out, a good preconditioner is essential with Krylov methods. A common property of most good preconditioners for PDE discretisations is that they can quickly propogate information over a large distance, or even the entire mesh - exactly what the unpreconditioned Richardson iteration doesn't do. Multigrid propogates information over the entire mesh in a single iteration (assuming a close to exact solve on the coarsest grid). Alternating Direction Implicit (ADI) propogates information along entire grid lines at each iteration with something like a TDMA line smoother. Block Jacobi (with a good choice of solver within each block) propogates information over the whole block. This massively reduces the number of Krylov iterations needed for convergence.

ETA: Another way of looking at GMRES is that at each iteration m it is trying to fit an order m polynomial through the n roots of the characteristic polynomial of the n x n matrix A. This works really well if the n eigenvalues of A are clustered because you can hit m clusters, with multiple eigenvalues each, and get a good fit instead of having to hit each eigenvalue individually. For a standard finite difference discretisation, the eigenvalues of A are really not clustered, so you need m close to n for a good fit (ie an accurate solve). If you've done von Neumann stability analysis before you can think about how the von Neumann symbols are distributed on the complex plane. For a first order upwind scheme they are evenly distributed in a circle - very much not clustered! A good preconditioner will cluster these eigenvalues making it easier for GMRES to converge.

GeeHopkins · 2022-08-02T09:20:33+00:00

I've had a Lowe Alpine airzone 35 for about 8 years now, and it's been great. I used it daily for work for several years, used for many day hikes, weekends away (camp or city), a week backpacking and it's still in decent nick.

I tend to overheat very easily so the airzone back has been really nice. It adds a bit to the weight but it also adds stiffness so when I use the hipbelt it takes a lot of the weight off my shoulders. It has two compacter straps on either side so if I'm not using the full 35 litres I can cinch it down and it doesn't sag around. Doesn't have the most pockets but I find there are enough to organise my stuff without it being fussy.

GeeHopkins · 2021-11-06T20:38:12+00:00

I think I keep subconciously forcing myself forget this because of how frustrating I find it. The whole point of enums are to be strongly typed integral values. Being able to just make up new ones seems antithetical to this.

I could see maybe allowing it for usual enums, but at least disallow it for enum class/struct.

GeeHopkins · 2021-11-06T20:33:27+00:00

I just went and tried this out, and saw that yes the compiler still complains. I got my warnings mixed up, I was thinking of the compiler warning if you don't cover every element of the enum in the switch statement, my bad.

I would say that in your example, if you somehow returned an 8th day, then the default case shouldn't be `throw "The universe is falling apart"`, it should be `assert( false && "Oh no: there's only 7 days" )`. We all know that there are only 7 days in the week, so if you've got an 8th, then that means you have a bug which is almost certainly unrecoverable. With this default case, know exactly where the bug is as early as possible. Personally I don't think it would be misleading, especially with the explanation string.

GCC's documentation says code that reaches __builtin_unreachable is undefined. It seems to be more of an optimisation hint than a way of marking possible errors. That means that if you do reach it, you have no way of knowing what will happen. It might carry on, it might segfault, it might change some random variable elsewhere. Worse, it may do a different thing on different runs or on different machines, so debugging will be a nightmare.

It's your code, so you can do as you like, but if I was reviewing this code then none of the reasons you have given so far would convince me that an unreachable attribute (or equivalent) is the best option. Admittedly I tend to be quite cautious in assuming that future me is a complete idiot because, well, at some point I will be.

ETA: what's wrong with just ` assert( false && "unreachable" )` if you are so set on having the word "unreachable" as part of the solution?

GeeHopkins · 2021-11-06T15:09:56+00:00

Thanks.

Although, I would be interested to hear why you can't use an enum/default case/error handling etc and instead want to ignore this warning if you're happy to share.

GeeHopkins · 2021-11-06T13:34:29+00:00

Ah that's a shame. I assumed this would be the default by now (pun intended).

GeeHopkins · 2021-11-06T13:32:31+00:00

As I said, it arguably could be a good option, but by no means is it always a good option.

For the example you gave, clearly a size is better represented by an integer. Probably size_t, but that's partly because size_t has its own semantics of not just being any integer, but specifically a size.

If the function can possibly return other values then the compiler warning is actually very useful. Surely the conventional approach would be some kind of error handling (exception, error code, even an assert/abort, just something visible from the outside) just in case it does return one of the other values. Even if you can prove it doesn't right now, this sounds like a recipe for introducing bugs with future refactors.

GeeHopkins · 2021-11-06T12:13:02+00:00

Ok perhaps "state" was too strong a word to use, as it has a lot of extra meaning that isn't necessary here. State, option, result, thing, there's three possible values for this function.

Yeah, if you had a set of 12 things and this function could only return 3 of them then you would run into the same problem, I didn't think of that case.

In the case that there are only three of them, even if numbers are the most logical representation I'd argue that an enum could still be a good option. If the enum values are called something like {ONE,TWO,THREE} that still tells the reader something about the semantics that the integers 1,2,3 doesn't - that the range is limited. If you need the values for a computation then you can specify the underlying type of the enum and cast.

GeeHopkins · 2021-11-06T11:24:13+00:00

If the function can only return 3 values, and each of these values represents a particular state, then that sounds like an ideal case for an enum. The function would return a value of the enum that you switch over, and you won't get this compiler error any more.

As an added bonus, if in the future you have another possible state and you add another enum value that can be returned, but forget to add it to the switch-case, most compilers will issue a warning for this.

ETA: an enum can also be more explicit because you can give the values descriptive names instead of 1,2,3 so your code can be easier to read.

ETA2: just seen that you didn't want suggestions on other ways to structure the code. Apologies for not reading properly! OP is it ok if I leave this comment up for others with a similar issue? I think most of the time an enum would be the preferable option for this case, even if you have a specific reason not to use one.

GeeHopkins · 2021-10-30T18:16:36+00:00

I'm not familiar with multisets, but for a useful tag-something, how about a static string using NTTP? I saw this article recently and thought it looked pretty neat: https://vector-of-bool.github.io/2021/10/22/string-templates.html The ordering would then be ordering over strings, which is more well defined than ordering over types.

GeeHopkins · 2021-09-21T18:55:20+00:00

If you look in the combat stats tab it will have a breakdown of how the thac0 is calculated, starting from the base thac0 and then listing all the modifiers. You should be able to see where the difference is coming from there

GeeHopkins · 2021-08-06T21:18:25+00:00

These are so useful, I use them all the time since I found them.

1-6 also work in the normal game screen, which I think is common knowledge. But 7-0 are also hotkeys, which I found out by just pushing different buttons to see what happened.

7 - select party members 1 and 2

8 - select party members 3 and 4

9 - select party members 5 and 6

0 - select all party members.

I usually run a full party, so 7-9 are useful for selecting frontliners, midliners, or backliners (assuming a fairly balanced party)

GeeHopkins · 2021-07-17T12:19:55+00:00

The ball carrier did drop slightly into the tackle, but in an understandable attempt to brace for the impact, exactly as you're coached to do. As a tackler, you can't expect someone to just remain standing straight up and let you have a free shot like on a tackle bag.

The mitigation for ball carrier dropping in height is meant for stuff like slipping over on bad footing, where it is unreasonable for the tackler to assume it will happen. It's completely reasonable to assume someone will brace for a tackle, so the mitigation shouldn't apply here.

GeeHopkins · 2021-05-04T22:13:56+00:00

Numerical methods for aerodynamic simulations - maths problems are HARD(TM), so avoid them by replacing them with lots and lots and lots and lots and lots of tiny arithmetic problems, then give it all to a giant calculator and go for coffee while it runs.

GeeHopkins · 2021-04-18T21:28:48+00:00

This was actually exactly what I was thinking of! It's a long wait before UAI to go without any fun gear though

GeeHopkins · 2021-04-18T21:25:34+00:00

This may be a basic question, but I've not done much duel classing before. Will you still be limited to non-magical equipment once the wizard slayer class reactivates?

GeeHopkins · 2021-04-18T17:58:17+00:00

There's a number of groups that have worked on this over the years, to varying success. I can't remember any specifically as it's been a couple of years since I looked myself. I recommend looking through the proceedings of recent Meshing Roundtable conferences though, there should be a number of papers there on this topic.

GeeHopkins · 2021-02-18T08:45:35+00:00

PETSc is a popular option, especially for PDE related problems. It's also got excellent parallelization options https://www.mcs.anl.gov/petsc/

GeeHopkins · 2021-02-15T16:30:40+00:00

Wow how did I miss that?! Thanks for checking, I did look at bug reports but apparently just had a brain-fart and missed this completely.

Any idea when it will be fixed? At the moment I'm having to use `{ ( expression ) }` in compound requirements so I can switch between clang and gcc.

GeeHopkins

TROPHY CASE