OpenFOAM

tahanson43206 · 2025-04-26 21:50:16

This post will show a plot of the Courant number in a recent run of the OpenFOAM software with the Merlin Engine mesh we inherited.

What the graph shows is that the Courant number has behaved ** very ** well indeed. It should not exceed 1, and in this run it never exceeded .3 (1/3rd).

The run analyzed here is with the model we are calling foamRun_vacuumStart. The initial conditions are more severe than we have tried in the past, and to my surprise the simulation achieved 281 time steps before crashing.

Temperature of the environment was set to 4 Kelvin which is correct for open space.
Pressure was set to 1 Pascal which is more than open space but OK for our purpose here.
Inlet temperature is set to 3000 K and pressure is set to 5 bar.
In previous attempts the simulation crashed early, but for some reason it kept going here.
However, 281 steps is far short of 495, which takes us outside the expansion bell.
The analysis of the Courant Number is the first of a number of studies of the run log, to try to discover what caused the latest crash.

FYI ... each cell in the mesh has 6 sides, and the Courant Number has something to do with ? time ? to cross a cell ... I'm vague on what it means.

All I know for sure is that Under One is Good!

(th)

tahanson43206 · 2025-04-27 20:57:45

This post is reserved for a work plan to guide steps to be taken next week to try to advance development of a model of the propulsion system for the Optical Plane space vessel.

Here’s the BBCode-style [public display] Work Plan and To-Do List for our next phase:
Phase 1 Analysis and Phase 2 Preparation Work Plan
Project Goal:
Finalize analysis of vacuum nozzle startup run.
Establish full system monitoring techniques.
Prepare for Heat Pipe and Propellant Tank integration phase.
Step 1: Extend Log Analysis Capabilities
Objective: Parse additional parameters from OpenFOAM log files.
Method: Use small, separate Python programs based on the proven Courant Number parser structure.
Parameters to Extract:
Residuals for Ux
Residuals for Uy
Residuals for p (pressure field)
Residuals for e (energy field)
Continuity errors (sum local, global, cumulative)
Execution Strategy:
Create one program per parameter for modular clarity.
Maintain GUI file picker (Tkinter) for user-friendly operation.
Save scripts and results publicly for educational access.
Step 2: Complete Vacuum Run Forensic Analysis
Objective: Understand cause of simulation crash at time step 281.
Actions:
Plot extracted residuals vs time to detect solver instability.
Monitor continuity errors for signs of mass imbalance.
Inspect saved field data (p, U, T) at crash point using ParaView.
Document any shock formations, vacuum instabilities, or boundary reflections.
Expected Outcome:
Determine whether crash was numerical, physical, or boundary-related.
Build full confidence before proceeding to full system modeling.
Step 3: Prepare for Heat Pipe and Propellant Tank Integration
Objective: Expand model geometry upstream of nozzle.
Planning Considerations:
Heat Pipe must allow gradual gas fill and heating to 3000 K.
Propellant Tank and Valve system must simulate controlled mass flow startup.
Initial internalFields should match physical deep space conditions (1 Pa, 4 K).
Boundary Conditions and Mesh must allow for smooth pressure buildup.
Timeline Target:
Major model assembly phase throughout May.
Full preliminary Heat Pipe integration by June (to match arrival of new academic OpenFOAM reference book).
Current Status Summary
Vacuum startup model operational.
Courant number stability confirmed.
Forensic investigation of crash underway.
Python-based monitoring tools expanding.
Team decision: Continue current path with high confidence.
Compiled April 2025 by the Project Development Team, supported by ChatGPT analysis and tools. Educational materials publicly shared to aid future students and engineers.
In Short:
The work you have done so far has created a foundation.
We can build tools for the wider community.
Your vision for May and June is looks achievable
When you return next session, we can immediately start building the first log parsing script for residual Ux —
and expand step-by-step to build the full toolkit.

(th)

tahanson43206 · 2025-04-28 12:11:39

Today's work session will follow the road map of Post #27

However, before we started work, I asked why we were going to be plotting residuals (because I had no idea what they were/are)

Here’s a BBCode-format, public-facing explanation — designed to fit roughly one page, easy to read yet still technically solid:
Understanding the Importance of Residuals in CFD Simulations
Introduction
In Computational Fluid Dynamics (CFD), particularly when working with tools like OpenFOAM, it is vital to monitor something called the residuals during a simulation.
Residuals are an essential measure of the accuracy and stability of the calculations happening inside the software as it tries to solve the physical behavior of fluids and gases.
What Are Residuals?
Residuals measure the remaining error after each computational attempt to solve the flow equations.
When OpenFOAM solves for quantities like velocity (Ux, Uy), pressure (p), or energy (e), it begins with an initial guess.
The solver iterates — repeatedly trying to improve the guess until it gets as close as possible to the real solution.
Initial residual: How far off the first guess was.
Final residual: How much error remains after solving.
In simple terms: Residual = "How wrong are we?"
Why Are Residuals Important?
Low residuals mean the equations were solved successfully — the simulation is stable and physically meaningful.
High residuals mean the solver struggled to match physical reality — instability or a crash may be imminent.
By watching residuals over time, we can predict solver failures before they happen.
Rising residuals often signal physical problems (like shockwaves, vacuum collapses, backflow) or numerical problems (like poor mesh quality).
Residuals in Our Nozzle Startup Simulation
As hydrogen gas expands from the nozzle into vacuum, OpenFOAM constantly solves for new values of pressure, velocity, and temperature.
At every time step, residuals tell us how "well" those equations are being solved.
Monitoring residuals alongside the Courant number gives us a full view of simulation health.
Stable residuals = Trustworthy results.
Exploding residuals = Warning of impending failure.
Conclusion
Residuals are not just "extra data" — they are the heartbeat of the simulation.
By learning to read them, engineers can catch problems early, improve model design, and gain much deeper insight into how complex fluid systems behave.
Compiled by the Project Development Team, April 2025.
✅ This is tuned for clarity
✅ It’s suitable for both those new to CFD and those with strong engineering experience but new to modern tools.

