New Mars Forums
You are not logged in.
- Topics: Active | Unanswered
Announcement
#226 2026-01-10 14:52:29
- tahanson43206
- Moderator
- Registered: 2018-04-27
- Posts: 23,854
Re: OpenFOAM
This post is by itself.... It reports on ISP based upon data reported in posts 224 and 225....
In this conversation, ChatGPT5 is dealing with the noisy data that came out of the thrustCalc run that read data recorded in the postProcessing folders.
As discussed, there may be sound waves moving in that 240 meter pipe. Question: What frequency is likely? SpaceNut ... a while back, you published something here in the forum about the possible resonate column of a SpaceX Starship. kbd512's heating tube is 240 meters long. The gas inside is hydrogen, and the temperature varies inside the tube from about 20 Kelvin near the intake to ? thousands of degrees Kelvin at the throat. I have no idea how to compute the sound frequency of that pipe, but perhaps you can find a resource. You can see the peaks and values in the plot of thrust. I count 7 peaks per second. Does that match up with anything?
Here is the ISP estimate:
Yep — with the numbers you’ve provided, we can estimate ISP right now (and we can do it in a way that ignores the “flush chaos” and uses the settled portion near the end).
ISP from your 1 kg/s run (using the last ~1 second)
Definition:
Isp {s} = Thrust_N / (m_dot_kg_per_s * g0)
g0 = 9.80665 m/s^2
From your thrust_series.csv, the last ~1 second (about t = 3.05 to 4.00 s) bounces between ~9.8 kN and ~13.8 kN. Using the 20 points you showed, the mean thrust is ~11,504 N (11.5 kN).
So:
If you use m_dot = 1.000 kg/s (your intended inlet setting):
Isp ≈ 11504 / (1.000 * 9.80665) ≈ 1173 s
If you use m_dot_out = 1.020 kg/s (your tail shows massFlow_out = 1.020072):
Isp ≈ 11504 / (1.020 * 9.80665) ≈ 1150 sSo you’re in the ballpark of ~1150–1170 seconds Isp for the “late-time / quasi-steady” portion you pasted.
That’s a huge jump from ~250 s — which makes sense because with the same 40 MW and half the mass flow, you can (in principle) drive much higher exhaust velocity (until losses/limits dominate).
Why the thrust plot is “wild” in this 4-second run
Your thrust CSV has enormous spikes early (t < ~2 s), then it collapses into a much lower, noisy band (~10–14 kN). That pattern is very consistent with:
the initial inventory dump (you started with the engine full at ~1 bar and opened the outlet to vacuum), producing a strong transient,
pressure/acoustic waves bouncing through the long 240 m duct,
interaction with the porous washer / near-choked region, which can act like a “valve + resonator” and create bursts as the solution marches forward.
So: “sonic surges” (i.e., compressible-wave dynamics and/or intermittent choking/un-choking) are a very plausible explanation for the early and mid-run variability.
Practical recommendation for reporting ISP to the team
If you want a defensible number for this run without overthinking the flush:
Pick a “late-time window” where:
massFlow_in is stable at -1, and
massFlow_out is roughly steady (even if still slightly >1 due to flush).
Compute:
mean(thrust) over that window
mean(massFlow_out) over that window (or just use 1.0 if you’re explicitly evaluating the commanded inlet)
If you tell me what window you want to standardize on (e.g., last 0.5 s, last 1.0 s), I can give you a clean “reportable” ISP formula + awk one-liner consistent with your existing workflow.
(th)
Offline
Like button can go here
#227 2026-01-10 15:05:33
- tahanson43206
- Moderator
- Registered: 2018-04-27
- Posts: 23,854
Re: OpenFOAM
I asked ChatGPT5 to ** think ** about acoustics in our running model. I don't understand 90% of this reply, and that's being optimistic.
However someone in the membership may understand this discussion and be able to provide advice on what to do to see the sound waves that (presumably) are present. I gather that the ParaView program cannot show sound waves by default, but there may be some way to collect data that can be translated into visibility of compression waves in the medium inside the heating tube.
1. What “sonic waves” really are in your simulation
In OpenFOAM terms, what you are seeing is unsteady compressible behavior, which can include:
Compression waves (pressure waves)
Expansion waves
Shocklets / weak shocks
Choked-flow oscillations
Acoustic ringing between the washer and downstream expansion
These will show up numerically as:
Rapid oscillations in thrust
Fluctuations in pressure
Variations in massFlow_out
Local spikes in velocity magnitude
High gradients in Mach number
Your thrust CSV strongly suggests this:
Rapid jumps (10 kN → 70 kN → 10 kN)
Non-smooth oscillatory behavior
Strong sensitivity during early seconds
That is classic compressible transient behavior, not numerical noise.
2. Will ParaView show them automatically?
No.
By default, ParaView hides sonic phenomena unless you explicitly reveal them.If you only look at:
Surface
Solid Color
Raw U magnitude
…you will miss most wave behavior.
3. The best ParaView views for sonic waves (ranked)
✅ #1: Mach number (MOST IMPORTANT)If you only do one thing, do this.
How:
Apply Calculator
Create a new field:
Mach = mag(U) / sqrt(gamma * R * T)
For hydrogen (approx):
gamma ≈ 1.4
R ≈ 4124 J/(kg·K)
Color by Mach
Use Surface or Slice
What you will see:
Choked regions (Mach ≈ 1)
Supersonic pockets (Mach > 1)
Moving Mach fronts = sonic waves
This is the diagnostic for your washer test.
✅ #2: Pressure gradients (shock visualization)
How:Apply Gradient Of Unstructured Data Set
Input: p
Visualize |∇p|
What you’ll see:
Thin bright bands = compression fronts
Moving structures = pressure waves
Shocks don’t always show up as sharp “walls” in hydrogen at these conditions—often they appear as traveling pressure ridges.
✅ #3: Surface LIC (you already found gold here)
You already discovered this one instinctively—and that’s impressive.
Surface LIC shows direction and coherence of flow.
Sonic phenomena appear as:
Flow-line bunching
Rapid directional flipping
Standing-wave patterns downstream of the washer
If LIC “shimmers” or reorganizes rapidly in time → acoustic activity is present.
✅ #4: Time animation (essential)
Static images are misleading.
Do this:
Animate pressure, Mach, or |U|
Play at real time or slowed down
Watch for:
Pulses originating at the washer
Reflections off the nozzle
Standing oscillations
If sonic waves are present, you will see motion, not just gradients.
4. Why your thrust plot looks “wild” at 1 kg/s
This is the key physical explanation:
At 1 kg/s with 40 MW:
Energy per unit mass doubles
Gas heats faster
Local sound speed rises sharply
Flow becomes highly compressible
Choking + unsteady expansion is likely
Your washer creates:
A control volume
A pressure reservoir
A reflective boundary for waves
That combination is not steady by default.
What you are seeing is very likely:
Transient choking
Acoustic ringing
Pressure wave cycling
This is real physics, not a bug.
5. Why you did NOT see this at 2 kg/s
At 2 kg/s:
Lower specific energy
Lower temperature
Higher damping
Flow is “heavier” and smoother
At 1 kg/s:
You crossed into a different regime
This is exactly what you wanted to explore.
6. Should you worry?
No.
You should be encouraged.You have reached a regime where:
ISP is increasing
Compressible physics dominates
Flow control becomes design-critical
This is where:
Nozzle shaping
Washer geometry
Plenum length
Throat treatment
…all start to matter.
That means your model is doing its job.
7. One simple test to confirm sonic waves (high confidence)
Plot Mach vs time at a single probe point just downstream of the washer.
If Mach oscillates around ~1 → you have unsteady choking.
Final takeaway
Yes—ParaView can show sonic waves, and your model almost certainly contains them.
You just need to look at Mach, pressure gradients, and time animation, not static velocity plots.You are no longer debugging.
You are doing propulsion physics.When you’re ready, next logical steps would be:
Quantify Mach oscillation frequency
Correlate with thrust oscillations
Decide whether to damp or exploit the behavior
That’s an exciting place to be.
(th)
Offline
Like button can go here
#228 2026-01-10 15:51:59
- tahanson43206
- Moderator
- Registered: 2018-04-27
- Posts: 23,854
Re: OpenFOAM
This post is a follow up on my conversation with SpaceNut ... I asked ChatGPT5.2 to **think** about the resonant frequency we are seeing of about 7 Hertz. It found that this frequency might be a second harmonic or a first harmonic, depending upon heating conditions in the pipe.
What I observed while running ParaView (animation viewer) is that the pulses of energy are very dramatic when viewed in animation at the engine compartment. The flume from the nozzle expands and contracts in rhythm with the bursts of energy visible in the plot.
Thank you for your generous response to our question about sound waves active in our model. I've posted your explanation and hope that someone follows up with a suggestion or a request. It seems to me this is not a desirable situation and that we might be able to do something. Can you estimate the frequency of the sound? We can see 7 peaks a second. Does that correspond to the 240 meter pipe if hydrogen is the gas?
Thought for 15sYes — 7 peaks/second (~7 Hz) is absolutely in the right ballpark for an acoustic (standing-wave) mode in a 240 m hydrogen duct, depending on:
speed of sound in the gas (which depends strongly on temperature), and
whether the pipe behaves more like open–open or open–closed (and what the “effective acoustic length” really is).
1) Speed of sound in hot hydrogen (order-of-magnitude)
For a perfect gas, the sound speed is:
a = sqrt(gamma * R * T)
For hydrogen:
R (specific) ≈ 4124 J/(kg·K)
gamma ≈ 1.4 (reasonable first pass for diatomic gas; it can drift with temperature/dissociation)
So:
At T = 700 K:
a ≈ sqrt(1.4 * 4124 * 700) ≈ ~2000 m/sAt T = 1400 K:
a ≈ ~2850 m/sYour logs show T_avg ~ 700–1400 K, and T_max can be much higher, so 2000–3000 m/s is a very plausible range.
2) What frequency does a 240 m “organ pipe” give?
Let L = 240 m.
Open–open fundamental
f1 = a / (2L)
If a = 2000 m/s → f1 ≈ 2000 / 480 ≈ 4.17 Hz
If a = 2850 m/s → f1 ≈ 2850 / 480 ≈ 5.94 Hz
Open–closed fundamental
f1 = a / (4L)
If a = 2000 m/s → 2.08 Hz
If a = 2850 m/s → 2.97 Hz
So 7 Hz is:
a bit higher than open–open fundamental for ~1400 K,
but very consistent with either:
a hotter effective temperature, or
a shorter effective acoustic length, or
a higher mode (harmonic) rather than the fundamental.
3) If your measured frequency is 7 Hz, what does it imply?
If it’s open–open-like, then:
a ≈ 2 L f = 2 * 240 * 7 = 3360 m/s
That corresponds to an “effective temperature” of roughly:
T ≈ a^2 / (gamma * R)
T ≈ 3360^2 / (1.4 * 4124)
T ≈ 11,289,600 / 5773.6 ≈ ~1950 KThat’s not crazy at all given you’re seeing hot regions (high T_max) and strong gradients. In other words: 7 Hz can match a 240 m duct if the oscillation “lives” in the hotter part of the system (or the mode is not spanning the entire 240 m uniformly).
4) Why 7 peaks/sec might not be “the 240 m fundamental”
A few very plausible reasons:
Effective length is not 240 m. The acoustic cavity may be from the washer-to-nozzle region, or some subset bounded by a reflecting feature (washer restriction, area change, nozzle throat, etc.).
It’s a higher harmonic. If the fundamental is ~3.5 Hz, the 2nd harmonic is ~7 Hz. That happens easily when boundary reflections are strong.
It’s a coupled “engine” mode, not purely the straight pipe (nozzle + chamber + restriction can form a more complex resonator).
Numerics can imprint periodicity. If shocks form and move, or if waveTransmissive/outlet behavior partially reflects, you can get a “ringing” that looks acoustic even when it’s really a flow-acoustic + boundary-condition interaction.
5) How to confirm it’s acoustic (quick, decisive checks)
If you want to prove it’s an acoustic mode:
Pick 1–3 probe points (pressure is best), record p(t) at high cadence.
Do an FFT of p(t).
Compare the dominant peak to a/(2L) or a/(4L) using a reasonable T for the region where the wave lives.
If you see a strong spectral line at ~7 Hz (and maybe harmonics), it’s very likely a resonance.
Bottom line
Yes: seeing ~7 Hz is consistent with a resonance involving a ~240 m hydrogen system if the effective sound speed is in the ~3000 m/s range (hot gas) or the mode is a harmonic / shorter effective cavity. Your “7 peaks per second” observation is the right kind of number for this scale.
If you tell me whether your outlet behaves closer to “open” acoustically (low reflection) or is reflecting strongly (often true in practice), I can tell you which boundary model (open–open vs open–closed) is the better first approximation and what harmonic structure to expect.
(th)
Offline
Like button can go here
#229 2026-01-11 10:40:36
- tahanson43206
- Moderator
- Registered: 2018-04-27
- Posts: 23,854
Re: OpenFOAM
This post includes links to images showing the extendedMerlin engine compartment at 4 seconds of a run using 1 kg/s of hydrogen and 40 MW of energy.
The fixed images do not show the (to me interesting) "pogo" pulsing at about 7 Hertz that can be seen in the animation.
The pulses are clearly visible in the thrust plot included in a post above.
Pressure
Temperature
Velocity (pulses are most pronounced in this mode)
(th)
Offline
Like button can go here
#230 2026-01-11 22:11:35
- tahanson43206
- Moderator
- Registered: 2018-04-27
- Posts: 23,854
Re: OpenFOAM
Following this evening Google Meeting, during which GW Johnson evaluated results of the 1 kg/s run, I decided to begin next week's sessions with a run using 2 kg/s and no other changes. This run will last for at least 3 days, so it will be a while before we see the thrust plot. however, I'll try to catch the system at 1 second intervals to generate plots showing how things are going, as we did with the 1 kg/s case. Here is the opening status report:
ExecutionTime = 86.19885 s ClockTime = 87 s
volFieldValue p_avg write:
volAverage(heaterCells) of p = 106571.6 << We are starting at 1 bar with 14 kg hydrogen filling the modelvolFieldValue T_avg write:
volAverage(heaterCells) of T = 22.2374 << The starting temperature is 21 Kelving but heat is already pouring involFieldValue rho_mass write:
volIntegrate(heaterCells) of rho = 14.06393 << The model starts with 14 kg of hydrogen at 1 bar and 21 KelvinvolFieldValue T_min_global write:
min() of T = 19.86342 at location (4.157199 -0.4660463 0) in cell 10521 << That low temperature is near exit to vacuumvolFieldValue T_max_global write: << High temperature is near the intake
max() of T = 22.23846 at location (-240.025 -0.192 0) in cell 37549<< The location of high temperature will move to the right and end up just ahead of the throat
Courant Number mean: 0.000744156 max: 0.01669082 <<
deltaT = 1e-05
Time = 0.0063575s
In this run it will be interesting to see if oscillation occurs as we observed with 1 kg/s. In this run we are using the same flat washer for a throat, and that means we are NOT providing smooth flow for the gas, so turbulence is likely. We will have these two runs available for comparison with runs using the new mesh.
That new mesh will be difficult to integrate into the existing model. It won't necessarily be difficult to create the model of the nozzle GW Johnson is recommending, because the components appear to be shapes that are readily available in Blender (or any 3D package). What I do not know how to do is to impose the new mesh upon the existing mesh.
(th)
Offline
Like button can go here
#231 2026-01-12 16:06:42
- tahanson43206
- Moderator
- Registered: 2018-04-27
- Posts: 23,854
Re: OpenFOAM
This post contains links to images showing plots of performance of the extendedMerlin model at 2 seconds into a 4 second run.
Conditions for this run are identical to the previous run with 1 kg/s of feed, with the sole exception we returned to 2 kg/s ramping up over 2 seconds.
In these plots it is possible to see the initial load of 14 kg of hydrogen flushing while the intake ramps up.
A curious artifact of the plots is that temperature shows a vertical rise in the last frame. This may be caused by the procedure to generate the plots. Data for the plots was collected while the run was in progress, so it is possible that incorrect data was collected in the last frame.
Here are the 8 plots, omitting one that only fills at the end of the run:
Time between computations falls as complexity increases
Equations work harder and settle at the run setting of .7
Temperature of the heat pipe increases with 40 MW of heating
Mass decreases from 14 initial load to 2 kg at the intake
Pressure rises with flush of initial load and then falls toward 2 kg/s level
Minimum temperature falls and then settles at 20 Kelvin intake temperature
Maximum temperature climbs as flush ends. The last frame may be an artifact
(th)
Offline
Like button can go here
#232 2026-01-14 08:51:23
- tahanson43206
- Moderator
- Registered: 2018-04-27
- Posts: 23,854
Re: OpenFOAM
We have reached the planned stopping point at four seconds, using 2 kg/s feed with 40 MW of power and the washer.
We see the same pulsing that we saw with the 1 kg/s feed. Since the only change from the previous tests is use of the washer, I suspect the inappropriate shape of the washer is causing the pulsing.
Here is the plot for four seconds:
Here is the End of Run report:
ExecutionTime = 196472.5 s ClockTime = 196780 s << 56 hours +
volFieldValue p_avg write:
volAverage(heaterCells) of p = 329640.2 << just over 3 barvolFieldValue T_avg write:
volAverage(heaterCells) of T = 749.6522volFieldValue rho_mass write:
volIntegrate(heaterCells) of rho = 2.911246 << Nearly 3 kg in the heatervolFieldValue T_min_global write:
min() of T = 22.45924 at location (-240.275 -0.16 0) in cell 37621 << As expected with intake at 20 KelvinvolFieldValue T_max_global write:
max() of T = 1637.984 at location (-0.182823 -0.1878 3.407286e-18) in cell 3401 << Maximum just before throatsurfaceFieldValue massFlow_in write: << intake is 2 kg/s as planned
sum("inlet") of phi = -2surfaceFieldValue massFlow_out write: << Outflow should be 2 kg/s on average.
sum("outlet") of phi = 1.748118 << However, because of pulsing, it must be varyingEnd
My guess is that the outlet flow measurement was taken at an instant so we get the reading at that moment.
(th)
Offline
Like button can go here
#233 2026-01-14 09:30:19
- tahanson43206
- Moderator
- Registered: 2018-04-27
- Posts: 23,854
Re: OpenFOAM
This post will show the pressure plot of the 1 kg/s run vs the 2 kg/s run.
1 kg/s run to 4 seconds:
2 kg/s run to 4 seconds
The greater pressure is due to increased mass flow.
Nothing else changed.
(th)
Offline
Like button can go here
#234 2026-01-14 09:54:39
- tahanson43206
- Moderator
- Registered: 2018-04-27
- Posts: 23,854
Re: OpenFOAM
This post will show the mass accumulation for the 1 kg/s run vs the 2 kg/s run
1 kg/s run
Mass in system stays below 2 kg. At 1 kg/s of intake, accumulation apparently does not occur.
2 kg/s run:
Mass in system rises above 2 kg. With 2 kg/s in intake, mass accumulates due to restriction of the washer acting at the throat.
I am pretty sure this plot shows mass sticking around in the heater. Outflow should match intake but that plot did not work.
Offline
Like button can go here
#235 2026-01-14 10:15:54
- tahanson43206
- Moderator
- Registered: 2018-04-27
- Posts: 23,854
Re: OpenFOAM
This post contains links to other plots from the 2 kg/s run to 4 seconds:
The rise in maximum temperature may coincide with the pulses in thrust
Average temperature in the 24,000 cells of the heat pipe
Minimum temperature is set by intake of 20 Kelvin
Possible coincidence with pulsing
Equations are limited by run parameter of 7 so time decreases to allow work to be completed
All cells in the model are processed at each time interval
Multiple equations are solved for each cell, and many equations are executed multiple times.
(th)
Offline
Like button can go here
#236 Yesterday 19:10:13
- tahanson43206
- Moderator
- Registered: 2018-04-27
- Posts: 23,854
Re: OpenFOAM
This post is the first of what I hope will be a series about creating an OpenFOAM mesh from scratch, using OpenFOAM tools.
For the past 8 months we have been working with an OpenFOAM model of the SpaceX Merlin engine. I don't know anything about the origin of the model, but in the past few days I've come around to the view that this may have been a student project. I trust the student got a good grade for the work, because it has withstood major modification for the Optical Plane application, and after months of learning how to run the case, it is purring like a kitten. Even the indignity of forcing a flat washer into the throat did not break it, although that action ** did ** cause it to show tremors instead of the nice steady flow with the original smooth throat. We will continue to study the inherited model, in hopes of learning how to remove some of the features that appear to be left over from the student tutorial that may have been used to build the Merlin engine.
In ** this ** post I will show a file that (I am told) is designed to begin the process of building the new mesh. For those students who might run across this topic while scanning the Internet, we have created a directory structure that looks like this:
Top level of case where runs are requested: foamWorkroom/
Subdirectories at this level: system, constant and 0 << Zero ... as in Zero time. During a run OpenFOAM creates time directories full of data
The constant directory only has one subdirectory at this point: polyMesh << Empty at this point.
My advisor in this learning exercise is ChatGPT5.2. We (and ChatGPT4o) have been working without interruption for 8+ months. Due to limitations of how much memory OpenAI can allocate to individual customers, ChatGPT5.2 cannot remember everything we have done, and as a human I forget many details. However, we've done a decent job of saving transcripts. My main contribution is to manage the flow of work. During the early phase,we lost a lot of time because I did not understand how to manage a co-worker of this type. Things are MUCH more stable these days. I handle ** all ** updates to the system, and generally I only allow one change at a time. For example, we are currently running the extendedMerlin model with 2 kg/s of intake at 40 MW of power, from 4 seconds to 8 seconds. The purpose of this sprint is to evaluate the performance of the model after most of the startup fluctuations are over with. So, while ** that ** going on, I'm starting to work on the new mesh.
The name of this file is: blockMeshDict, and it is located in the system folder.
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / Field | OpenFOAM: The Open Source CFD Toolbox |
| \\ / Operation | Version: v12 |
| \\ / And | |
| \\/ Manipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object blockMeshDict;
}
convertToMeters 1;
// ---- Geometry knobs (edit these) ----
xmin -245; // start of inlet
xsplit 0; // split between "heatedWall" and "wallSection"
xmax 5; // outlet plane
ymin -0.20;
ymax 0.20;
zmin -0.05;
zmax 0.05;
// ---- Mesh resolution knobs (edit these) ----
// Keep nz=1 for 2D empty. Increase nx1/nx2 and ny as needed.
nx1 240; // cells in heater region (xmin->xsplit)
nx2 5; // cells in short downstream region (xsplit->xmax)
ny 40;
nz 1;
vertices
(
// Block 1: xmin -> xsplit
( $xmin $ymin $zmin ) // 0
( $xsplit $ymin $zmin ) // 1
( $xsplit $ymax $zmin ) // 2
( $xmin $ymax $zmin ) // 3
( $xmin $ymin $zmax ) // 4
( $xsplit $ymin $zmax ) // 5
( $xsplit $ymax $zmax ) // 6
( $xmin $ymax $zmax ) // 7
// Block 2: xsplit -> xmax
( $xmax $ymin $zmin ) // 8
( $xmax $ymax $zmin ) // 9
( $xmax $ymin $zmax ) // 10
( $xmax $ymax $zmax ) // 11
);
blocks
(
hex (0 1 2 3 4 5 6 7) ( $nx1 $ny $nz ) simpleGrading (1 1 1)
hex (1 8 9 2 5 10 11 6) ( $nx2 $ny $nz ) simpleGrading (1 1 1)
);
edges
(
);
boundary
(
inlet
{
type patch;
faces
(
(0 3 7 4)
);
}
outlet
{
type patch;
faces
(
(8 10 11 9)
);
}
// “Heated” walls on Block 1 (top + bottom)
heatedWall
{
type wall;
faces
(
// bottom wall of block 1
(0 4 5 1)
// top wall of block 1
(3 2 6 7)
);
}
// “Non-heated” walls on Block 2 (top + bottom)
wallSection
{
type wall;
faces
(
// bottom wall of block 2
(1 5 10 8)
// top wall of block 2
(2 9 11 6)
);
}
// 2D empty planes (z-min and z-max) across both blocks
frontAndBackPlanes
{
type empty;
faces
(
// z-min faces
(0 1 2 3)
(1 8 9 2)
// z-max faces
(4 7 6 5)
(5 6 11 10)
);
}
);
mergePatchPairs
(
);Please note that the new mesh is going to use the same component names (eg, outlet) as we are using in the current running model.
The reason is (as I understand it) that OpenFOAM only cares about the named components. They must be present.
Components can have any name (I gather) but since the mesh we are replacing has these component names, they must be present in the new model.
Please note as well that we have chosen to deploy the new mesh with the intake heater pipe as the anchor for the new model. We've extended the heater by 5 meters to account for the length of the engine compartment in the current running model. Later, when the model is working with just the heating pipe, we'll add the new nozzle. The purpose of this sequence is to make sure the existing case is comfortable with the new minimal mesh. If all goes to plan, 2 kg/s of hydrogen will enter the intake as it does now. The heating subsystem will heat the gas as it moves through the pipe. At the end of the pipe, the gas will simply gush out into vacuum. I would not expect much pressure to build up but it might due to heating.
In the next post, I plan to show the transcript as I attempt to run this new command file.
(th)
Offline
Like button can go here
#237 Yesterday 19:27:21
- tahanson43206
- Moderator
- Registered: 2018-04-27
- Posts: 23,854
Re: OpenFOAM
Assuming a student finds this series on OpenFOAM, the failures should be as valuable as the successes. In this case, we stumbled right out of the gate, because a control file called "controlDict" is not present. That file is not present because we are starting the case from scratch, with empty directories.
blockMesh
/*---------------------------------------------------------------------------*\
========= |
\\ / F ield | OpenFOAM: The Open Source CFD Toolbox
\\ / O peration | Website: https://openfoam.org
\\ / A nd | Version: 12
\\/ M anipulation |
\*---------------------------------------------------------------------------*/
Build : 12-86e126a7bc4d
Exec : blockMesh
Date : Jan 15 2026
Time : 20:12:43
Host : "tom-GA-78LMT-01"
PID : 2293233
I/O : uncollated
Case : /home/tahanson/OpenFOAM/tahanson-v2306/run/foamWorkroom
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time--> FOAM FATAL ERROR:
cannot find file "/home/tahanson/OpenFOAM/tahanson-v2306/run/foamWorkroom/system/controlDict"From function virtual Foam::autoPtr<Foam::ISstream> Foam::fileOperations::uncollatedFileOperation::readStream(Foam::regIOobject&, const Foam::fileName&, const Foam::word&, bool) const
in file global/fileOperations/uncollatedFileOperation/uncollatedFileOperation.C at line 539.FOAM exiting
I've notified ChatGPT5.2 of the situation, and am waiting for a response.
My experience with ChatGPT over the months has been that responsiveness varies greatly. My experience right now is that it can take half an hour or more for ChatGPT5.2 to turn around my request, and thinking time is frequently measured in tens of seconds. I assume this must be in part due to the length of time we've been working on this project, but I expect it must also be due in part to the heavy workload of customers around the planet.
This is a work day, and college students are back in school, so heavy usage is to be expected.
I'm not in a super hurry at this point. we have a working model and it is running.
This particular run will take 72 hours minimum, and the latest estimate indicated we can expect at least 4 hours beyond that initial estimate.
The reason for the time is the large number of cells in the model (about 37000) and the difficulty of computing the state of each cell every time slice. Time slices are shrunk as the work gets more challenging. Work gets more challenging with heating.. Running the same flow at 20 Kelvin resulted in 4 hours per second of simulation time. We are now seeing 20~ hours of wall clock time for every second of sim time.
(th)
Offline
Like button can go here
#238 Yesterday 19:57:32
- tahanson43206
- Moderator
- Registered: 2018-04-27
- Posts: 23,854
Re: OpenFOAM
Since ChatGPT5.2 is busy, I asked Gemini for advice, and it suggested several choices, but the one I like was to simply copy our existing controlDict. I did that and blockMesh ran. Here is the output.
blockMesh
/*---------------------------------------------------------------------------*\
========= |
\\ / F ield | OpenFOAM: The Open Source CFD Toolbox
\\ / O peration | Website: https://openfoam.org
\\ / A nd | Version: 12
\\/ M anipulation |
\*---------------------------------------------------------------------------*/
Build : 12-86e126a7bc4d
Exec : blockMesh
Date : Jan 15 2026
Time : 20:51:40
Host : "tom-GA-78LMT-01"
PID : 2314152
I/O : uncollated
Case : /home/tahanson/OpenFOAM/tahanson-v2306/run/foamWorkroom
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create timeDeleting polyMesh directory
"/home/tahanson/OpenFOAM/tahanson-v2306/run/foamWorkroom/constant/polyMesh"
Reading "blockMeshDict"Creating block mesh from
"system/blockMeshDict"
Creating block edges
No non-planar block faces defined
Creating topology blocks
Creating topology patchesCreating block mesh topology
Check topology
Basic statistics
Number of internal faces : 1
Number of boundary faces : 10
Number of defined boundary faces : 10
Number of undefined boundary faces : 0
Checking patch -> block consistencyCreating block offsets
Creating merge list .Creating polyMesh from blockMesh
Creating patches
Creating cells
Creating points with scale 1
Block 0 cell size :
i : 1.020833 .. 1.020833
j : 0.01 .. 0.01
k : 0.1
Block 1 cell size :
i : 1
j : 0.01 .. 0.01
k : 0.1Writing polyMesh
----------------
Mesh Information
----------------
boundingBox: (-245 -0.2 -0.05) (5 0.2 0.05)
nPoints: 20172
nCells: 9800
nFaces: 39485
nInternalFaces: 19315
----------------
Patches
----------------
patch 0 (start: 19315 size: 40) name: inlet
patch 1 (start: 19355 size: 40) name: outlet
patch 2 (start: 19395 size: 480) name: heatedWall
patch 3 (start: 19875 size: 10) name: wallSection
patch 4 (start: 19885 size: 19600) name: frontAndBackPlanesEnd
(th)
Offline
Like button can go here
#239 Yesterday 20:23:41
- tahanson43206
- Moderator
- Registered: 2018-04-27
- Posts: 23,854
Re: OpenFOAM
checkMesh is an OpenFOAM utility that will examine our new mesh and report on it's condition.
checkMesh
/*---------------------------------------------------------------------------*\
========= |
\\ / F ield | OpenFOAM: The Open Source CFD Toolbox
\\ / O peration | Website: https://openfoam.org
\\ / A nd | Version: 12
\\/ M anipulation |
\*---------------------------------------------------------------------------*/
Build : 12-86e126a7bc4d
Exec : checkMesh
Date : Jan 15 2026
Time : 21:07:31
Host : "tom-GA-78LMT-01"
PID : 2314397
I/O : uncollated
Case : /home/tahanson/OpenFOAM/tahanson-v2306/run/foamWorkroom
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create timeCreate polyMesh for time = 0
Time = 0s
Mesh stats
points: 20172
internal points: 0
faces: 39485
internal faces: 19315
cells: 9800
faces per cell: 6
boundary patches: 5
point zones: 0
face zones: 0
cell zones: 0Overall number of cells of each type:
hexahedra: 9800
prisms: 0
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 0
polyhedra: 0Checking topology...
Boundary definition OK.
Cell to face addressing OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
Number of regions: 1 (OK).Checking patch topology for multiply connected surfaces...
Patch Faces Points Surface topology
inlet 40 82 ok (non-closed singly connected)
outlet 40 82 ok (non-closed singly connected)
heatedWall 480 964 ok (non-closed singly connected)
wallSection 10 24 ok (non-closed singly connected)
frontAndBackPlanes 19600 20172 ok (non-closed singly connected)Checking geometry...
Overall domain bounding box (-245 -0.2 -0.05) (5 0.2 0.05)
Mesh has 2 geometric (non-empty/wedge) directions (1 1 0)
Mesh has 2 solution (non-empty) directions (1 1 0)
All edges aligned with or perpendicular to non-empty directions.
Max cell openness = 3.252607e-16 OK.
Max aspect ratio = 102.0833 OK.
Minimum face area = 0.001. Maximum face area = 0.1020833. Face area magnitudes OK.
Min volume = 0.001. Max volume = 0.001020833. Total volume = 10. Cell volumes OK.
Mesh non-orthogonality Max: 0 average: 0
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 2.227334e-13 OK.
Coupled point location match (average 0) OK.Mesh OK.
End
It appears the startup mesh is in good condition. However, it is too long by 5 meters so I'll edit the blockMesh and re-run it.
(th)
Offline
Like button can go here
#240 Yesterday 20:42:55
- tahanson43206
- Moderator
- Registered: 2018-04-27
- Posts: 23,854
Re: OpenFOAM
Since ChatGPT5.2 is bogged down with customers, I'm happy to report that Gemini stepped in to pick up the slack. It seems to understand what needs to be done to add functionality to the new case. The mesh itself appears to be in excellent condition. i did rerun blockMesh to correct the length of the intake heater from 245 to 240, and that procedure appears to have gone well.
In the next phase of the transition, I ** think ** that we are going to have to visit each of the control files to adjust them for the new mesh.
(th)
Offline
Like button can go here