at least with extend I do not need to scared of any new release requiring me a potential complete rewrite of my custom code

Don't think so. It referred to the poor last release if I remember correctly and oh god it was bad last one 🤣. It feels that Extend is outside of this battle (and I say it in the good way)

Well with esi neither. It is super rare to break retrocompatibility. But I must admit also that org for me for example it has some great things that otherwise one need to jungle to implement it on esi (imagine more or less same for extend).

this was actually mostly an argument against foundation, for own development I would either esi or extend

Yes, 100% with you, I meant that in fondation I found several things that in at least esi I would need to implement myself.

Where in fondation was already there

Hi everyone, this is my first time asking a question here. Does anyone know why the non orthogonal corrector term is evaluated explicitly, an not just implicitly, in discretization of diffusion terms? I found one source on the internet -- [this one](https://www.cfd-online.com/Forums/main/244898-why-does-non-orthogonal-term-fvm-need-evaluated-explicitly.html) -- which explains that the implementation gets more efficient with less memory usage and cache misses. However, the explanation is very brief and is not apparent how the code becomes more efficient.

This has some info: https://doc.cfd.direct/notes/cfd-general-principles/surface-normal-gradient

how is my hardware for CFD: is it sufficient? https://cdn.discordapp.com/attachments/397874745464586242/1393282428143140895/image.png?ex=68729ae0&is=68714960&hm=6d5eeac120bb5227501f5961f49ca888432cf60d5e9da5c7c268fb5650947c1a& https://cdn.discordapp.com/attachments/397874745464586242/1393282428411449474/image.png?ex=68729ae0&is=68714960&hm=4567043a59d437f89c400d4daf61355e7f207b0a080c5aa2fcd722f31c536b49& https://cdn.discordapp.com/attachments/397874745464586242/1393282428642000958/image.png?ex=68729ae0&is=68714960&hm=184b2664dc7e523832c99213983a99b8dd827471ccec2051eb0ab02e3725bfbf&

will only 24gb VRAM be a problem?

because i know that simulations are very intensive, and i get the feeling this is a bit more heavy than just a FLIP fluid solver that i've used in the past

generally OpenFOAM does not run on a GPU, exceptions SPUMA, neon, etc. So I think it should be fine

ah cool, well then is my cpu and ram sufficient?

damn, a 4090

anyways that looks great, I'm sure you'll be able to handle big simulations just fine

Yippee

I mean, the next thing that's better is a server. You've basically got the maximum desktop already

well, that or a threadripper, but those are hella expensive

Well, need 5090 And 196gb RAM And CPU with 4 channel memory controller so that the ram actually runs at DDR5 speeds

I mean yeah, you can push it further

but a few years ago this would've been top of the line

2

Years ago

I'll be happy to trade in my rog strix 4090 white OC if anyone wants to give me a 5090 astral white

Thanks for sharing the link. Maybe I'm missing something, but this section of the book didn't explain why the non-orthogonal corrector is discretized explicitly.

Howdy folks, when I mesh a case with snappy in Parallel, I reconstruct the mesh and then decompose it again just to make sure the cells are divided evenly. I'm not sure, though, is there actually a benefit to doing that? Or am I just wasting time? Making things worse, even?

It shows within decomposePar the processor load. It would depend how you decompose the mesh (scotch, etc.)

Maybe check there? As that may be more indicative of what you're looking for?

It's fine, there is little chance of issues with reconstruction-decomposition. I typically do this because I run Snappy in parallel with <20 cores (50.

After re-reading the book, I noticed that for the non-orthogonal term they interpolate the gradient itself from cells on both sides of the face. Now this means we cannot write this in terms of the main variable of the PDE, and hence it can't be discretized implicitly. Now, my question is why it is done in that way? why wouldn't we alternatively use the values at surrounding cells (just like the orthogonal term) to calculate the gradient?