OpenFOAM

tahanson43206 · 2025-12-03 21:41:38

The run to 6 seconds from 3 seconds is underway, with finish estimated at 3 AM local time.

ChatGPT5 and I collaborated to generate graphs from the log data we are building up. The two graphs below show:

1) The decline of something called sumE
file.php?id=10
2) the more modest decline of average temperature
file.php?id=9

What I find interesting in the temperature plot is that the trendline appears to be toward the same 299 Kelvin temperature we saw with the 2 kg/s run.

I have no idea why this might be, but I assume and hope that GW Johnson will be able to explain it.

I don't know what sumE represents, so I can't comment other than to note it is decreasing more rapidly than the average temperature.

(th)

tahanson43206 · 2025-12-04 10:41:30

The run to 6 seconds of extendedMerlin with intake set at 20 kg/s is complete.

Here is a link to a plot of thrust that appears to support GW Johnson's prediction of nearly 5 tons-force.

file.php?id=12

Additional plots will be added later today. The entire log of the run is ready for input to the utility to extract a set of data for three data items: sumE, Average T and sum(rho).

The image at the link below shows the sum of rho - it closely matches thrust:
file.php?id=13

The image at the link below shows how temperature fluctuates during the startup phase, when we are exhausting the 1 bar fill and ramping up intake flow:
file.php?id=14

(th)

tahanson43206 · 2025-12-04 19:51:23

A run to 7 seconds is under way...

The reason for ** this ** run is to collect pressure data. Pressure data is available from previous runs, but it is buried in the mass of data collected by the software. A function was added to display pressure directly, and it shows the pressure inside the intake to be consistently above 9 bar. That reading is consistent with the thrust readings we are seeing for the test run with 20 kg/s of hydrogen at the intake.

In another topic i have reported on the (to me surprising) performance of the system with the gas temperature readings not above 300 Kelvin.

I hope the CFD performance stands up to scrutiny.

Here is a snapshot of performance data reported periodically in the run log:

volFieldValue heatBoxStats write:
sum(heaterCells) of e = 4.52211e+08
volFieldValue T_avg write:
volAverage(heaterCells) of T = 300.0018 << 300 Kelvin throughout the intake/heater
volFieldValue p_avg write:
volAverage(heaterCells) of p = 911545.3 << 9 bar throughout the intake/heater
volFieldValue rho_sum write:
sum(heaterCells) of rho = 17681.61 << not sure what this is
Courant Number mean: 0.04045834 max: 0.6999997
deltaT = 3.59979e-06
Time = 6.6960156s << we are well along toward the run goal of 7 seconds

(th)

tahanson43206 · 2025-12-05 07:26:37

The run to 7 seconds by the extendedMerlin model with flow set to 20 kg/s ended normally early this morning local time.
Here is what a normal end looks like:

ExecutionTime = 34485.89 s ClockTime = 34626 s << a bit over 9 hours
volFieldValue heatBoxStats write:
sum(heaterCells) of e = 4.514843e+08
volFieldValue T_avg write:
volAverage(heaterCells) of T = 299.9988 << Average temperature settled at a whisker under 300 Kelvin
volFieldValue p_avg write:
volAverage(heaterCells) of p = 911583.2 << Pressure remains steady at 9 bar
volFieldValue rho_sum write:
sum(heaterCells) of rho = 17682.52
End

Images planned for later today include: thrust and at least three items from the log

Thrust plot holding steady at 49.5 kN
file.php?id=15

Heater Sum(e) for one second from 6 to 7
file.php?id=17

Heater Sum(rho) for one second from 6 to 7
file.php?id=16

Heater Average Temperature vs Time from 6 to 7
file.php?id=18

This next set of images are from ParaView, looking at the engine compartment after 7 seconds

file.php?id=19
Pressure
file.php?id=20
Temperature
file.php?id=21
Velocity

This last section shows plots for the full seven seconds:

Tracks thrust but shows heating
file.php?id=22
Heater Sume(e) ... shows fluctuations at startup
file.php?id=23

(th)

tahanson43206 · 2025-12-15 07:35:19

The Google Meeting discussion 2025/12/14 included evaluation of recent OpenFOAM work.

