Will the foundation folks stab themselves in the back with this? I understand the urge to refactor everything but just changing everything and telling no one about what you've done?

Well to be honest, the rearrangement of libraries is quite neat and logical in more places than one.

There's just a learning curve now... Like the way it used to be in the early days of Foam. What's painful is just so much modularity without documentation. Nobody seems to be willing to go through the pain - and even the best most logical solution needs people to pick it up and use it.

Just chuck the relevant parts through gpt and have it spit out docs. We have llms for this now

I would do this if I had any idea at all how the source code worked

Those who really need or want it will go through the pain. The refactoring has allowed really amazing things to be added to especially the multiphaseEuler module. And there's new things coming up all the time! I'm so happy this is available. Even without docs.

What is the secret of getting rid of negative Temperature error? 😭 I've cycled through BCs and it inevitably creeps up.

limitTemperature fvOptions is worth trying if you did not already. Does not always work though.

Is there no clean sensible way to do things

Like which is actually physics wise sensible?

Anyway you're right I should try that. I alrady have a lot of assumptions here so I shouldnt be crying for physical accuracy

I only want an isothermal but compressible sim to run but the temperature just goes negative

It is not necessarily dirty if it only kicks in at startup. Proper use in my opinion is having limited temperature on the first iterations to avoid the solver crashing, and once the temperature is back into your bounds it won't limit anything and you'll have the proper physics

Sometimes it's just what it needs to keep the run alive with a rough initialization and everything gets back to normal within a few iterations. (sometimes...)

Apparently limit temperature cannot work with compressibleInterFoam because it is an enthalpy based solver.

Shouldn't be the problem, I use it with buoyantSimple and that solves an enthalpy equation?

Well, it threw an error something along lines of no valid function. And there is some discussion about this on the forum as well that this is not implemented for some cases. But since you mention this, I'll try adding this fvOptions to some tuts in the two solvers just to see what comes up.

Yeah not implemented wouldn't surprise me

You could replicate it with a coded constraint

For now I managed to get past the poor initialisation issue by setting awful small initial deltaT and let the solver gradually increase it as per its own convenience. But I'll keep this idea of coded constraint in mind in case this pops up again.

Hello everyone, i am having a student who is simulating the flow through a propeller in a large enviroment. He uses rhoSimpleFan and a fan boundary condition to do a simulation with the actuator disk approach. The student wants to simulate different freestream velocities and the solution looks comparable to the froude theorem, which is good so far. However, when he increases the freestream velocity, the solution directly at the cyclic boundary conditions looks weird. For very low freestream velocities (1 m/s) the solution looks quite good, but with an increase in outer velocity (40 m/s and 200 m/s), the local velocity dircetly in front and after the cyclic drops very. And this drop becomes more drastic with a larger outer velocity (e.g. 200 m/s). I will attach three figures to clearify this and also the solution for the pressure directly at the cyclic condition. Has anyone ever observed such a trend and might have a reason and solution? Or is their a problem with the fan boundary condition? https://cdn.discordapp.com/attachments/726377692626157579/1374731620145430632/U200.png?ex=682f1e17&is=682dcc97&hm=7883a7881c0cf3b8a48c2ecf962044c49c3ca1b02b5705d326a5a88ba4f99d1d& https://cdn.discordapp.com/attachments/726377692626157579/1374731620493430805/U40.png?ex=682f1e17&is=682dcc97&hm=3db9116bb4d2b096e102cdc5fdaf2022cd5020c9756fcea269c12353777d7341& https://cdn.discordapp.com/attachments/726377692626157579/1374731620980097164/U1.png?ex=682f1e17&is=682dcc97&hm=ea74cda8739b3b4530d02d81479c842cf9ffc7b6aec8098cce3f5cdfd1c9f422& https://cdn.discordapp.com/attachments/726377692626157579/1374731621508583424/pressureDetail.jpeg?ex=682f1e17&is=682dcc97&hm=6303a7cd3b2f59681b455b3ec0c43c53a06e9038ff086e5902e6944eeab79fd4&

Are you still getting negative temps? I’m running into same issue and I’m seeing a suggestion to use compressibleInterIsoFoam because the artificial interface compression term in interFoam is what causes the negative temps. I haven’t tried it yet though

@User For my case, I was able to resolve it with better BCs at the outlet where reversal occurred. I do use geometric VOF in this case, yes.

Can anyone get access to this research article? https://pubs.aip.org/aip/acp/article-abstract/2134/1/040007/606908/Study-of-flow-characteristics-of-supersonic-flow?redirectedFrom=fulltext

Hi, wanna ask whether the unshowed plotting for nan values considered as not converging? in this case, shouldn't the case paused with error? https://cdn.discordapp.com/attachments/726377692626157579/1382226686245998612/image.png?ex=684a626a&is=684910ea&hm=d191ed84faaa89b846cde7515e35261551559067b408c102f1b014732052f86d&

Is anyone here familiar with the front facing step aka the mach 3 windtunnel benchmark problem for the 2D euler equations? Im having some issues id like to discuss

Specifically the issue of the singularity at the step corner

@User scam, here and in #727096272346939472

Thanks, banned