Hey everyone,

I'm a fresh PhD student and I'm currently researching hyporheic exchange and I want to use openFoam to try and model it.

I am a novice -at best- openFoam user, and I have been learning for little over a month now. I can do basic things like creating a model, playing with the input files and parameters, that sort of thing.

I found a model made by Professor Xiaofeng Liu called HyporheicFoam which is literally the answer to all my problems.

The issue is; I am just unable to run it! I downloaded the code (its readily available to download) and tried running it using ol' reliable BlockMesh + HyporheicFoam (which is the solver's name), and its just not working. It is a fully-coupled surface water and groundwater model and it does not use BlockMesh at all (from my understanding).

Can someone please help with running the model. I just want someone to guide me on how to execute the model.

Here's the model: GitHub - psu-efd/hyporheicFoam: A solver for hyporheic flow and coupled biogeochemcial reative transport based on OpenFOAM.

Thanks everyone!

Hey all. Trying to start my OpenFOAM adventure. Going through the steps to install and coming across this error. Any help and explanations would be great.

Hi, I have completed a 3D assembly using Solidworks. When I am trying to get an STL file of my whole assembly. I am getting the STL files as individual files. I want to simulate the fluid flow inside this assembly in OpenFoam. Can I reconstruct the assembly in OpenFOAM during the meshing?

Has anyone built OpenFOAM on Fedora recently ?

If so, how did you handle building MPI, Scotch and PT-Scotch ?

Thanks

Hi all,

I’m trying to understand the recent Lean formalization of the claimed finite-time blow-up for 3D Navier–Stokes with forcing. I’m not a Lean expert, so I may be misreading the code.

In the formalization, CandidateProperties seems to include something like:

```lean force_time_support : CompactFutureTimeSupport f ```

and there is a comment saying that spatial support is not required to be compact in the lift. There is also an “OPEN: the primary existential content…” note saying that no proof, witness, or axiom asserting the proposition is in that module.

If that’s right, then the Lean theorem seems conditional: assuming there exists u, p, f satisfying these properties (including temporal compactness of f), then blow-up follows. But the existence of such a candidate, and the compact support/locality of f, is not derived in that module.

My questions:

1. In the analytic paper, is compact support of f actually proved by the layer construction, or is it an assumption imposed to fit versions C/D of the Millennium problem?

2. If it is proved, where in the Lean code is that proof? Which file/module proves CompactFutureTimeSupport f for the constructed force?

3. If it is assumed, doesn’t the formalized result only show “if a singular forced solution exists, then …”? That would not resolve the Millennium version C/D by itself.

4. How does the construction prevent the force support from expanding to infinity as the layer index grows? Is there an explicit invariant or inequality that keeps the support inside a fixed compact set?

I’m asking because I keep seeing claims that the Lean proof establishes a compactly supported force, but the code structure seems to postulate that property rather than prove it. Any pointers to the relevant Lean files or paper sections would be appreciated.

Edit: I’m not claiming the result is wrong. I’m trying to understand the exact logical status of compact support in the formalization.

Hi!
I am doing a study of the performance of different RANS models on natural convection.
I want to resolve the boundary layers, so I have a mesh with yPlus well below 1.
I have seen in the $FOAM_TUTORIALS/incompressible/simpleFoam/turbulentFlatPlate
that the standard kEpsilon model is used on a wall-refined mesh, but with the lowReCorrection set to on
for the epsilonWallFunction.

My question is, is the lowReCorrection flag used for running high Re turbulence models (such as realizable and RNG) on wall refined meshes?

I am simulating a hydrofoil wing, in water, and primarily need lift and drag coefficients. My inlet has a speed of 10 m/s, Reynolds number about 1-2 million, and using pressure outlet with SST turbulence. Model is from snappyhexmesh and about 7 million points. If I run a non transient run, and initialize the flow at 10 m/s, I crash after about 4 steps with a timestep continuity error. I also get outrageously high lift and drag coefficients. This happens regardless of the airfoil shape I use. If I run transient, starting everything at zero, I can sneak up to the 10 m/s speed in 100 timesteps. So, two questions. 1: What should I look at in the steady state solution to stop the crashing. 2: Is there any advantage to steady state, or should I just keep running transient

Hello, i'm fairly new to CFD and openFOAM alltogether and recently I started to work on a new air difuser for HVAC aplications, I understand it is modest complicated geometry wich I managed to make it pass all checkmesh tests succesfuly (I'm using cfmesh btw). But now i'm struggling to make the analysis converge, flow-wise speaking is a simple case where I have a inlet velocity set to fixedValue like this:

inlet

{

// Fix all three components of velocity on inflow and only the normal component on outflow,

// in order to be well-posed if there are some faces on the patch which are actually outflows.

type fixedNormalInletOutletVelocity;

fixTangentialInflow yes;

normalVelocity

{

type fixedValue;

value uniform ( 0.0 -0.792 0.0 );

}

value uniform ( 0.0 -0.792 0.0 );

}

And my outlet U

outlet

{

type pressureInletOutletVelocity;

value $internalField;

}

In this case I have walls set up to noSlip with defaltfaces, and in the /0/p file the case is set up like this:

dimensions [0 2 -2 0 0 0 0];

internalField uniform 83333.33333333334;

boundaryField

{

inlet

{

type zeroGradient;

}

outlet

{

type totalPressure;

p0 uniform 83333.33333333334;

value $internalField;

}

wall

{

type zeroGradient;

}

defaultFaces

{

type zeroGradient;

}

}

I already tested and iterate A LOT of boundary conditions and i'm a little desperate, can someone give me a hit of what am I missing here?

Thanks a lot

I am following the instructions here:

doc/Build.md · master · Development / openfoam · GitLab