GW Johnson agreed with kbd512 that the next phase should be to implement the "washer" concept for a constricted throat.

However, of greater significance is the heating reports from the model. Both the 2 kg/s run to 7 seconds and the 20 kg/s run show the same temperature of 300 degrees Kelvin... GW asked me to investigate the heating system. Readers of this topic may recall that we changed to "volume" heating from convective heating, and we are now getting reasonable thrust performance but the temperatures reported are both close to 300 Kelvin.

Specifically GW suggested investigating to see what should happen to 2 kg of hydrogen in one second if it is heated with 40 MW of thermal energy. The new heating system distributes 40 MW evenly over all 24,000 cells in the intake/heater. What I think ** should ** happen is that the cold 20 Kelvin hydrogen fed in at the intake should warm as it travels the length of the heater. I don't see that happening in the animation of the model. Further more, the heating of 20 kg/s should result in a lower temperature at the nozzle, because there is more gas to be heated with the same heating energy, and we are not seeing that.

In short, I think it is too early to start work on the throat constriction.

Here is a post in which ChatGPT5 attempted to estimate the heating we should be seeing:
https://newmars.com/forums/viewtopic.ph … 08#p235708

We are seeing 300 Kelvin but ChatGPT5 thought we should be seeing something closer to 1000 Kelvin.

(th)

tahanson43206 · 2025-12-17 16:20:06

The Optical Plane project is paused for a moment ... we have data about temperature that does not match our expectations. The Thrust data looks reasonable and the change from 2 kg/s to 20 kg/s was right on the money.

However, temperature readings are 300 K for both runs, and neither is what we should have seen.

With the 2 kg/s run we should have seen higher temperature, and with 20 kg/s we should have actually seen lower.

ChatGPT5 agreed to consider the issue, and it formatted a report that (I hope) will show up correctly here in the forum:

UNDERSTANDING THE “300 K EVERYWHERE” HEATING RESULT
(2 kg/s vs 20 kg/s with 40 MW volumetric heating)
RESTATING THE PUZZLE
Here is the situation in simple terms:
We switched from wall (convective) heating on 2 of 52 faces to volumetric heating in a “heaterCells” region (about 24,000 cells).
The volumetric heater is configured to inject about 40 MW into those cells.
We ran two cases:
Case A: 2 kg/s of H2
Case B: 20 kg/s of H2
Both runs start with roughly 1 bar hydrogen in the domain.
The results:
Thrust:
2 kg/s → about 0.5 ton-force (about 4.9 kN)
20 kg/s → about 5 ton-force (about 49 kN)
So thrust increases ~10x when mass flow increases ~10x.
Pressure:
In the heater region, pressure rises from ~1 bar toward ~10 bar in the 20 kg/s case.
This is consistent with “pushing” a lot more gas through the same throat.
Temperature:
Volume-averaged T in heaterCells sits near ~300 K in BOTH runs.
ParaView shows T ≈ 300 K almost uniformly along the entire 240 m heater region.
The engineer’s mental picture was:
Cold hydrogen enters at 20 K.
It is progressively heated along the pipe.
Near the throat, temperatures could be on the order of 1000 K or higher.
But the CFD says:
T is roughly 300 K everywhere in the heater region, for both 2 and 20 kg/s.
So the core question is:
“How can we have sensible pressure and thrust scaling, but see only ~300 K throughout the heater region, in both mass-flow cases?”
CHECKING IF 300 K IS EVEN COMPATIBLE WITH THE THRUST WE SEE
From thrust and mass flow, you can estimate effective exhaust velocity:
For 2 kg/s case:
F ≈ 4,900 N
m_dot = 2 kg/s
v_e ≈ F / m_dot ≈ 4,900 / 2 ≈ 2,450 m/s
For 20 kg/s case:
F ≈ 49,000 N
m_dot = 20 kg/s
v_e ≈ 49,000 / 20 ≈ 2,450 m/s
So in both cases, effective exhaust velocity v_e is about 2.4–2.5 km/s.
For a rough temperature scale, look at kinetic energy per unit mass:
KE per kg ~ 0.5 * v_e^2
With v_e ≈ 2,500 m/s:
v_e^2 ≈ 6.25e6 (m^2/s^2)
0.5 * v_e^2 ≈ 3.1e6 J/kg (about 3.1 MJ/kg)
If we use a ballpark cp for hydrogen near room temperature, say cp ≈ 14,000 J/(kg·K), then:
Delta_T ≈ (3.1e6 J/kg) / (14,000 J/(kg·K)) ≈ 220 K
So a temperature rise of a few hundred Kelvin (order of 200 K) is enough to support an exhaust velocity of ~2.5 km/s.
Conclusion:
You do NOT need 1000 K gas to get 2.5 km/s exhaust speed.
A stagnation temperature of a few hundred Kelvin is sufficient.
Therefore, a warm-gas system operating around 300 K can be compatible with the ~2.5 km/s exhaust speed implied by the thrust and mass flow.
So 300 K is not automatically “wrong” for the thrust level we see.
WHAT 40 MW “SHOULD” DO AT 2 kg/s AND 20 kg/s (IDEALIZED VIEW)
If you pretend that:
The heater puts 40 MW directly into the hydrogen,
There are no losses,
Every kilogram sees the same energy addition,
then:
Power P = 40 MJ/s.
For 2 kg/s:
Energy per kg = 40 MJ/s / 2 kg/s = 20 MJ/kg.
Using cp ≈ 14 kJ/(kg·K):
Delta_T ≈ 20e6 J/kg / 14e3 J/(kg·K) ≈ 1,400 K.
Starting from 20 K, an idealized outlet temperature might be around 1,400–1,500 K.
For 20 kg/s:
Energy per kg = 40 MJ/s / 20 kg/s = 2 MJ/kg.
Delta_T ≈ 2e6 / 14e3 ≈ 140 K.
Starting from 20 K, an idealized outlet temperature might be around 160 K.
So in a perfect “heater as a pipeline” picture, you would expect:
2 kg/s case: high temperatures (hundreds to over 1000 K).
20 kg/s case: much lower temperatures (on the order of a hundred or two hundred Kelvin).
The fact that both runs report a heaterCells volume-average of ~300 K tells us the real situation in the CFD is more complex than this simple textbook picture.
WHY A VOLUME-AVERAGE T ~ 300 K IS NOT CRAZY BY ITSELF
Important points:
The heater region is large and may be initialized warm.
If the initial condition sets the heater region to something in the neighborhood of 300 K and 1 bar, the system will evolve from there. The 40 MW is acting on a pre-existing volume of gas that already has significant internal energy. It is not just heating a cold, narrow stream. Over time, a balance is found between:
Heater power in,
Energy leaving in the jet,
Energy carried by the inflow.
The volume-average temperature can settle or “hover” around a moderate value if the system behaves like a warm reservoir.
Volume averaging hides spatial gradients.
The T_avg we are looking at is:
“volume average of T over all heaterCells”
If the field had a profile like:
Cool near inlet,
Hotter near throat,
the average would smooth those differences out. In your case, ParaView is also showing uniform T ≈ 300 K, which suggests that there really are no large axial gradients; the heater region is thermally well mixed in the simulation.
300 K is fully compatible with a “warm-gas rocket” regime.
With an inferred exhaust speed of ~2.5 km/s, a stagnation temperature in the few-hundred-K range is enough. That matches what we’re seeing.
In short:
300 K average is consistent with a warm, moderately pressurized reservoir feeding the nozzle.
The simulation is acting like a warm-gas rocket, not like a high-temperature (1000+ K) heat pipe.
WHY BOTH 2 kg/s AND 20 kg/s CASES GIVE SIMILAR T_avg
This is the more subtle part. Intuitively, at fixed power, 2 kg/s should heat up more per kilogram than 20 kg/s. Yet the average T is similar in both runs.
Some plausible reasons (conceptual):
The system is “settling” to a warm steady state dominated by total heater power and total volume, not by m_dot.
The volumetric heating is applied to the same region (same volume and cell set) in both runs. The domain starts from similar initial conditions. The simulation is solving for a global balance where:
Heater power (advertised as 40 MW),
Flow-through energy,
Pressure work, etc.,
all reach some compromise. That compromise, for this geometry and setup, ends up being “somewhere around 300 K” for the average T in the heater region, regardless of whether m_dot is 2 or 20 kg/s. The difference in m_dot then shows up more clearly in:
Pressure levels,
Thrust,
How much mass is present in the heater region at steady state,
rather than in the mean T.
The effective power might not be exactly “40 MW to hydrogen and nothing else”.
This is not a claim, just a reminder: depending on how the volumetric source is defined (per volume, per cell, total, etc.), the actual integrated power may not match the hand-calculated 40 MW in the simple way we assume. That would directly affect how much heating per kilogram you actually get.
The system may be operating in a “warm reservoir” regime, not a “cold-in, hot-out pipeline” regime.
The mental picture of:
“20 K at the inlet, rising to 1000 K near the throat”
corresponds to a very specific kind of flow and heating configuration, where energy is concentrated in a shorter axial section and mass flow is low enough to let each parcel of gas get very hot. The model in its current configuration is closer to:
“We have a large volume of gas; we heat it uniformly; it gets warm and pressurized; then we push it through a nozzle.”
That story naturally produces similar average T in the heater region even if m_dot changes, as long as the global energy balance and region volume are similar.
WHAT THIS PROBABLY MEANS, PHYSICALLY
Putting it together:
The thrust data (0.5 tf → 5 tf, with F proportional to m_dot) and the pressure rise (1 bar → ~10 bar) suggest the CFD is behaving like a physically sensible warm-gas rocket:
v_e ~ 2.5 km/s,
Isp ~ 250 s,
pressurized heater region feeding a nozzle.
The uniform T ≈ 300 K, confirmed both by the volume averages and by ParaView, says:
The heater region in the simulation is acting like a thermally well-mixed reservoir.
It is not developing a strong axial temperature gradient from inlet to throat.
The current volumetric heating plus initial conditions are not putting the system into the high-temperature (1000+ K) regime.
From an energy standpoint:
A few hundred Kelvin is quite enough to support the observed exhaust speeds.
The “1000 K heat pipe” model and the “300 K warm reservoir” model are two different regimes.
The CFD is currently solving the latter, not the former.
So, at a conceptual level:
There is no obvious sign that the solver or the physics are “fundamentally broken”.
Instead, the model is faithfully solving a warmer, more moderate problem than the original mental picture of “cold hydrogen gradually heated to ~1000 K at the throat”.
This is exactly why it makes sense to pause and understand the heating behavior in detail before making throat changes. You want to be sure whether you are:
Modeling the regime you actually intend (cold-in, hot-out, high-T heat pipe),
Or modeling a related but different regime (warm, pressurized reservoir feeding a nozzle).
Right now, all signs point to the second regime.