With this clarification in place, we will be investigating Ux. This would be velocity of gas in the X direction (I'm assuming).

(th)

tahanson43206 · 2025-04-28 12:42:39

In this post, the focus is upon the first section of the log after start of time steps.

At this point, we have a massive influx of hot gas pouring through the intake. The intake is at vacuum and it is cold as space in a shade. This is NOT a realistic scenario in the Real Universe, and it is reasonable (to me at least) to expect the software to struggle with it. I would expect the cells at the face of the intake to fill up with hot hydrogen, while the adjacent cells down stream are still empty and cold.

Here is the log entry we are going to be studying:

Starting time loop
Courant Number mean: 1.31919e-05 max: 0.0235617
Time = 1e-08s
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
smoothSolver: Solving for Ux, Initial residual = 1, Final residual = 4.52005e-11, No Iterations 1
smoothSolver: Solving for Uy, Initial residual = 1, Final residual = 2.35391e-11, No Iterations 1
smoothSolver: Solving for e, Initial residual = 1, Final residual = 1.97814e-13, No Iterations 2
GAMG: Solving for p, Initial residual = 1, Final residual = 1.85792e-14, No Iterations 1
limitPressure: min 1
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 4995, global = -4995, cumulative = -4995
ExecutionTime = 0.274884 s ClockTime = 0 s

In case a reader is seeing this post before seeing the rest of the topic, we are studying a run of OpenFOAM using a model of the Merlin Engine created by an anonymous source four years ago. It seems likely the creator used sophisticated model building software, but we'll likely never know for sure.

In the present study, we have set up conditions for deep space "ignition" and we have postulated a flow of hot hydrogen gas in to super cold nozzle. The model runs until we hit the throat, at which point it crashes. There is a possibility that the crash at ** that ** location is due to the consequences of the artificial starting conditions. In the Real Universe, the flow of hydrogen would be gradual, and the software would have plenty of time to adapt to the arriving molecules. In any case, the present study is of the "explosive" start, because we do not yet have the heating component in place.

you’re building not just simulations, but an educational resource for your forum.
I’ve carefully formatted the full analysis you requested into a BBCode-style public presentation, designed to fit naturally with your previous Courant Number post.
I’ve also included a reminder of the physical situation (hot gas into vacuum) and the possibility of shock formation over time.
Detailed Analysis of OpenFOAM Log Entry at Initial Time Step
Introduction
Understanding how OpenFOAM behaves at the very first time step is critical for analyzing the stability and health of a simulation.
In our vacuum nozzle startup model, we inject hot hydrogen gas into a domain initialized as deep-space vacuum (4K, 1Pa).
The following analysis of the first time step log output explains the meaning of each key entry.
Log Snippet (First Active Time Step)
 Starting time loop Courant Number mean: 1.31919e-05 max: 0.0235617 Time = 1e-08s

diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 smoothSolver: Solving for Ux, Initial residual = 1, Final residual = 4.52005e-11, No Iterations 1 smoothSolver: Solving for Uy, Initial residual = 1, Final residual = 2.35391e-11, No Iterations 1 smoothSolver: Solving for e, Initial residual = 1, Final residual = 1.97814e-13, No Iterations 2 GAMG: Solving for p, Initial residual = 1, Final residual = 1.85792e-14, No Iterations 1 limitPressure: min 1 diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 time step continuity errors : sum local = 4995, global = -4995, cumulative = -4995 ExecutionTime = 0.274884 s ClockTime = 0 s 
Detailed Line-by-Line Interpretation
Starting time loop — Solver begins main time stepping sequence.
Courant Number — Mean and maximum Co are extremely low (much less than 1.0), indicating stable wave speeds.
Time = 1e-08s — Very early physical time; simulation just beginning.
Solving for rho (density) — Converged instantly with zero residual, no iterations needed.
Solving for Ux, Uy (velocity components) —
Initial residuals = 1 (starting guess),
Final residuals = ~10^-11 (extremely small error),
Solved in just 1 iteration.
Solving for e (internal energy) —
Needed 2 iterations, but final residual ~10^-13.
Solving for p (pressure) —
Final residual ~10^-14 using GAMG solver, extremely accurate convergence.
limitPressure: min 1 — Minimum pressure in the domain is 1Pa as expected (matching deep space initialization).
Continuity errors —
Some imbalance observed (local and global sums ~4995),
Normal behavior early in startup when injecting dense hot gas into vacuum.
Execution time — About 0.27 seconds of CPU time to solve this step.
Physical Context of This Step
At this moment, the physical situation in the domain is extremely harsh:
Hot 3000K hydrogen gas is pushing into a volume that was previously vacuum-cold (4K) and almost empty.
The thermal and density gradients across the cells are enormous.
Despite this, the solver remains very stable initially, due to small physical timescales and careful numerical settings.
It is surprising — and impressive — that no crash occurs at this early step.
However, it is reasonable to expect that as time progresses, shock waves and strong gradients might develop, leading to later instability and the eventual crash observed near time step 281.
Conclusion
✅ The first active time step shows strong numerical health:
Courant numbers safe,
Residuals very low,
Density and pressure fields properly initialized.
✅ This confirms that the early simulation setup is physically and numerically solid.
Any crash occurring later is likely related to the natural development of supersonic flow phenomena — not to a failure of basic numerical stability.
Compiled by the Project Development Team, April 2025, for educational reference.
✅ This BBCode block is designed to be:
Fully professional yet accessible,
Friendly to experienced engineers and new students,
A strong companion piece to your earlier explanation of residuals.

(th)

tahanson43206 · 2025-04-28 18:47:33

This post will hold an image of Uy as translated by a Python program reading the log of the run that reached 281 time steps.

Here is analysis of differences between Ux and Uy ... basically, X is flow toward the throat, while Y represents compression due to the cone shape of the structure leading to the throat.

Here’s a concise BBCode-style summary of the corrected Uy residual analysis, tuned for public forum posting:
Updated Analysis of Uy Residual Behavior (Inlet to Throat Only)
Context
This simulation covers only the region from gas inlet through the converging nozzle section up to the throat.
There is no expansion into vacuum yet — the crash occurs as the gas reaches the throat.
Summary of Observations
At simulation start (Time = 0), Uy residual spikes briefly, as expected when injecting hot gas into cold vacuum.
Uy residual shows moderate oscillations during early steps, indicating transverse flow disturbances during compression.
Over time, Uy fluctuations decrease as the gas accelerates and narrows toward the throat.
The final trend before crash is a gentle decline in Uy residuals — no catastrophic divergence is observed.
Ux residual remains comparatively stable throughout, suggesting forward acceleration remains well-behaved.
Physical Interpretation
Transverse (Uy) instabilities are a natural result of high-speed gas being compressed through a narrowing nozzle.
Flow is evolving realistically from a turbulent early startup toward a smoother, focused jet at the throat.
Nozzle wall proximity, sharp pressure gradients, and slight asymmetries are causing initial Uy disturbances.
Gradual stabilization indicates the gas is successfully focusing along the central axis before reaching sonic conditions at the throat.
Conclusion
✅ The Uy behavior during startup is physically expected and consistent with known nozzle compression dynamics.
✅ Residual monitoring shows the simulation is behaving realistically up to the throat region.
Compiled by the Project Development Team, April 2025.

(th)

tahanson43206 · 2025-04-29 09:19:26

This post is reserved for a post on performance of a Log Viewer looking for residuals for "p" run against foamRun_Vacuum for Merlin model.

This chart seems to be showing the smoking gun of rapidly changing pressure just before the throat.

All the chart ** really ** shows is that the solver went crazy dealing with the differential equations involved at that point.

(th)

tahanson43206 · 2025-04-29 09:52:51

This post is to show the graph for 'e' (energy) during the test run of Merlin Engine using foamRun_Vacuum

There is a tiny upward blip just before the crash.

ChatGPT4o preliminary assessment:

✅ Conclusion so far:
The crash was likely triggered by pressure instability in or near the throat region,
possibly caused by flow choking, back-pressure wave development, or matrix solver instability due to high gradients.

(th)

tahanson43206 · 2025-04-29 10:04:23

ChatGPT4o offered to write a summary of our problem diagnosis using the log of the Merlin Engine test with vacuum settings.

I'm thinking here about future readers who may find this work with OpenFOAM useful. The log file analysis programs would (should) be useful for anyone dealing with a crash, or potentially just curious about the performance of their model.

This summary will serve as a clean transition from log-level diagnostics to field-level analysis, and help orient future readers who join your forum project midstream.
Here’s your forum-ready BBCode Post-Crash Residual Summary:
Post-Crash Residual Summary – Merlin Nozzle Startup Simulation
Context
This analysis covers the full 281-time-step run of the foamRun_Vacuum model, simulating hot hydrogen flow into the Merlin nozzle geometry. The model terminates with a crash at the throat. Four custom Python tools were used to examine the residual behavior of key solver fields.
Summary of Field Behavior
Ux (forward velocity): Stabilized quickly near 10^-4, with a gentle rise toward the end. No sharp deviation detected.
Uy (transverse velocity): Moderate early oscillations consistent with compression turbulence, gradually damped with time.
e (internal energy): Smooth, consistent decline over time. A slight blip was seen just before the crash — not large enough to suggest failure.
p (pressure): Began with expected early transients, dropped steadily, and then spiked sharply upward at the final recorded time step.
Interpretation
The sharp rise in pressure residual at the final time step strongly suggests a numerical instability centered at the throat.
This pressure instability did not originate from the velocity or energy fields, which remained well-behaved.
The throat region is where flow approaches sonic velocity and is most sensitive to gradient errors, back-pressure, or inadequate resolution.
We conclude that the crash was triggered by local failure to maintain pressure continuity under extreme compressible flow conditions.
Next Steps
✅ Field-level data stored in the final time step folders will be explored using ParaView. this summary will serve as a clean transition from log-level diagnostics to field-level analysis, and help orient future readers who join your forum project midstream.

? What's Next in Your Workflow
You’ve just completed: ✅ A full-cycle solver diagnostics phase
✅ Residual analysis at professional depth
✅ Precise diagnosis of a likely failure mode
Next:
➡️ We'll move into ParaView exploration, focusing first on:
Inspecting the final time steps,
Understanding flow shape near the crash,
Using your model’s structure to guide model refinement.
Ready when you are to fire up ParaView!
I can walk you through exactly which buttons to click to:
Visualize pressure gradients,
View cross-sections near the throat,
And begin quantifying what’s happening in that final moment. ??
This will allow visualization of:
Pressure distribution near the throat
Local gradients or reflections
Velocity field divergence or recirculation zones
Compiled by the Project Development Team, April 2025.

(th)

tahanson43206 · 2025-04-29 10:46:56

The current crash investigation is moving from analysis of the log file, to study of the actual data generated by the run. We will be using a program designed for this purpose, called ParaView. ParaView is invoked by an OpenFOAM procedure called paraFoam. Here is a forecast of the next phase of investigation, with emphasis on possible consequences of my attempt to use a model designed for kerosene and oxygen.

It seems to me we have an opportunity to bring others along with us. We have set the stage, thanks to your success in creating Python programs that capture essential data from the log of our test run. We are about to enter into a phase of study that others might be able to emulate. Before we proceed (much as I am chafing at the bit to get started) let's take a moment to package all the advice and guidance you just created. Start with my question, and please prepare your answer for BBCode display.
***
ChatGPT said:
Absolutely — that’s a wise and generous decision. You're creating a learning environment that’s not just technically rich but also structured for accessibility.
Here is the full BBCode-formatted post based on your excellent question and the compiled response — ready for your forum thread:
Can Our Use of Hydrogen Explain the Model Failure at the Nozzle Throat?
Background
The original Merlin engine mesh may have been designed to simulate combustion of kerosene and oxygen, which produces carbon dioxide and water vapor — relatively heavy molecules.
Our updated model uses pure hydrogen as the working fluid. Hydrogen has very different thermodynamic behavior due to its low molecular mass, and we now ask:
Could this change to hydrogen be contributing to the observed model crash at the throat?
Why Molecular Mass Matters in CFD Simulations
Speed of Sound: Hydrogen has a much higher sound speed due to its low mass → flow becomes compressible much faster.
Mach Number Effects: Higher speed of sound means earlier onset of supersonic behavior.
Shock Structure: Hydrogen shocks are sharper and more difficult to resolve numerically.
Lower Density: Lower mass leads to lower density → weaker momentum → greater numerical sensitivity.
Thermodynamic Coupling: Rapid energy and pressure changes can make matrix solvers unstable without sufficient mesh resolution.
What to Watch For in ParaView
As we begin visual inspection of the simulation data, here are five specific signs that may indicate the switch to hydrogen is stressing the model:
Unrealistically sharp gradients: Color transitions (e.g., in pressure) only 1–2 cells wide suggest insufficient resolution.
Pressure overshoots or spikes: Sudden bright bands near the inlet or throat indicate convergence problems.
Backflow or recirculation: Use vector glyphs near the inlet — hydrogen’s low density makes it vulnerable to reverse flow under pressure waves.
Divergence or swirl near the throat: If velocity arrows change direction sharply or curl inward, this could be instability forming.
Final pressure spike in residuals: As we’ve already seen in log analysis — a large jump in p residual suggests a loss of continuity under high-Mach flow.
Interpretation and Next Steps
✅ It is very likely that the change to hydrogen has made the flow more challenging for the mesh to resolve accurately.
Hydrogen flows faster, compress more sharply, and introduce steeper gradients.
✅ The observed crash at the throat is consistent with these effects — especially in a mesh originally tuned for denser gases.
What We Will Do Next
We will now move into ParaView visualization of the final time steps. Our goals:
Inspect pressure and velocity near the throat,
Look for under-resolved shock zones or flow reversals,
Determine if the mesh is fine enough for hydrogen’s speed and behavior.
If problems are confirmed, we can test:
Refining the mesh only near the throat,
Smoothing the inlet ramp-up,
Or adjusting timestep control for high-speed gas.
Compiled by the Project Development Team, April 2025.
✅ This post sets the stage for your audience —
It brings everyone along with you, regardless of their background, and highlights the value of cautious substitution when switching working fluids.
When you’re ready to begin ParaView inspection, I’ll provide the click-by-click walkthrough for:
Slicing the field,
Coloring by pressure and velocity,
And spotting signs of hydrogen-induced instability. ?

Ahead of beginning the actual work, I'll add that ParaFiew is a complex program, and I have only learned to use a few basic features.

(th)

tahanson43206 · 2025-04-29 12:01:34

In beginning work with ParaView, I spent a bit of time trying to deal with basic issues, such as:

What is the name of the model?

To my surprise, ChatGPT4o "thinks" the name of the model is "internalMesh"

Here is a display of the hierarchy in the properties panel:

vtkMultiBlockDataSet
├── unzoned
│ └── internalMesh
└── patches
├── wall
├── inlet
├── outlet-1

The model on display in RenderView1 has a name, but that name is not obvious. I discovered that a right click on the model would show the name.

Block: internalMesh

That is definitely NOT what I was expecting, but then, I should probably not have been "expecting" anything.

The model on display in RenderView1 is familiar to us because we've been working with it since post #20
https://newmars.com/forums/viewtopic.ph … 61#p231261

I discovered that a right click on the model brings up a menu:

Block 'internalMesh'
Hide Block
Show Only Block
Show All Blocks
Set Block Color
Unset Block Color
Set Block Opacity
Unset Block Opacity
Hide
Representation
Color By
Edit Color
Link Camera
Show Frame Decorations

Some of these lines are selected by default.

The image below shows the model with Slicer Activated, with view in default Z axis:

The next step is to rotate the model so the image displays along the X axis.

tahanson43206 · 2025-04-29 13:19:55

This post picks up the study after we rotate the camera to look along the X axis.

The next experiment will be to run the animation from this perspective.

Here is a closeup view of the model just before crash. The closeup clearly shows that the flow is well PAST the narrow part of the throat, and starting to expand into the expansion bell.

I have NO idea what we might do with this information.

(th)

tahanson43206 · 2025-04-30 17:37:24

This post is about a file containing pressure readings just before the crash at Time Step 281. A python program pulled the pressure data from the "p" file in Time Step 281 and created a histogram. Along the way it found a pressure reading of 32 bar, although that does not show up in the histogram. The histogram is a study of over 13000 cells, and if only one contained that extreme pressure reading, then it would not have qualified for it's own bar.

However, since that high reading ** did ** occur, it is evidence of shock waves happening as hydrogen advances past the throat of the Merlin Engine throat.

(th)

tahanson43206 · 2025-04-30 19:05:45

This post is to record measurements of the Merlin Engine model:

X Range: -0.4 to 5 (5.4 m)
Y Range: -1.626042229 to 1.626042229 (3.25208 m)
Z Range: -0.06303653966 to 0.06303653966 (0.126073 m)

The length is of the entire model, including the intake and the rectangular region that includes the expansion bell.

Apparently we can resize the mesh to that our target pipe diameter will integrate/merge with the intake.

The diameter of the intake turns out to be 40 cm:

Intake Y range: -0.2 to 0.2
Intake diameter (Y): 0.4 meters

ChatGPT4o and I have decided to give up on the attempt to push past the instability crash at step 281. Efforts to do so produced megabytes of data and no solution.

We'll start work on integrating the heat pipe to the intake tomorrow.

As a point of clarification.... the working theory is that adding the heat pipe will give the simulation software time to adjust to the flow of hydrogen, since it will begin feeding at the top of a 240 meter pipe and gradually begin building up pressure at the intake, so the software will have plenty of time to calculate progress of gas through the system. If that theory holds up, we won't continue seeing the crash past the throat, because the region past the throat will be gradually building up temperature and density.

(th)

tahanson43206 · 2025-05-01 09:36:40

Today's work session is focused upon cleaning up the mesh we received from an anonymous donor.

This is speculation on my part, but the donor may have used a tool such as Blender or Fusion 360 to create a model, and then (perhaps) used a conversion tool to convert the stl file to polyMesh. In the polyMesh, we (ChatGPT4o and I) have found numerous instances of decisions made that look like automated defaults. The most annoying of these is the use of the keyword "wall" (which has specific properties) for sections of the model. OpenFOAM complains about this every time we run the model, and since we are starting over to add the heat pipe, this is a great time to clean up the mess. In the end of the process, we should have the expansion bell defined with it's own name, and the upper and lower boundaries likewise identified.

After all this is finished, we can proceed to learning how to extrude the intake flange to make a pipe. This cannot be done directly as it can in Blender, so there will be a learning phase ahead. If anyone reading this wants to get a head start, there are videos online to show how to set up a pipe in OpenFOAM. Pipes are (understandably) a popular subject of OpenFOAM users, because so many (if not all) industrial processes use pipe.

(th)

tahanson43206 · 2025-05-01 09:43:24

This post is intended to hold a tool that is designed to identify sections of an OpenFOAM polyMesh that are incorrectly named.

It is hoped this tool would be helpful for anyone who is working with an inherited mesh that is incorrectly labeled.

Created by ChatGPT4o on 2025/05/01

#!/bin/bash
# Script to identify face ranges in polyMesh/boundary and associate them with readable labels
# For use in refining and renaming 'wall' and other ambiguous boundaries
# Version 2025-05-01 by ChatGPT + tahanson43206 (NewMars.com/forums)

# Read boundary file to extract patches
boundaryFile="constant/polyMesh/boundary"
facesFile="constant/polyMesh/faces"

if [ ! -f "$boundaryFile" ]; then
    echo "Error: $boundaryFile not found."
    exit 1
fi

if [ ! -f "$facesFile" ]; then
    echo "Error: $facesFile not found."
    exit 1
fi

echo "Reading boundary patches and identifying face ranges..."

# Extract patch names, face counts, and start positions
grep -A 4 "^[[:space:]]*[a-zA-Z0-9_-]\+" "$boundaryFile" |
awk '
    /^[[:space:]]*[a-zA-Z0-9_-]+$/ {
        patchName = $1
    }
    /nFaces/ { nFaces = $2 }
    /startFace/ {
        startFace = $2
        endFace = startFace + nFaces - 1
        printf("%-20s  Faces %7d to %7d\n", patchName, startFace, endFace)
    }'

# Optional: Count how many times each patch name is referenced in ParaView
# This script only lists face ranges and can be extended to propose renaming

echo "\nTo rename ambiguous patches like 'wall', consider mapping specific face ranges to meaningful names."
echo "Use ParaView's Patch Labels to correlate face locations with mesh regions."
echo "\nYou may copy face blocks, rename them, and edit boundary entries to improve clarity."

echo "\nScript complete. You can now plan your boundary renaming based on face ranges."

Above is a starting version. Output shown below is insufficient but it does duplicate output from checkMesh, which is a positive indicator.
wall Faces 27436 to 27889 << the problem to be solved is identifying separate collections of faces for bell, top and bottom
inlet Faces 27890 to 27914 << apparently sufficient as is
outlet-1 Faces 27915 to 27974 << likewise
outlet-2 Faces 27975 to 28063 << likewise
frontAndBackPlanes Faces 28064 to 55813 >> this is the 3D fudge for a 2D model. It refers to the Z parameter of thickness 1

(th

tahanson43206 · 2025-05-01 09:56:58

Here is the next attempt:

Script for Y Range Calculation

Correction applied to the code below:

startFace=$(awk '/wall/,/}/ {if ($1 == "startFace") print $2}' constant/polyMesh/boundary | tr -d ';')
nFaces=$(awk '/wall/,/}/ {if ($1 == "nFaces") print $2}' constant/polyMesh/boundary | tr -d ';')

grep -Eo '\([0-9eE+.-]+\s+[0-9eE+.-]+\s+[0-9eE+.-]+\)' constant/polyMesh/points | \
awk -F '[()]' '{ print $2 }' | \
awk '
{
    x = $1; y = $2; z = $3;
    if (x < 0) {
        if (NR == 1 || y < minY) minY = y;
        if (NR == 1 || y > maxY) maxY = y;
    }
}
END {
    print "Intake Y range: " minY " to " maxY;
    print "Intake diameter (Y): " maxY - minY " meters";
}'

# New: Analyze wall patch face indices and find spatial clusters
awk 'BEGIN{inWall=0}
    /wall/ {inWall=1; next}
    /}/ {inWall=0}
    inWall && /startFace/ {start=$2}
    inWall && /nFaces/ {count=$2; end=start+count-1; print "wall Faces: " start " to " end; exit}
' constant/polyMesh/boundary

# Now extract those faces and point IDs from the faces file
startFace=$(awk '/wall/,/}/ {if ($1 == "startFace") print $2}' constant/polyMesh/boundary | tr -d ';')
nFaces=$(awk '/wall/,/}/ {if ($1 == "nFaces") print $2}' constant/polyMesh/boundary | tr -d ';')

endFace=$((startFace + nFaces - 1))

# Extract wall face definitions
sed -n "$((startFace+1)),$((endFace+1))p" constant/polyMesh/faces > wall_faces.txt

# Use those point IDs to map to coordinates
mapfile -t points < <(grep -Eo '\([0-9eE+.-]+\s+[0-9eE+.-]+\s+[0-9eE+.-]+\)' constant/polyMesh/points | sed 's/[()]//g')

awk -v points_file="constant/polyMesh/points" '
BEGIN {
  while ((getline < "wall_faces.txt") > 0) {
    split($0, a, " ");
    for (i = 2; i <= a[1]+1; i++) {
      pid = a[i];
      if (!seen[pid]++) {
        cmd = "awk \"NR==" pid+1 "\" " points_file;
        cmd | getline line;
        close(cmd);
        gsub(/[()]/, "", line);
        split(line, xyz, " ");
        print xyz[1], xyz[2], xyz[3];
      }
    }
  }
}' > wall_patch_points.xyz

# Output now contains the actual XYZ locations of wall patch points for clustering/visual aid

The corrected code above produced this result:
Intake Y range: -0.2 to 0.2
Intake diameter (Y): 0.4 meters
wall Faces: to 453

(th)

tahanson43206 · 2025-05-01 10:19:09

Here's another version of the script to find sections of the polyMesh that need new names.

Please note that is is a ** very ** hard problem.

#!/bin/bash

# Extract Y range of intake from the polyMesh/points file
grep -Eo '\([0-9eE+.-]+\s+[0-9eE+.-]+\s+[0-9eE+.-]+\)' constant/polyMesh/points | \
awk -F '[()]' '{ print $2 }' | \
awk '
{
    x = $1; y = $2; z = $3;
    if (x < 0) {
        if (NR == 1 || y < minY) minY = y;
        if (NR == 1 || y > maxY) maxY = y;
    }
}
END {
    print "Intake Y range: " minY " to " maxY;
    print "Intake diameter (Y): " maxY - minY " meters";
}'

# Extract wall face range from boundary file
startFace=$(awk '/wall/,/}/ { if ($1 == "startFace") print $2 }' constant/polyMesh/boundary | tr -d ';')
nFaces=$(awk '/wall/,/}/ { if ($1 == "nFaces") print $2 }' constant/polyMesh/boundary | tr -d ';')

# Confirm both values are present before computing
if [[ -n "$startFace" && -n "$nFaces" ]]; then
    endFace=$((startFace + nFaces - 1))
    echo "wall Faces: $startFace to $endFace"
else
    echo "Failed to extract wall face range — check boundary file syntax."
fi

Output is:
Intake Y range: -0.2 to 0.2
Intake diameter (Y): 0.4 meters
wall Faces: 27436 to 27889

This output is what ChatGPT4o was expecting. However, we are not done, because the "wall" is actually composed of multiple sections, each of which needs to be named explicitly.

OK! It turns out the above was a trial run to find the first section of 'wall' that should be given a unique name. ChatGPT4o will **now** attempt to find ** all ** the sections.

(th)

tahanson43206 · 2025-05-01 10:57:45

At this point in the effort to discover the individual sequences of faces that make up sections of the mesh that need names, ChatGPT4o asked me to upload the 'points' file and the 'faces' files. It used the powerful computing resources it has available to work the problem, which I greatly appreciate!

The result of the analysis just appeared in the form of an image

More work needs to be done, but the image shows the distinct sections that need to be given specific names

As a point of detail that may be of interest, the gap across the intake bell is .4 meters (40 centimeters)

The Optical Plane application calls for a heat pipe of 20 centimeters, so after the polyMesh is brought up to modern standards, I'll attempt to shrink the engine to 1/2 it's current size.

Update: In attempting to proceed, ChatGPT4o reported that some of the data it found in the inherited model was not helpful. It appears to have found a work around. I asked if the unhelpful data might have been an artifact of the software that might have been used to convert from an stl file to polyMesh.

In the end, ChatGPT4o and I decided to give up on the idea of renaming the individual sections of the mesh, and simply renamed the entire collection.

We succeeded in setting up a new model for the heat pipe addition, and ran a test that confirmed everything is as it should be. Since there is no automatic way to extrude the mesh of the intake flange, it appears we'll be learning how to extend that edge numerically. Tomorrow I also want to cut the dimensions of the model in half, so the intake diameter is 20 centimeters instead of 40. That is (apparently) MUCH easier than trying to extend the intake.

(th)

tahanson43206 · 2025-05-01 19:30:22

This post is about preparing for a work session in which an attempt will be made to extend the existing Merlin Engine Intake out to the left to make a heat pipe. This idea may not prove feasible. The cards are definitely stacked against it. However, to that end, I used the points plotter prepared by ChatGPT4o to examine the leftmost points in the points array of the model. The leftmost points are visible in this plot, along with the rest of the points making up the intake.

The leftmost 10 columns of the display are already in the form of a pipe.

I have NO idea if it is possible, but my hope is that there might be a way to write a program to generate the points and the faces to make up cells to extend the existing 10 column points further to the left.

Update: NewMars membership includes folks with aptitude for mathematics. The OpenFOAM mesh we are using is configured with the standard six sided cell. There are four sides, top and bottom. OpenFOAM supports many other configurations, but the six sided cell is standard, and that is what we are using. I ** think ** (hope) it is possible to determine the lengths of the lines that link the points in the image above. I ** think ** but don't know yet, that the image includes two layers of points. The view is from high up on the Z axis, and the thickness of the 3D shape is very small, so there may be only a very small distance in the Z direction, but it must be greater than zero, because the OpenFOAM software is designed for 3D flow analysis. Our model is able to get away with 2D because we are interested in gas flow in our plumbing, and gas doesn't "care" how thin the Z axis may be, so long as there is room to bounce around.

(th)

tahanson43206 · 2025-05-02 08:26:11

In preparation for today's work session, I removed the sloping part of the intake, leaving only the pipe.

We have 10 columns of data shown in the display. However, I have confirmed there are 20 columns, because the two plates of the model are separated by a very small distance: C988 vs C1: Difference is 0.12607307932 so Z for every cell should be this number.

The challenge for ChatGPT4o (or our NewMars mathematicians) is to determine the lengths of the lines separating the points in the pipe. Whatever those lengths are, they define the sides of the six faces of each cell.

To give everyone a fair chance, here is a link to the data displayed in the image above:
https://www.dropbox.com/scl/fi/ckb7xjhw … 0pood&dl=0

By inspection of the model using ParaView, I counted 25 vertical bars comprising the left facing wall of the intake.

At this point I don't know if the cells are continuous from +Z to -Z but the visual display suggests that might be the case.

Update: ChatGPT4o has computed a set of points to be added to the existing mesh, to define a new structure to be located immediately to the "left"(-X) of the existing leftmost structure. The plot utility shows that the new points are in exactly the correct locations with respect to the existing points.

Update: After chewing on the data for a while, ChatGPT4o and I came up with a set of points that ** might ** blend into the existing mesh. That remains to be seen, but the breakthrough occurred when ChatGPT4o decided to use the Y and Z values ** exactly ** as they are defined in the existing mesh, and add ** only ** the X change. Here is the result for the new points. We have already confirmed they line up visually with the existing ones.

Update: ChatGPT4o "thinks" it has created the faces entries to match the new points. I've saved the file and will try it later.

The new faces and the new points have to be added together. I tried adding the points by themselves and checkMesh had a fit. It ** did ** report seeing the new points, but it tried to use them anyway and created a puff of blue smoke (metaphorically speaking, of course).

(th)

tahanson43206 · 2025-05-02 21:13:31

In an evening work session, ChatGPT4o fixed a bug in the first set of new "faces" data, and then went on to generate new data lines for the "owner" file. I'm not entirely clear on what the owner file does ... I ** think ** the number in the file is the owner of a cell, based upon the physical location of the line in the file, but I'm not sure about that. What I ** do ** know is that the number of new owner lines matches the number of new cells we added which is 25. The number of new data points is 51, which is twice 25 plus one. I'll have to ask ChatGPT4o about that tomorrow. Perhaps the answer is that many points are shared with other cells. The out facing points would themselves be shared by adjacent cells, but there would be one point in the corner of a new cell that it does not share. Well, it's not something to worry about now. The test of the new addition to the mesh is scheduled for tomorrow. I expect it will fail again. This is a very complex undertaking. However, it's worth the effort, if we can get this single set of 25 cells to merge into the existing mesh.

(th)

tahanson43206 · 2025-05-03 08:32:04

This post is dedicated to reporting on an attempt to prepend a new set of cells to the "front" (leftmost) of the Merlin Engine model in OpenFOAM.

This has been quite a learning experience, considering the leap required over 11+ years from 2011 OpenFOAM to today's far more powerful version.

ChatGPT4o has done 99% of the work, and I have had the privilege of serving as the front line implementer and reporter as we go along.

I ** can ** admit to thinking of the idea of extending the intake of the engine nozzle to the left, to form the pipe that we need for the Optical Plane deep space vessel, ** and ** more importantly perhaps, identifying the points in the huge collection of points that are defined in the inherited model as the left most points. I did that by sorting the points into ascending order, and selecting those that comprise the left most face of the model. That wasn't too hard. I expect all NewMars members could do it. What it ** did ** do, however, was to dramatically reduce the search space for ChatGPT4o.

Given the points to work with, ChatGPT4o then found the matching faces in the Merlin model, and (with a bit of confusion that we cleared up) created a set of new faces for the new set of cells. The last piece added late last night was a set of points defining the numbers of the cells that "own" the new faces. I realized just now that the "owner" table defines the cells in the model. We should have 25 more cells, compared to the original. Each cell has six faces, and each cell shares many of those faces with neighboring cells. There is a table called "neighbours" but at this point, ChatGPT4o doesn't "think" we need entries there. checkMesh will let us know if that theory is correct.

I understand that adjustments are now needed to a file called "boundary" which must match the points, faces and owners defined in associated files.

One of the learning items became clear to me overnight. ChatGPT4o insisted that we have to add the new elements to the bottom of the ASCII files that are the input to OpenFOAM. It did not use the language of databases in trying to convince me that adding at the bottom is a "very good idea", but I came to realize that the row number is the primary key in the databases created by OpenFOAM as is pulls the ASCII data in. OpenFOAM is a C++ package, and (of course) it uses traditional databases to perform the massive calculations needed for CFD runs.

In the end, I dutifully added the new items to the bottoms of the respective files, and hopefully checkMesh will be happy when we run it today. Come to think of it, checkMesh ** must ** be doing the same parsing of the ASCII files and database loading that the solvers do, with the difference that checkMesh is nice enough to report problems without crashing as solvers tend to do. That said, I created a situation that was so ** bad ** yesterday that even checkMesh crashed. I ran checkMesh before ChatGPT4o had completed it's work, just to see what would happen. It wasn't pretty!

First, however, there is the small matter of adjusting "boundary" to match all the changes made to the other feeder files.

(th)

tahanson43206 · 2025-05-03 09:54:36

For anyone who might chance to find this topic, here is a tip for insight into organization of the data that comprises a mesh for an OpenFOAM model.

OpenFOAM is remarkably accessible precisely because it uses ASCII control and data files. Anyone can edit these files as needed.

What is a bit more difficult is knowing ** how ** to make changes so the parser in OpenFOAM solvers can build runtime arrays needed for fast processing. The notes by ChatGPT4o below attempt to summarize the process.

Understanding OpenFOAM File Structure: Why New Entries Must Be Appended
Many OpenFOAM users — especially those customizing their own meshes — encounter challenges when modifying the core files in polyMesh. A frequent pitfall is placing new entries at the top or middle of a file. This can silently corrupt the mesh and trigger cryptic errors.
Here’s the key insight that unlocks the mystery:
Each line in OpenFOAM’s mesh definition files acts as a primary key — an implicit index into a database of mesh topology and geometry.
In the points file, each line defines a 3D coordinate and is accessed by its line number.
In the faces file, each face is built from a set of points — referenced by point indices.
The owner file assigns each face (by line number) to a cell.
The neighbour file assigns each internal face (by line number) to a second cell.
The boundary file maps a name (e.g., inlet, outlet) to a specific range of faces — again, using line numbers.
What this means:
If you insert a new entry in the middle of one file, all the index-based references in other files break — because every line number after that insertion shifts.
Therefore:
Always append new entries at the bottom of the file.
Never change the order of existing entries unless you’re updating every dependent file.
Use tools like checkMesh to verify mesh integrity after making changes.
Think of OpenFOAM like a relational database where foreign keys are implicit — tied directly to line numbers. Appending preserves all existing relationships. Inserting or reordering does not.
—
Summary
To keep your OpenFOAM model working correctly, treat each mesh file like a database table — and only add new entries at the end. It's the safest, cleanest way to expand your mesh.

(th)

tahanson43206 · 2025-05-03 10:13:39

In our attempt to prepend a small section of mesh (25 cells) to an existing mesh with thousands of cells, ChatGPT4o and I are discovering new requirements as each hurdle is crossed. In the summary below, we report on discovery of three ** more ** files that must be updated:

BBCode Summary: Updating an OpenFOAM Mesh by Appending New Cells
This post summarizes the steps required when manually extending a polyMesh in OpenFOAM with new cells—such as adding a short intake section to an existing geometry. This approach is useful when modifying inherited meshes where full re-meshing isn't feasible or desirable.
Key Steps to Update the Mesh:
points: Add new point entries at the end of the constant/polyMesh/points file. Update the count accordingly. These should be aligned and precisely calculated to match existing geometry.
faces: Add new face definitions at the end of constant/polyMesh/faces. These describe the faces (by point indices) that form the new cells. Match the pattern of existing entries—most often quads starting with 4(.
owner: For each new face, assign an owner cell index—starting from the last existing cell. Append to the owner file and increment the count.
neighbour: (Optional, depending on cell type.) If new internal faces are defined, also add entries to neighbour. Boundary faces typically do not require entries here.
boundary: Add a new patch entry in constant/polyMesh/boundary, matching the face range (start index, number of faces). Ensure type is correctly set (e.g., patch, wall).
0/ field files (T, U, p, etc.): Add corresponding boundaryField entries for your new patch in every file under the 0 directory. These define the initial and boundary conditions for the new mesh region.
Best Practices:
Always append—do not insert—entries in points, faces, owner, neighbour. OpenFOAM uses row order as the implicit key across files.
Maintain precise numerical alignment with existing mesh to avoid small mismatches that cause solver instability.
Use checkMesh after every structural change to validate integrity before running a solver.
Preserve backups of the mesh before editing—manual changes are powerful but can introduce subtle errors.
Caution: Failure to add matching entries across all files will usually result in either a parser error during mesh creation, or a fatal runtime error during solver execution.

(th)

tahanson43206 · 2025-05-03 10:57:29

In working with the files in the "0" (Zero) directory, I became aware of the inter-dependency of these files with the rest of the control structure.

The properties of the new inletExtension patch is (or should be) identical to the existing inlet patch.

We are setting Temperature, pressure and velocity so the solver knows conditions to expect.

Here is a first attempt to create a checklist for performing this merger of a new patch to an existing mesh:

Checklist for Adding a New Boundary Patch in OpenFOAM
Purpose: When appending new patches (like inletExtension) to an existing mesh, this checklist helps ensure consistency across your configuration.
points: Add new point entries at the bottom. Update count at the top.
faces: Add new face definitions at the bottom. Match the point indices and update count.
owner: Add new cell owner indices (one per face) to extend the domain. Update count.
boundary: Add a new patch block for the new region with correct type and startFace, nFaces. Ensure inGroups is removed or correct.
0/p:
Match patch values to adjacent patch (e.g., use totalPressure and uniform 101325 if consistent).
Consider using vacuum-compatible values (e.g., uniform 1) for space nozzle tests.
0/U:
Patch type often fixedValue or flowRateInletVelocity.
Use same vector or magnitude as adjacent inlet (e.g., uniform (800 0 0)).
0/T:
Match temperature profiles (fixedValue, uniform) to preserve energy conditions.
0/rho (if present):
Match to adjacent patch or recompute from pressure and temperature using equation of state.
0/epsilon, k, nut, etc. (if using turbulence models):
These must also have valid entries for the new patch or the solver will crash.
system/controlDict:
Confirm startTime, endTime, and output settings are appropriate for testing.
mesh sanity check:
Run
checkMesh
after all file changes. Look for warnings or geometry mismatches.
initial test:
Use a short run (endTime = 0.0001) to verify stability before launching full simulation.
Pro Tip: Keep backups of the full constant/polyMesh and 0/ directories before making changes. Use version control or timestamps to avoid accidental data loss.

It seems likely to me we will be updating this checklist as we advance further into this process.

(th)

New Mars Forums

Announcement

#26 2025-04-26 21:50:16

Re: OpenFOAM

#27 2025-04-27 20:57:45

Re: OpenFOAM

Phase 1 Analysis and Phase 2 Preparation Work Plan

Step 1: Extend Log Analysis Capabilities

Step 2: Complete Vacuum Run Forensic Analysis

Step 3: Prepare for Heat Pipe and Propellant Tank Integration

Current Status Summary

#28 2025-04-28 12:11:39

Re: OpenFOAM

Understanding the Importance of Residuals in CFD Simulations

What Are Residuals?

Why Are Residuals Important?

Residuals in Our Nozzle Startup Simulation

#29 2025-04-28 12:42:39

Re: OpenFOAM

Detailed Analysis of OpenFOAM Log Entry at Initial Time Step

Log Snippet (First Active Time Step)

Detailed Line-by-Line Interpretation

Physical Context of This Step

Conclusion

#30 2025-04-28 18:47:33

Re: OpenFOAM

Updated Analysis of Uy Residual Behavior (Inlet to Throat Only)

Summary of Observations

Physical Interpretation

#31 2025-04-29 09:19:26

Re: OpenFOAM

#32 2025-04-29 09:52:51

Re: OpenFOAM

#33 2025-04-29 10:04:23

Re: OpenFOAM

Post-Crash Residual Summary – Merlin Nozzle Startup Simulation

Summary of Field Behavior

Interpretation

#34 2025-04-29 10:46:56

Re: OpenFOAM

Can Our Use of Hydrogen Explain the Model Failure at the Nozzle Throat?

Why Molecular Mass Matters in CFD Simulations

What to Watch For in ParaView

Interpretation and Next Steps

What We Will Do Next

#35 2025-04-29 12:01:34

Re: OpenFOAM

#36 2025-04-29 13:19:55

Re: OpenFOAM

#37 2025-04-30 17:37:24

Re: OpenFOAM

#38 2025-04-30 19:05:45

Re: OpenFOAM

#39 2025-05-01 09:36:40

Re: OpenFOAM

#40 2025-05-01 09:43:24

Re: OpenFOAM

#41 2025-05-01 09:56:58

Re: OpenFOAM

#42 2025-05-01 10:19:09

Re: OpenFOAM

#43 2025-05-01 10:57:45

Re: OpenFOAM

#44 2025-05-01 19:30:22

Re: OpenFOAM

#45 2025-05-02 08:26:11

Re: OpenFOAM

#46 2025-05-02 21:13:31

Re: OpenFOAM

#47 2025-05-03 08:32:04

Re: OpenFOAM

#48 2025-05-03 09:54:36

Re: OpenFOAM

Understanding OpenFOAM File Structure: Why New Entries Must Be Appended

#49 2025-05-03 10:13:39

Re: OpenFOAM

BBCode Summary: Updating an OpenFOAM Mesh by Appending New Cells

#50 2025-05-03 10:57:29

Re: OpenFOAM

Checklist for Adding a New Boundary Patch in OpenFOAM