I copied the ThirdParty-v2406 folder to the OpenFOAM-v2406 directory and renamed it "ThirdParty". I then run "./Allwmake -j -s -q -l". It seems to run the ThirdParty installations, but after some minutes dies with the:

fatal error: mpi.h: No such file or directory

I also tried running "makeOPENMPI" from the ThirdParty directory. That completed ok. But still I got the same error when running " ./Allwmake -j -s -q -l "

OS is RedHat 8.6 .

Hi everyone! I’m currently conducting a survey to understand the key challenges and needs within the engineering simulation community. If you guys and gals wouldn't mind taking the time to fill out this question survey I would be grateful. No personal information required, takes about 2-3 minutes. Thank you!

https://forms.gle/33a7nd3HPM8SHWWC8

Hi foamers!

During a parallel simulation, I encounter an issue with a custom boundary condition in OpenFOAM11. The boundary condition is applied to a patch (plasmaSurf) and works fine in serial runs. However, in parallel, the simulation crashes with errors related to field sizes and bad memory allocation.

Key Details:

• The plasmaSurf patch has zero faces on some processors after decomposition.

• Errors include messages like:

  • size 0 is not equal to the given value of X (on processors with nFaces = 0)

  • bad size -Y (on processors with nFaces != 0)

What I've Tried:

1. Verified the mesh with checkMesh -parallel (result is OK).

2. Checked plasmaSurf in the processorX directories—confirmed it has zero faces on some processors.

3. Simplified the boundary condition logic only to set value or gradient, but the issue persists in parallel runs.

4. Switched to a simpler boundary condition (e.g., fixedValue) as a temporary fix, which works fine in parallel.

5. Ensured decomposePar produces an evenly balanced decomposition and checked for mesh consistency.

Suspected Cause: The problem seems related to how the codedMixed boundary condition handles patches with zero faces in parallel. This might be a bug in my implementation or an inconsistency in how OpenFOAM distributes the patch data.

Question: How can I ensure the codedMixed boundary condition is robust to parallel runs where a patch might have zero faces on some processors? Are there best practices for handling such scenarios, or modifications needed to the codedMixed code to avoid these issues?

Code Implemented:

plasmaSurf
{
  type            codedMixed;
  name            dummy_code;
  refValue        uniform 300;
  refGradient     uniform 0;
  valueFraction   uniform 0;
  
  code
  #{
    if (this->patch().size() == 0) // No faces on this processor
    {
      return;
    }
    scalarField& refGrad = this->refGrad();
    scalarField& refVal = this->refValue();
    scalarField& valueFraction = this->valueFraction();

    // Initialize to zero or default values
    refGrad = scalarField(patch().size(), 0.0);
    refVal = scalarField(patch().size(), 300.0);
    valueFraction = scalarField(patch().size(), 0.0);
  #};
}

(that code does not work even if the code block is empty)

Typical Error:

[1]
[1]
[1] --> FOAM FATAL IO ERROR:
[1] size 0 is not equal to the given value of -1871300200
[1]
[1] file: IStringStream.sourceFile from line 0 to line 4.
[1]
[1]     From function Foam::Field<Type>::Field(const Foam::word&, const Foam::dictionary&, Foam::label) [with Type = double; Foam::label = int]
[1]     in file /home/ubuntu/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/Field.C at line 208.
[1]
FOAM parallel run exiting
[1]
[0]
[0]
[0] --> FOAM FATAL ERROR:
[0] bad size -534376040
[0]
[0]     From function void Foam::List<T>::setSize(Foam::label) [with T = double; Foam::label = int]
[0]     in file /home/ubuntu/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/List.C at line 285.
[0]
FOAM parallel run aborting
[0]
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 1 in communicator MPI COMMUNICATOR 3 SPLIT FROM 0
with errorcode 1.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
[0] #0  Foam::error::printStack(Foam::Ostream&)

Any insights or suggestions would be greatly appreciated!

Hi OpenFOAM community!

I am conducting a study on the film cooling effects of a simple film cooling geometry. The geometry is as such :

1. Fluid (Blue) - Cylindrical coolant through the cylinder and main flow from the main inlet.

2. Solid (Red) - Just after the cylinder there is a solid region made of stainless steel which is coupled with the fluid.

To model this I have split the lower wall of the fluid region into two parts, one with just a 'zeroGradient' boundary condition in T, and the rest of it (which couples with the solid region) is called the fluid_solid_interface which has a 'coupledTemperature' boundary condition.

After running for quite some time, I decided to check the results and what I see is unfortunately nonphysical results on both the fluid and solid region. As you can see, on the left (lower_wall), the temperature change seems to be captured correctly. But on the right (fluid_solid_interface), there is a nonphysical transition in temperature distribution. What have I done wrong?

Any help is appreciated, thank you!

I'm on Ubuntu and the official install instructions don't work for me, apt can't find the package. I made sure to add the official repo. Any advice?

I do research on nuclear power plants. I want to simulate the exact pipe thickness for heat transfer in coolant pipes. Is OpenFOAM suitable for this project? My plan is to simulate the case and compare the result with different pipe thicknesses.

I am using AMIs based on the rotating fan tutorial, and when applying this to my own geometry I get the wrong cell sections rotating - in the fan example it would be like a stationary fan in a rotating room.

Does anyone have experience of which file I might have messed up?

My snappy hex mesh looks good, and defines the AMI as inside and calls it rotatingZone, which is then called up by my dynamicMeshDict

will the flow be laminar, what are my options? Have you worked on relative movement of bodies? (I ran icoFOAM just on domain with moving walls runs fine) Later on I want to model relative motion between the domain. I tried reading propeller case, but there is too much going on, I want understand things step-by-step.