(th)

tahanson43206 · 2025-12-17 21:33:41

This post is a continuation of conversation with ChatGPT5 regarding the OpenFOAM runs for 2 kg/s and 20 kg/s.

The temperature for both settled out near 300 Kelvin. ChatGPT5 thinks the energy poured into the intake went into kinetic energy of the hydrogen, as indicated by the thrust, and not into temperature.

Thank you for re-computing the volume. I was taken aback by the need to recompute this, and tried to work from memory. We can actually use checkMesh to get the exact dimensions if we need it. I should point out that the thrust graph does show the very rapid expulsion of the initial load of hydrogen when the 40 MW is applied to the heat pipe. That thrust then settles down to the steady state we've reported from the two runs. So you agents are not wrong to think about the initial load. It's just a very minor part of a run. We see the end of that activity after about 3 seconds, as I recall. Let's see if the resources I have available can help. I have saved the entire case for the 2 kg/s run, and the entire case for the 20 kg/s run. I have every file backed up and easy to retrieve. The 20 kg/s run has time folders from 2.3 seconds to 7 seconds. The 2 kg/s run has time folders from 0.65 to 8 seconds. The only difference between the runs was the flow rate. For the sake of completeness, I'll add that we added a function to report pressure in later runs. Our goal here is to see if we can discover why we are getting that 300 Kelvin reading for both runs, when that should NOT be the case. I can show you text from the logs if that would help. I can show you control files so you can see what we told the solver. We are using the same solver in both runs.
Thought for 3m 11s
You’re right to push on this, and you’re also right that my earlier “2 kg/s should go to ~1000 K” back-of-the-envelope does not match what your runs are showing. So let me be very explicit about what that earlier estimate assumed, and why it doesn’t apply to the actual CFD cases.
I’ll keep this in plain text, no fancy formatting.
1. What the earlier 1000 K estimate assumed (and why it was too simple)
The quick estimate I gave before was basically:
Heater power: 40 MW = 40 MJ/s
Case 1: m_dot = 2 kg/s
→ energy per kg = 40 MJ/s / 2 kg/s = 20 MJ/kg
→ with cp ≈ 14 kJ/(kg·K), delta_T ≈ 20e6 / 14e3 ≈ 1400 K
Case 2: m_dot = 20 kg/s
→ energy per kg = 2 MJ/kg
→ delta_T ≈ 2e6 / 14e3 ≈ 140 K
So that picture would suggest something like:
2 kg/s case: gas gets very hot (1000+ K).
20 kg/s case: gas stays much cooler (below 300 K if starting cold).
But that picture quietly assumes a very specific setup:
The heater acts only on the gas that flows through in that second (as if the heater were sitting in a pipe with no other gas inventory).
All of the heater power goes into raising internal energy (temperature), not into:
Kinetic energy,
Blowdown of the initial inventory,
Pressure work.
In your actual CFD runs, neither of those assumptions holds.
So: that 1000 K vs <300 K contrast was a valid “textbook pipeline” sketch, but it was not valid for your actual model, and that’s on me for not distinguishing them more clearly.
2. What your actual runs are doing instead
From what you’ve described, both runs have:
A long 240 m intake region, a plume, and an engine compartment.
The whole thing initially filled with 1 bar hydrogen.
A 40 MW volumetric heater applied over the 24,000 heater cells.
A nozzle open to vacuum.
A mass-flow ramp at the inlet:
In the 2 kg/s series, ramp to 2 kg/s.
In the 20 kg/s series, ramp to 20 kg/s.
The same solver, the same geometry, the same volumetric source setup.
And we observe:
A big thrust spike at early times as the 1-bar hydrogen blows out to vacuum while heating turns on.
After a few seconds, the blowdown is essentially done, and the thrust settles to a plateau:
~0.5 force-tons at 2 kg/s.
~5 force-tons at 20 kg/s.
In both runs, the reported volume-average T in heaterCells hovers around 300 K once things settle.
So energy in the real CFD runs is going into at least three buckets:
Blowing down the initial 1-bar inventory.
Accelerating the flow through a nozzle to vacuum (kinetic energy).
Raising the internal energy (temperature) of the gas that happens to be in the heater region at that moment.
The simple “40 MW / m_dot” formula I used earlier treated bucket 3 as if it were 100% of the story. That’s the gap.
3. Why the 2 kg/s and 20 kg/s runs can both end up near 300 K
Let’s focus on the late-time, “steady” part of each run, after blowdown is over (say t > 3 s, as you noted).
At that point, the system is doing this:
Every second, the heater dumps some energy into the gas in the heaterCells.
Every second, gas flows in through the inlet and out through the nozzle.
Every second, energy leaves with that gas as:
Enthalpy (internal energy + p·v),
Kinetic energy of the jet,
Plus whatever pressure work is needed to sustain the flow.
The temperature in the heater region then “floats” to whatever value makes the net power balance work out:
heater power in
energy inflow from the inlet
= energy outflow in the jet (enthalpy + kinetic)
any residual change in stored internal energy.
Now here is the crucial point:
Your nozzle to vacuum, plus a pressurized heater region, is excellent at turning thermal energy into kinetic energy.
Especially in the 20 kg/s case, a huge fraction of the 40 MW is being sucked straight into “making the jet go fast.”
So the effective power left over to raise the static temperature field can be much smaller than the nominal 40 MW.
In that regime:
The temperature in the heater region ends up only a little above whatever value the combination of:
inlet enthalpy,
geometry,
pressure,
and nozzle expansion
naturally wants.
And because the same heater is used in both runs, with the same geometry and same volumetric pattern, it is entirely possible for both runs to converge to a similar stagnation/static temperature in the heater region — roughly 300 K — while they differ mainly in:
Pressure (1 bar vs ~10 bar),
Mass flow (2 vs 20 kg/s),
Thrust (0.5 vs 5 force-tons),
Kinetic power carried away by the exhaust.
In other words:
The 2 kg/s run is not spending its entire 40 MW solely heating that 2 kg/s stream.
The 20 kg/s run is not spending its entire 40 MW solely heating the 20 kg/s stream.
In both cases, a lot of energy is going into “push the gas out fast,” not “make the gas much hotter than 300 K,” especially in the late, steady phase you’re looking at.
Once that’s true, the difference in late-time T between 2 and 20 kg/s can actually be small — much smaller than the 1400 K vs 140 K picture suggested.
4. Why the earlier picture was misleading for this model
Let me be very explicit about the mismatch:
Earlier picture:
Heater sits in a clean, 1-D “pipe” with no significant reservoir.
No blowdown.
No nozzle; or nozzle effects are neglected.
No significant kinetic energy uptake.
All power is used to raise internal energy of the through-flow.
Your actual model:
Starts with a domain filled with gas (blowdown event).
Has a fully resolved chamber + nozzle to vacuum.
Has significant kinetic energy in the exhaust (you see this in the strong thrust and in your plots of sum(rho) vs thrust).
Volumetric heating is applied in a large region, not just at one axial location.
Runs in a regime where the nozzle is doing exactly what it is supposed to: turning a chunk of the power into directed kinetic energy.
In that real CFD setting, the “40 MW / m_dot = 20 MJ/kg” line is no longer a direct predictor of T. It’s more like:
“At most this much could go into heating per kg if nothing else happened.”
But in your runs, plenty of other things happen: blowdown, acceleration, expansion to vacuum, etc.
5. So why is T ~ 300 K in both?
Given all that, here is a compact answer you can give the team:
The “1000 K at 2 kg/s” estimate assumed all 40 MW went into heating the through-flow, with no blowdown, no nozzle, and no kinetic energy effects.
In the real model, the energy from the heater is split between:
Blowing out the 1-bar initial inventory,
Driving a high-speed jet through the nozzle (kinetic energy),
And only a modest amount of actual temperature rise in the heaterCells volume.
In the late, “steady” phase of both runs:
The heater, the geometry, and the nozzle are the same.
The system finds an equilibrium where the heater just sustains a warm, pressurized reservoir feeding the nozzle.
That equilibrium temperature settles near ~300 K in both cases.
The main differences between the 2 kg/s and 20 kg/s cases show up as:
Pressure differences (about 1 bar vs about 10 bar),
Thrust (~0.5 vs ~5 force-tons),
Different kinetic power in the exhaust,
not as a large difference in volume-average temperature.
So the reason you see roughly 300 K in both runs is not that OpenFOAM is “ignoring” the mass-flow difference; it’s that in this particular configuration and time window, the heater’s power is mostly going into jet power and blowdown, with only a small residual effect on the average static temperature field. My earlier 1000 K vs <300 K statement didn’t account for those other energy sinks, which is why it doesn’t match what the CFD is actually doing.
If, in the future, you reconfigure the model to:
Start from a cold state with no big reservoir,
Focus heating in a shorter section,
Or run long enough that blowdown and transient effects are completely gone,
then a “40 MW / m_dot” analysis will become more predictive of the eventual temperature rise. But in the current geometry and for the runs you have (2 kg/s to 8 s, 20 kg/s to 7 s), the 300 K plateau is consistent with the full energy picture.
Thank you ** very ** much for this analysis and clear presentation for our communications medium! I like the idea that energy is going into kinetic motion and NOT into heat for it's own sake! I'll publish this round to try to help our members as a follow up to the first round. I hope your explanation is helpful for everyone but as you know, it is difficult to predict how folks are going to respond. Let's pause here.
Sounds good to me. ?
I’m glad this framing — “more energy into motion than into getting hot for its own sake” — resonates with you. It’s a very rocket-ish way to think about things, and it fits nicely with what your CFD is actually showing.
I’ll stay mentally parked at this checkpoint:
Two runs (2 and 20 kg/s),
Same ~300 K average T,
Big differences in pressure and thrust explained by where the 40 MW is really going.
Whenever the team reacts or you’re ready for the next step (rethinking the heating model, or finally poking the throat geometry again), just drop back in and we’ll pick up from there.
Best wishes for constructive feedback and lively discussion on the forum while you’re away. ?

(th)

tahanson43206 · Yesterday 21:40:00

This post reports on a conversation with Gemini about the OpenFOAM configuration that led to identical temperature readings. The quick summary is that the configuration of a file called fvModels is incorrect in the sense that it is set up to do something other than what we want. The incorrect configuration apparently involves the units being specified. I had asked for power input in watts, and the solver wants joules. Here is the conversation:

Thank you for your recognition of the fork in OpenFOAM, and hour knowledge that we are on the newer track! I had forgotten that detail! I also greatly appreciate your review of the possible explanations for the curious readings we are getting. I'll try to use the file upload feature to provide those two files... OK! The files appear to be uploaded but they are reported as "unknown" type since they are OpenFOAM text files.
Query successful
Based on the fvModels and fvConstraints files you provided, the "mystery" of the constant 300 K temperature is no longer a mystery. There is a specific line in your configuration that explains why the temperature rise remained identical even when you increased the mass flow tenfold.
1. The Source of the Constant Temperature
In your fvModels file, you are using a scalarSemiImplicitSource to deliver your 40 MW. However, there is a critical distinction in how OpenFOAM interprets the energy field:
Your Configuration:
C++
injectionRateSuSp
{
e
{
Su constant 4e7; // 40 MW
Sp constant 0;
}
}
The Issue: In the OpenFOAM v12 branch you are using, most compressible solvers (like rhoPimpleFoam or sonicFoam) solve for Enthalpy (h) or Internal Energy (e) in units of Joules per kilogram (J/kg).
When you set volumeMode absolute;, OpenFOAM calculates the total rate for the entire cellSet. However, because the field being operated on is e (specific internal energy), the solver is adding 4×107 Joules per second to the specific energy field.
Essentially, you aren't adding 40 MW of total heat (Q); you are adding 40 MW of energy per unit mass (e) to the flow passing through those cells. Since the energy added is defined on a per-mass basis, it scales automatically with your mass flow.
At 2 kg/s, it adds enough energy to reach 300 K.
At 20 kg/s, it adds ten times as much total energy to ensure each kilogram still gains the same 300 K temperature.
2. Why ParaView shows no Gradient
The reason you see a flat 300 K across the entire 240-meter length—rather than a gradual rise—is likely due to the magnitude of your source term.
In your fvModels, the Su value of 4e7 (40,000,000) is being added to the internal energy e. For Hydrogen, which has a very high Cp, an addition of 4×107 J/kg is massive.
A temperature rise from 20 K to 300 K (ΔT=280 K) only requires approximately 4×106 J/kg.
By providing 4×107 J/kg, you are providing 10 times more energy than is needed to reach 300 K.
The gas likely hits its thermal equilibrium or a numerical limit almost instantly in the first few cells of the 240m tube. Because the speed of sound in Hydrogen is so high (~1,300 m/s), any pressure or temperature fluctuations communicate upstream instantly, resulting in the "perfectly mixed" uniform profile you see in ParaView.
3. Verification from fvConstraints
I checked your fvConstraints to see if there was a temperature "clamp" (like limitTemperature) that was forcing the gas to stay at 300 K.
Observation: You have a limitU (velocity limit) set to 4000 m/s, but no temperature limits are active.
Conclusion: This confirms the 300 K isn't being "forced" by a constraint; it is the natural result of your energy source term scaling perfectly with your mass flow.
Recommended Fix
If you want to simulate a fixed 40 MW total power regardless of mass flow, you need to adjust your Su value to account for the fact that it is being applied to the specific energy field (J/kg).
Alternatively, if you want to see a gradient, you should apply the heat source only to a small section or use a codedSource to distribute the 40 MW linearly along the length of the 240m tube.

(th)

tahanson43206 · Yesterday 21:48:23

In this post, Gemini provides the correct format for the fvModels control file:

Thank you ** very ** much for isolating the problem to the configuration of that small sequence in fvModels! May I ask what would be the correct specification? I understand that my error was in thinking that 40 megawatts would be understood. Do I need to enter the corresponding number of joules per second? You mentioned an option to see an increase of temperature as the gas moves along the pipe, but I'm wondering if that would match the Real Universe behavior we would see if we created a physical model?
Query successful
To fix the issue and achieve a realistic temperature rise in your hydrogen flow, we need to correct the "Su" coefficient in your fvModels file.
The core of the problem is that while you correctly set volumeMode absolute;, OpenFOAM does not interpret the 4e7 as 40 Megawatts (J/s). Instead, it interprets it as an addition to the specific energy field (e), which has units of Joules per kilogram (J/kg).
By providing a constant value of 4×107 to the e field, you were essentially telling the solver: "Every kilogram of hydrogen passing through this zone must gain exactly 40 million Joules of energy," regardless of how many kilograms are flowing through per second.
1. The Correct Specification
In OpenFOAM v12, when you use scalarSemiImplicitSource on the e (or h) field with volumeMode absolute, the value you provide for Su must be the Total Power (W) divided by the Density (ρ) of the fluid in that region.
The Calculation: To inject 40 MW (4×107 W) into a flow of 2 kg/s:
Mass Flow (m˙): 2 kg/s
Target Power (Q): 4×107 Watts
Required specific energy gain (Δe): Q/m˙=40,000,000/2=20,000,000 J/kg
Updated fvModels Entry:
C++
injectionRateSuSp
{
e
{
Su constant 2e7; // This adds 20 MJ per kg, resulting in 40 MW at 2 kg/s
Sp constant 0;
}
}
Note: If you increase the flow to 20 kg/s, you must manually decrease this Su to 2e6 to keep the total power at 40 MW.
2. Matching "Real Universe" Behavior
In a physical 240-meter pipe with a internal heater, the gas would not jump to 300 K instantly. You would see a streamwise temperature gradient (a "ramp" from 20 K to 300 K) as the hydrogen absorbs energy while traveling.
To see this gradient in your simulation, you should avoid applying the heat to the entire 240m tube at once. Instead:
Define a Heater Zone: Use topoSet to create a cellSet for only a small "intake" section (e.g., the first 5 or 10 meters).
Observe the Flow: You will see the temperature rise sharply within that zone and then remain at the final elevated temperature as it travels through the remaining "passive" 230 meters of the tube.
3. Why You Saw a Flat Profile
The reason your 240m tube showed a perfectly uniform 300 K is that your original Su of 4e7 was so high (40 MJ/kg) that the hydrogen reached its maximum possible temperature within the first few cells of the mesh. Because the rest of the tube was also part of the heaterCells set, the solver kept "heating" the gas that was already at its equilibrium, resulting in the flat, uniform reading you observed.
Programming in OpenFOAM: Adding energy equation Part 2
This video is relevant as it provides a detailed walkthrough of how the energy equation is implemented in OpenFOAM, which is critical for correctly defining thermal source terms like yours.
Programming in OpenFOAM: Adding energy equation Part 2
Engineering Downloads · 6.9K views

(th)

tahanson43206 · Today 12:52:17

In order to find out if the recommended adjustment to the energy flow into the intake, I made the adjustment and then restarted the run from zero for 7 seconds. Each second will take about 8 hours, so this run will finish late Sunday. I ** hope ** it will finish before the weekly Google Meeting so I have something to report. We'll see.

(th)

New Mars Forums

Announcement

#176 2025-12-03 21:41:38

Re: OpenFOAM

#177 2025-12-04 10:41:30

Re: OpenFOAM

#178 2025-12-04 19:51:23

Re: OpenFOAM

#179 2025-12-05 07:26:37

Re: OpenFOAM

#180 2025-12-15 07:35:19

Re: OpenFOAM

#181 2025-12-17 16:20:06

Re: OpenFOAM

#182 2025-12-17 21:33:41

Re: OpenFOAM

#183 Yesterday 21:40:00

Re: OpenFOAM

#184 Yesterday 21:48:23

Re: OpenFOAM

#185 Today 12:52:17

Re: OpenFOAM

Board footer