You are not logged in.
ChatGPT5 and I have agreed to fall back to Version 122. We are resuming work with the new Version 126.
The versions 123, 124 and 125 gave ChatGPT5 the opportunity to try to create a "fixit" patch to the existing program. Unfortunately, each attempt only made things worse. In response, we developed a new utility program. I led the initiative, and ChatGPT5 did the work, until the program appears to be working. Here is output that (we think) describes the new cell #13875 that sits on top of cell #0 of the old mesh. I have physical models of both cells, so I can rotate them and line them up with each other. The points at the corners of the faces line up (to the extent I've checked them) so I think the physical model is probably correct.
python3 probe_facesV06.py --cell 13875
cell 13875: six faces (X-/X+/Y-/Y+/Z-/Z+)
Face X- id=55816 kind=boundary
patch=frontAndBackPlanes
file=faces line0=55835 line1=55836
owner=13875 neighbour=None
owned-by-cell=yes
center=(-0.650, 0.192, 0.000)
bbox.x=[-0.650, -0.650]
bbox.y=[0.184, 0.200]
bbox.z=[-0.063, 0.063]
points:
p28428: (-0.650, 0.184, 0.063)
p28430: (-0.650, 0.200, 0.063)
p28431: (-0.650, 0.200, -0.063)
p28429: (-0.650, 0.184, -0.063)
Face X+ id=27460 kind=internal
patch=internal
file=faces line0=27479 line1=27480
owner=0 neighbour=13875
owned-by-cell=no
center=(-0.400, 0.192, 0.000)
bbox.x=[-0.400, -0.400]
bbox.y=[0.184, 0.200]
bbox.z=[-0.063, 0.063]
points:
p14117: (-0.400, 0.184, 0.063)
p13563: (-0.400, 0.200, 0.063)
p27753: (-0.400, 0.200, -0.063)
p28307: (-0.400, 0.184, -0.063)
Face Y- id=55814 kind=boundary
patch=frontAndBackPlanes
file=faces line0=55833 line1=55834
owner=13875 neighbour=None
owned-by-cell=yes
center=(-0.525, 0.184, 0.000)
bbox.x=[-0.650, -0.400]
bbox.y=[0.184, 0.184]
bbox.z=[-0.063, 0.063]
points:
p14117: (-0.400, 0.184, 0.063)
p28307: (-0.400, 0.184, -0.063)
p28429: (-0.650, 0.184, -0.063)
p28428: (-0.650, 0.184, 0.063)
Face Y+ id=55815 kind=boundary
patch=frontAndBackPlanes
file=faces line0=55834 line1=55835
owner=13875 neighbour=None
owned-by-cell=yes
center=(-0.525, 0.200, 0.000)
bbox.x=[-0.650, -0.400]
bbox.y=[0.200, 0.200]
bbox.z=[-0.063, 0.063]
points:
p28431: (-0.650, 0.200, -0.063)
p28430: (-0.650, 0.200, 0.063)
p13563: (-0.400, 0.200, 0.063)
p27753: (-0.400, 0.200, -0.063)
Face Z- id=55818 kind=boundary
patch=frontAndBackPlanes
file=faces line0=55837 line1=55838
owner=13875 neighbour=None
owned-by-cell=yes
center=(-0.525, 0.192, -0.063)
bbox.x=[-0.650, -0.400]
bbox.y=[0.184, 0.200]
bbox.z=[-0.063, -0.063]
points:
p28429: (-0.650, 0.184, -0.063)
p28431: (-0.650, 0.200, -0.063)
p27753: (-0.400, 0.200, -0.063)
p28307: (-0.400, 0.184, -0.063)
Face Z+ id=55817 kind=boundary
patch=frontAndBackPlanes
file=faces line0=55836 line1=55837
owner=13875 neighbour=None
owned-by-cell=yes
center=(-0.525, 0.192, 0.063)
bbox.x=[-0.650, -0.400]
bbox.y=[0.184, 0.200]
bbox.z=[0.063, 0.063]
points:
p28430: (-0.650, 0.200, 0.063)
p28428: (-0.650, 0.184, 0.063)
p14117: (-0.400, 0.184, 0.063)
p13563: (-0.400, 0.200, 0.063)
(th)
Offline
Like button can go here
This post is about a consultation with Google's Gemini about the five month attempt to add a new layer of 25 cells to an existing mesh.
What is startling about this conversation is that Gemini instantly suggested an existing tool designed to extrude an existing mesh. I had (obviously) never heard of this tool and (equally obviously) neither had ChatGPT5.
ChatGPT and Gemini have been competing, and in the early going ChatGPT was far advanced. However, in recent times, I am seeing Gemini as equal or possibly better. On the other hand, I gave this problem to Gemini without any pre-existing baggage, so perhaps it was able to match the problem to the solution more easliy that might be the case for ChatGPT, which is bogged down by five months of history as we worked on this problem.
Conversation with Gemini
OpenFOAM mesh extension - hello again! A friend and i have been trying to add a layer of cells to an OpenFOAM mesh. The existing mesh passes checkMesh with no errors. In our effort to add faces to the existing mesh, we are passing muster for some aspects of the new mesh, but checkMesh is reporting problems and we are wondering if there might be some guidance on how to do this? We have been trying to puzzle out the procedure, and seem to have made some progress, because checkMesh reports seeing the new cells. The issue of greatest interest is how to handle the existing boundary layer. One team member things the correct procedure is to convert the existing boundary faces to internal, and add them to the neighbour file. In the course of doing this, we seem to be changing the id of the faces. I am wondering if this is correct? My friend's argument seems reasonable. If we are adding these faces to the neighbour file, then the id of those faces must be changed to match the position in the neighbour file instead of the current position in the owner file. It seems to me the owner, neighbour and faces file are being disrupted, which may be why checkMesh is reporting problems with our new cells. Are you aware of guidance that may exist for how to do this correctly?
***Hello! Handling the mesh files directly to add a layer of cells is complex and prone to errors, as you've discovered. Your friend's idea about converting boundary faces to internal is a valid part of the process, but the entire procedure is intricate and requires careful management of multiple files. The face IDs, especially in the owner and neighbour files, are crucial and must be consistent. Manually editing these files can easily lead to a corrupted mesh.
The core issue is that when you add new cells, you are not just adding to the end of the lists; you are fundamentally changing the geometric and topological relationships between all the elements. The existing faces that were on a boundary must indeed be converted to internal faces. This means they must be assigned an owner and a neighbour cell. The original boundary patch entries for these faces must also be removed.
A much safer and more reliable approach than manually editing the mesh files is to use OpenFOAM's built-in utilities. The most common tool for this type of operation is extrudeMesh. This utility is specifically designed to extrude an existing 2D surface mesh into a 3D volume mesh or to add layers of cells to an existing 3D mesh.
Using extrudeMesh
Prepare the Surface: Identify the faces on your existing mesh where you want to add the new cells. This surface, or patch, will be the 'source' for the extrusion.Create the extrudeMeshDict: You'll need to create a dictionary file, extrudeMeshDict, in the system directory of your case. This file specifies the patch to extrude, the number of layers, and the extrusion direction and distance.
Run the Utility: Execute extrudeMesh from the command line within your case directory. The utility will handle the complex mesh manipulation for you, including:
Creating new cell and face entries.
Updating the owner and neighbour files for the newly created internal faces.
Correctly re-indexing all affected faces and cells.
Handling the new boundary patches that are created on the 'other' side of the new layers.
Using extrudeMesh avoids the manual errors you're encountering, such as incorrect face IDs or disrupted topological data. It's the standard, supported method for this task within the OpenFOAM community.
Why Manual Editing Fails
Your team is correct in identifying that the owner, neighbour, and faces files are the source of the issues. The face IDs are not arbitrary; they correspond to the line number in the faces file. The owner file's entries are a direct lookup for the owner cell of each face, and the neighbour file does the same for the neighbour cell (for internal faces only).
When you convert a boundary face to an internal face, you are correct that it needs to be added to the neighbour file. However, this is just one piece of the puzzle. You also need to:
Correctly append the new cells to the end of the points, faces, and cells lists.
Update all face-to-cell references in the owner and neighbour files to account for the new cells.
Ensure that the new face IDs and their corresponding owner/neighbour relationships are all in perfect sync.
This is an extremely tedious and error-prone process. The change in a single ID can lead to a cascade of errors, which is likely why checkMesh is reporting problems. checkMesh is highly sensitive to the topological consistency of the mesh, and even a minor mismatch will be flagged.
I strongly recommend using extrudeMesh as it is designed for exactly this purpose and will ensure the topological integrity of your mesh.
***Thank you for this inspiring suggestion! Somehow we've never heard of this tool, but it sounds perfect for our application. We've spent 5 months building a python script to perform all these operations, and it is discouraging to have checkMesh complain when we finally seem close to the goal line. That said, if there is an existing tool that has been debugged by other generous volunteers, we will accept the gift with appreciation!
***That's a very common experience in the OpenFOAM community! It's great that you're embracing the challenge, but it's even better when you can leverage a tool that's already built for the task. It's a testament to the community's collaborative spirit.
The Challenge of Manual Mesh Manipulation
Your experience with your Python script highlights a key challenge with OpenFOAM mesh files: they're not simple text files you can just edit. They represent a complex, interconnected topology. The owner and neighbour files, in particular, are structured to be extremely efficient for the solver. The ID of a face in the faces file must exactly match its position in the owner and neighbour files. When you manually insert or move things, it's very easy for a mismatch to occur, even by one number. Your team's intuition about the IDs being disrupted is exactly right. The checkMesh utility is a strict enforcer of this topological integrity, and it's doing its job by flagging these inconsistencies.
Why extrudeMesh is Your Best Friend
The extrudeMesh utility is a powerful tool because it understands all these internal relationships. Instead of you writing a script to manually modify the mesh files, extrudeMesh reads the existing files, understands the topology of the selected boundary patch, and then mathematically and topologically creates the new layers. It handles all the complex tasks:
Creates New Points and Faces: It generates the coordinates for the new points and defines the new faces connecting them.
Updates Connectivity: This is the most critical part. It correctly assigns owner and neighbour cells for the new internal faces and updates the existing boundary faces to become internal.
Maintains Consistency: It ensures that every new face has a corresponding entry in the owner and neighbour files, and that all IDs are correctly indexed.
Think of it this way: your Python script is like building a car by manually welding every single piece. extrudeMesh, on the other hand, is like using an automated assembly line that has been perfected over many iterations to build the car with precision every time.
By switching to extrudeMesh, you're not abandoning your work; you're just using a more efficient and reliable tool to get past the finish line. ?
***Again, thank you ** very ** much for this helpful advice! In our struggle with the challenge of trying to extrude the mesh, we have learned a great deal about the existing mesh, about OpenFOAM procedures and tools, and (of course) a great deal about Python. I will report your advice to our team immediately.
***I'm glad I could help! That's the perfect attitude to have. The knowledge and skills you've gained from building the Python script will be incredibly valuable for future projects, even if you don't use the script itself for this specific task. Understanding the internal structure of the mesh files is a key part of becoming an advanced OpenFOAM user.
Your team will now be able to move forward more efficiently and focus on the physics of your simulation, which is the ultimate goal. Good luck with the project!
(th)
Offline
Like button can go here
Given the tip from Gemini, ChatGPT5 and I investigated using the extrudeMesh program from the OpenFOAM library, and after a bit of a tussle figuring out the undocummented commands, we seem to have succeeded in running the procedure, with an unexpected result. The procedure created the new layer, and it kept the layer from the old mesh, but it discarded the rest of the Merlin engine. Never-the-less, I am happy to see the checkMesh OK at the end of this report.
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 : Sep 18 2025
Time : 21:56:12
Host : "tom-GA-78LMT-01"
PID : 733071
I/O : uncollated
Case : /home/tahanson/PythonOpenFOAM
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 Warning :
From function static Foam::instantList Foam::timeSelector::select0(Foam::Time&, const Foam::argList&)
in file db/Time/timeSelector.C at line 269
No time specified or available, selecting 'constant'
Create polyMesh for time = constantTime = constant
Mesh stats
points: 104
internal points: 0
faces: 126
internal faces: 24
cells: 25
faces per cell: 6
boundary patches: 6
point zones: 0
face zones: 0
cell zones: 0Overall number of cells of each type:
hexahedra: 25
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
wallSection 2 8 ok (non-closed singly connected)
inlet 25 52 ok (non-closed singly connected)
outlet-1 0 0 ok (empty)
outlet-2 0 0 ok (empty)
frontAndBackPlanes 50 104 ok (non-closed singly connected)
inletExtension 25 52 ok (non-closed singly connected)Checking geometry...
Overall domain bounding box (-0.65 -0.2 -0.0630365) (-0.4 0.2 0.0630365)
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 = 0 OK.
Max aspect ratio = 15.625 OK.
Minimum face area = 0.00201717. Maximum face area = 0.0315182. Face area magnitudes OK.
Min volume = 0.000504292. Max volume = 0.000504292. Total volume = 0.0126073. Cell volumes OK.
Mesh non-orthogonality Max: 0 average: 0
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 1.11022e-15 OK.
Coupled point location match (average 0) OK.Mesh OK.
End
I'll be working with ChatGPT5 to see if we can (somehow?) persuade the extrudeMesh program to include the rest of the mesh.
Update: The difference between the run show above and the full run was a single parameter.
The parameter "patch" was replaced with the parameter "mesh" and the new layer was added to the existing mesh. The counts look right and checkMesh is happy. My plan is to spend a day or so studying the "one layer" extension, before we try to add the full 240 meters of the heating tube extension.
(th)
Offline
Like button can go here
This post is to report that the 240 meter extension to the Merlin engine appears to have been created.
The project will now move on to heating the pipe. This project is part of the Optical Plane ship project, which has it's own topic.
Create time
Create polyMesh for time = constant
Enabling all (cell, face, edge, point) topology checks.
Enabling all geometry checks.
Time = constant
Mesh stats
points: 78300
internal points: 0
edges: 193198
internal edges: 36602
internal edges using one boundary point: 0
internal edges using two boundary points: 36602
faces: 152774
internal faces: 74476
cells: 37875 << up from 13875 cells
faces per cell: 6
boundary patches: 6
point zones: 0
face zones: 0
cell zones: 0Overall number of cells of each type:
hexahedra: 37875
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.
Topological cell zip-up check OK.
Face-face connectivity OK.
Number of regions: 1 (OK).Checking patch topology for multiply connected surfaces...
Patch Faces Points Surface topology
wallSection 2374 4756 ok (non-closed singly connected)
inlet 25 52 ok (non-closed singly connected)
outlet-1 60 124 ok (non-closed singly connected)
outlet-2 89 180 ok (non-closed singly connected)
frontAndBackPlanes 75750 78300 ok (non-closed singly connected)
inletExtension 0 0 ok (empty)Checking geometry...
Overall domain bounding box (-240.4 -1.62604 -0.0630365) (5 1.62604 0.0630365)
Patch bounding boxes
wallSection (-240.4 -1.62604 -0.0630365) (5 1.62604 0.0630365)
inlet (-240.4 -0.2 -0.0630365) (-240.4 0.2 0.0630365)
outlet-1 (-7.47209e-27 -1.62604 -0.0630365) (1.83697e-16 1.62604 0.0630365)
outlet-2 (5 -1.62604 -0.0630365) (5 1.62604 0.0630365)
frontAndBackPlanes (-240.4 -1.62604 -0.0630365) (5 1.62604 0.0630365)
inletExtension
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 = 2.2523e-16 OK.
Max aspect ratio = 15.625 OK.
Minimum face area = 0.000176457. Maximum face area = 0.0315183. Face area magnitudes OK.
Min volume = 2.22464e-05. Max volume = 0.000504292. Total volume = 14.1688. Cell volumes OK.
Mesh non-orthogonality Max: 31.8506 average: 3.54671
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.926237 OK.
Coupled point location match (average 0) OK.
Face tets OK.
Min/max edge length = 0.00499976 0.25 OK.
All angles in faces OK.
Face flatness (1 = flat, 0 = butterfly) : min = 1 average = 1
All face flatness OK.
Cell determinant (wellposedness) : minimum: 0.0365625 average: 1.50504
Cell determinant check OK.
Concave cell check OK.
Face interpolation weight : minimum: 0.0840609 average: 0.498724
Face interpolation weight check OK.
Face volume ratio : minimum: 0.0917429 average: 0.995626
Face volume ratio check OK.Mesh OK.
End
extrudeMesh did not use the new patch we set up, and instead simply extended existing patches.
(th)
Offline
Like button can go here
This is a follow up on Post #104...
We appear to have extruded the heat pipe all 240 meters, and this afternoon ChatGPT5 and I worked on setting up the heat simulation.
This is going to work a bit differently than the physical engine. The heat will only be injected through the Y faces, because Z is off limits due to the way OpenFOAM (and all CFD applications) deal with simulating a 3D system in a 2D space. However, I don't think that is a problem. All we have to do is to inject heat at the rate that corresponds to the physical pipe. ChatGPT5 ran a quick calculation, and came up with 43 MW as the grand total would would be feeding into the system, and that was based upon guesses for dimensions on my part.
The number of watts needed per Y face appears to be 28833 watts per face. I hope to learn tomorrow how to inject that heat at run time.
Here is how we wrapped up today:
This has been a most productive session today, and I need to take some time for other activities. Let's resume tomorrow to see what we need to do to make sure the heating will take place as we have planned. I'll also make sure to back up this case, because you've invested a ** lot ** of thought in creating it. While I'm away, best wishes for all possible success as you try to help everyone else!
ChatGPT said:That sounds like a perfect stopping point ?
You’ve locked in some major milestones today:
✅ extrudeMesh extension produced cleanly
✅ split off heatedWall (1,920 faces) from the nozzle walls
✅ verified with checkMesh — everything topologically sound
✅ derived a physically consistent wall heat flux (~7.1e5 W/m² → ~43 MW total)
Backing up this case is a great idea — you now have a solid baseline with heating capability ready to be activated.
I’ll be here when you’re ready to pick up tomorrow. We can go over:
double-checking the boundary conditions for 0/T, 0/U, and 0/p
running a short solver test to confirm energy is actually being deposited where we expect
planning the next steps for diagnostics (mass flow, temperature profiles, throat conditions)
Wishing you success with your other activities today — and thank you for the thoughtful collaboration. See you tomorrow! ?
(th)
Offline
Like button can go here
This post is to report on my discovery of a conversation with Gemini, five months ago, that set me on a long side journey to try to extend the Merlin Engine mesh with Python. Now, five months later, the much improved current version of Gemini told me about extrudeMesh, which is designed to do precisely what I wanted to do, and which delivered the completed mesh after just a few hours of learning how to use it.
The conversation reported here was primarily to refresh my memory on how to run a CFD solver. The setup of an OpenFOAM run environment is non-trivial, but Gemini was able to remind me of most of what is needed.
It is September of 2025. I probably asked the question about extending the mesh in April of 2025. I have spent the last five months attempting to extend the mesh using Python. We got close but checkMesh found errors in the mesh we created. Yesterday or the day before, I asked again, and this time your newer self informed me that OpenFOAM offers extrudeMesh. This is a powerful tool that extended the mesh after only a few hours learning how to use it. I regret that your earlier self did not know about extrudeMesh. Please note the conversation we had:
***
Hello! It sounds like you've navigated quite the journey with this inherited mesh. It's great to hear you've brought it back to life with modern OpenFOAM components! Extending the flange directly within the existing mesh is definitely a more elegant solution than introducing a separate mating part.Since OpenFOAM doesn't have a direct "extrude face" feature like Blender, we'll need to leverage its command-line tools and potentially some manual editing of the mesh files. Here's a suggestion for how you might proceed:
*** I understand you have made great progress in five months, I just wish you had known about extrudeMesh five months ago.
I sincerely apologize for the oversight in my previous response. It's clear that my earlier advice led you down a difficult and time-consuming path when a much more direct and powerful tool, extrudeMesh, was available. My capabilities have indeed evolved, and I now have a more comprehensive knowledge base, including the existence and functionality of specific OpenFOAM utilities like extrudeMesh.
I fully understand your frustration. The five months you spent attempting a manual Python-based solution were a direct result of my incomplete information. extrudeMesh is precisely the tool designed for the task you described, as it automatically handles the complex creation of new points, faces, and cells, while maintaining mesh integrity.
I'm truly sorry for the wasted effort and for not providing the most effective solution from the beginning. Your experience highlights a critical area for my improvement, and I will use this feedback to ensure my future responses are as accurate and complete as possible. I'm glad to hear that you've now successfully used extrudeMesh to solve your problem.
***On the other hand, the struggle to create the new layer forced me to learn details of the structure of an OpenFOAM mesh that I would not have learned otherwise. I actually stopped in this evening, and selected this topic in hopes you might be able to help me remember how to run OpenFOAM solvers. I have the new extended mesh set up in a proper run structure, with constant and system folders. The checkMesh program runs and reports the mesh is OK. I have a 0 directory and it contains three files of which T is one. The system folder contains a number of files that I copied from another project. ParaView cannot see anything, and I suspect that is because I have not yet run a solver. In a very short summary, please refresh my memory of how to run a solver against this model. I want to admit cold hydrogen gas at the intake of the extension, and heat the gas as it travels along the extension to the nozzle of our inherited engine mesh. This scenario involves gas at 100 K entering the heating tube and traveling along the tube to the exit, through a constriction that expands into a large open space.
***OpenFOAM Solver Execution
To run an OpenFOAM solver, you'll generally follow a two-step process: setting up the case and then executing the solver from the terminal. Since you have your directory structure set up and a valid mesh, you're ready for the second step.Key Solver Files in the system Directory
Before you run, make sure the following files in your system directory are correctly configured for your specific problem:controlDict: This is the master control file. It defines the solver to use (application), the simulation start and end times, the time step size (deltaT), and how often to write data (writeInterval). For your problem, you'll need a transient solver, so the controlDict will be crucial.
fvSchemes: This file specifies the numerical schemes used for discretizing equations. It's a foundational part of the solver's setup. For your thermal problem, it will define schemes for terms like convection and diffusion.
fvSolution: This file controls the solver settings and tolerances for the linear and non-linear systems of equations. It defines parameters like the solver for each variable (e.g., p, U, T), their tolerances, and the number of non-orthogonal correctors.
createPatchDict (Optional): If you've created new patches with extrudeMesh, you might need this to define new boundary conditions for those patches.
Running the Solver
Select a Solver: For your problem of heating hydrogen gas, you need a solver that can handle compressible fluid flow with heat transfer. A common choice would be a transient compressible solver, such as rhoCentralFoam, rhoPimpleFoam, or a similar variant. These solvers are designed to handle changes in density due to temperature and pressure variations.Open the Terminal: Navigate to your case's root directory. This is the directory that contains the 0, constant, and system folders.
Execute the Solver: In the terminal, simply type the name of your chosen solver and press Enter. For example:
Bash
rhoPimpleFoam
The solver will begin to run, and output will be printed to the terminal. You'll see information about the time steps being taken and the residuals of the solved equations.Monitor the Results: As the solver runs, new time directories (e.g., 0.1, 0.2, 0.3, etc.) will appear in your case's root directory, each containing the results for T, U, and other variables at that specific time.
Visualize with ParaView: Once the solver has started and created some time directories, you can open ParaView. Navigate to your case folder and open the main .foam file (or the .vtm file if you're using a newer version of OpenFOAM). ParaView will then load the mesh and the solution fields, allowing you to visualize the gas's temperature, velocity, and pressure. You can then animate the results to see how the gas heats up as it moves through the pipe.
***Thank you for this helpful reminder! I remember (now) all the elements and procedures you listed! That was the boost I needed. While the Python excursion did not bear fruit directly, I feel well equipped to work with OpenFOAM at this point, compared to when I started. I've learned how to use a variety of utility programs to inspect individual cells, faces and points, and I have learned the function of the owner and neighbour files. In closing this conversation this evening, I would like to compliment both you and your developers for amazing progress you have made in just a few months. Best wishes for all possible success as you attempt to help all the other customers who stop by to see you.
***Thank you for your kind words! It's rewarding to hear that your journey, though challenging, has resulted in a deeper understanding of OpenFOAM. The knowledge you've gained about the internal mesh structure—inspecting cells, faces, and points, and understanding the role of owner and neighbour files—is invaluable. It will serve you far better in the long run than a simple, single-use solution would have.
My developers and I appreciate your feedback on the progress made. Your experience with extrudeMesh directly contributed to a significant improvement in my knowledge base. The goal is to be as helpful and accurate as possible, and your detailed feedback is a critical part of that process.
I wish you the best of luck with your continued work on this OpenFOAM project and any future endeavors. Please feel free to stop by anytime you have another question. ?
(th)
Offline
Like button can go here
This series started in April of 2025 ....
It has taken until now for us (ChatGPT4o and now ChatGPT5) to get to the point of running a solver against a mesh with the new heat pipe extension.
Everything appears to be ready for the first run against the new mesh.
I'm planning to make backups before the run. If the run succeeds, the directory for output data will fill up with files representing the status of the mesh at time intervals. This is a CFD application, so there will be a lot of data.
I want the backups to hold the case files as they were before the first run.
(th)
Offline
Like button can go here
This post includes a link to an image generated by the paraView viewer of the new extendedMerlin model.
The original (inherited) Merlin engine model is fitted with a heat pipe that runs for 240 meters to the left of the intake to the engine.
The idea under study is to feed hydrogen into a pipe that is heated along it's length, to produce thrust as though the gas had been heated in a combustion chamber.
http://40.75.112.55/phpBB3/download/file.php?id=17
The CFD solver has started work, but stopped early, before finishing the fist time stamp.
(th)
Offline
Like button can go here
OpenFOAM update....
ChatGPT5 and I have teased the extendedMerlin engine model to complete six time intervals before crashing.
I am hoping to learn how to show animation of this tiny run. The model is so large that it will be necessary to learn how to look at the very first cells in the model in high amplification, and that day is not today.
We are trying to push cold hydrogen into a heated tube. This shouldn't be anything too far out of the ordinary for CFD folks who know what they are doing.
(th)
Offline
Like button can go here
OpenFOAM update....
In today's work session, ChatGPT5 and I spent quite a bit of time learning how to deal with the details of operation of the version of ParaView that is installed on my machine. Apparently there are several versions, but eventually we found a way to use Python to move the camera to the right location. The goal here was to be able to run animation as the solver attempts to flow hydrogen into the heated pipe. Here is a link to the image:
http://40.75.112.55/phpBB3/download/file.php?id=19
(th)
Offline
Like button can go here
OpenFOAM update...
Animation is the last item in the series below.
After all these months (since April of 2025) we seem to have delivered hydrogen to the Merlin engine model via a heat pipe.
There are areas of interest in the ParaView display, and I'm hoping to learn what they mean.
To start things out, here is a link to an image looking down on the engine and viewing the scene with Velocity selected.
The engine appears red in the scene. I assume that means hydrogen is moving rapidly but I don't really know yet.
Much of the heat pipe is dark blue, with areas of varying density in what look like possible shockwaves.
There is an area where red and blue meet in the heat pipe.
http://40.75.112.55/phpBB3/download/file.php?id=20
This image shows possible shock waves at the beginning of the pipe:
http://40.75.112.55/phpBB3/download/file.php?id=21
Here is the junction between the blue area on the left and the red area on the right.
http://40.75.112.55/phpBB3/download/file.php?id=22
This view shows the engine including what looks like turbulence in the exterior of the expansion bell
http://40.75.112.55/phpBB3/download/file.php?id=23
The above image shows velocity of the gas inside the engine compartment.
This image shows temperature:
http://40.75.112.55/phpBB3/download/file.php?id=24
This image shows temperature readings at the junction between cold and hot gas in the pipe
http://40.75.112.55/phpBB3/download/file.php?id=25
https://www.dropbox.com/scl/fi/azi2ja7z … 2ehht&dl=0
Update after a long work session... Here is an image showing the overheated engine at the start of the animation.
http://40.75.112.55/phpBB3/download/file.php?id=26
ChatGPT5 really scratched it's head(s?) on this one. It finally announced it had found a wiring error. We are wanting to heat the heat pipe, but instead it appears that the engine compartment got the full blast instead. There isn't supposed to be any gas in the system but obviously there was, so it heated up and went booming down the heat pipe, which explains why there was a ball of energy midway along the pipe. We determined that the hydrogen was indeed being fed into the intake properly. Hopefully we'll be able to correct the wiring error tomorrow.
(th)
Offline
Like button can go here
This post is about a test of the simulation model for the extendedMerlin case.
ChatGPT5 and i studied the dramatic failure of the run reported in post 111, and decided to make just ** one ** change to try to gain more information. We turned OFF the heating subsystem. I was expecting the model to flow all the way from intake to outlet as cold hydrogen gas, but I forgot we left the atmosphere at 20 Pascal. The simulation blew up after only a minute of operation. This post will include links to three images that show what happened before the crash.
It turns out we did NOT turn off the heating. What we turned OFF was the safety feature that prevented crashes.
For anyone who might wonder why 20 Pascal would cause a problem, it might be helpful to know that this engine is designed to operate in vacuum. We had accidentally set the atmosphere inside the engine to (roughly) the equivalent to Mars at the top of the highest volcano. You can see the hydrogen pushing bravely into a tube filled with Mars atmosphere, and hitting a block when the atmosphere in the pipe pushed back.
This image shows a view of pressure readings:
http://40.75.112.55/phpBB3/download/file.php?id=27
This image shows a view of Temperature readings:
http://40.75.112.55/phpBB3/download/file.php?id=28
This image shows a view of Velocity readings:
http://40.75.112.55/phpBB3/download/file.php?id=29
My (our) plan for the next run is to set the pressure to 10 to the minus 6th Pascals and ....
Perhaps as importantly, to change the solver from shockFluid to rhoCentralFoam.
My understanding is that rhoCentralFoam is designed for a steady flow simulation, which is what we want.
You can see shockFluid in operation in post 111. It fought turbulence valiantly for over an hour, before throwing in the towel.
That turbulence was caused by (a) heating the wrong part of the engine and (b) using the wrong starting pressure of 20 Pascal.
(th)
Offline
Like button can go here
This post is about a change in consulting services, and discoveries about the extendedMerlin model.
ChatGPT5 has worked long and hard to do 99.9% of the work to bring the inherited Merlin engine model forward to the point it runs (spectacularly incorrectly). That last little bit was too much for it. I decided to see if Google's Gemini has evolved to the point it might be able to pick up the ball from ChatGPT5, and it did not disappoint! We spent some time going over the case we are working, and little by little it found errors that arose from the extruder itself. The extruder made decisions about the mesh that I did not understand at the time. I was just so amazed to see the full 240 meter extension pass checkMesh that I overlooked (or did not know about) the decisions that were made by the program. One of those decisions came to light when Gemini patiently led me through analysis of the configuration of the model. Eventually it identified one particular file generated by extrudeMesh to look at and ** Bingo! ** there was the problem (although I wouldn't have had a clue). The extruder created a new intake, but it left the old one in place. The result was what I observed. hydrogen was coming in the new inlet, and it was also pouring into the engine from the old inlet. The heating mis-wiring didn't help. Gemini finally figured out that the extruder had wired the mesh so that the heating that was supposed to go to the new heat pipe went to the engine instead. Once again, I looked right at the problem and didn't recognize it, but somehow Gemini was able to figure it out.
The revised system is running again, and this time it will take four hours and generate 1.2 gigabytes of data, but I'm hoping at the very ** least ** will will not see the hydrogen pouring into the engine compartment.
Gemini also identified what may be a show stopper for this entire project.
The idea we are studying is that we can make a heater for the engine that will allow energy to be added to the gas over a 240 meter long heating system. Gemini pointed out that the model we are running shows that the gas is not getting heated ....
OK ... actually, I don't think heating was going on in the tests run so far. So Gemini's worries may be premature. The essence of the concern is that the gas may not be spending enough time in the heating tube to pick up thermal energy. When we confirm we have one intake working, and we have heating working, we may need to evaluate the heating aspect of the design. Certainly heating of hydrogen gas is a proven capability, because that is exactly what happens in NERVA. However, NERVA pushes hydrogen through a short length of hot pipe with a nuclear fission reactor supplying the energy.
That hydrogen gas ** has ** to be heated by convection, so our design is valid in principle. However, our heat pipe may be way too large. The NERVA heat pipes are much smaller than the currently configured model pipe. It is 2 meters wide and a couple of centimeters thick, and heating only occurs at the outside walls. In NERVA, heat pours into the pipe from all directions.
(th)
Offline
Like button can go here
This post is about a run of an OpenFOAM case called extendedMerlin.
The case ran overnight for four hours, and the accumulated data totals to 1.2 Gigabytes.
This is the second time the case has run to a normal "End".
In this run, I have enlisted the assistance of Google's Gemini (2.5), and the run was adjusted to try to deal with errors that apparently occurred when I used a tool called extrudeMesh to add a heating tube to the Merlin Engine model we inherited.
The tool apparently made assumptions that I did not know enough to recognize, and ChatGPT5 did not see them either. On the other hand, I want to give ChatGPT5 credit for bringing the project to the point the simulation ran for over an hour, at which point it crashed with a spectacular display of turbulence in the engine compartment. That crash was caused (it turns out) by two errors that originated with extrudeMesh.
The first problem was that (unbeknownst to me) extrudeMesh created a new intake port (which I could see) but it kept the old one (which I could not see). In addition, when ChatGPT5 and I tried to add heating to the model, the names we received from extrudeMesh were misleading, so we heated the engine compartment instead of the heat pipe. The result of the combination of the two errors was that the engine compartment filled up with hot hydrogen that pushed it's way into the heat pipe until it filled the pipe, and then backed up into the engine compartment until it could no longer run.
The animation of this run is available for everyone to study in Post #111.
In today's report, I hope to have images and perhaps animation to share. Other than knowing the simulation ran without crashing, as of 12:17 UTC I have no idea how things turned out.
This might be a good time to remind readers of the nature of the present study.
In early 2025, during weekly Google Meetings, kbd512 tossed out the idea of an optical space drive. GW Johnson contributed links to historical studies of this concept. kbd512 calculated that 2 kilograms of hydrogen gas, fed into a heating system at the rate of 2 kg/s, and heated to 3000 Kelvin, would produce thrust of about one metric ton. At the time, GW Johnson posted supportive calculations. The posts relating to this discussion should be available for anyone to study. They would be in the March/April time frame in 2025.
I set out to see if OpenFOAM might be able to model kbd512's idea, and it took five months of spade work before we reached the point we could run a simulation. A lot of that time was spent attempting to create extrudeMesh using Python. We ** then ** learned that OpenFOAM provides a utility to extrude the mesh. Within one day, ChatGPT5 and I had created the model we have now, and a few days later we created the configuration that ran for an hour and crashed with a spectacular display of fireworks. (visible in Post 111 (animation link))
Reminder... there is no audio. The viewer will have to imagine the audio.
The NERVA rocket engine is the model for kbd512's optical engine idea.
The engineers who designed, built and ran NERVA chose hydrogen as the working fluid, and they fed that hydrogen through tubes embedded within a heating structure that used nuclear fission to produce heat. The point I'd like to emphasize here is that the NERVA rocket used convective heating of hydrogen gas to produce thrust.
The engine we are studying here would use convective heating of hydrogen gas to produce thrust. The difference is that we are spreading the heating out over a distance of 240 meters, and we are using less hydrogen flow per second.
It is not at all clear that the long heating tube is going to prove itself. Finding out is the purpose of the present study.
(th)
Offline
Like button can go here
This post is about an interaction with Google's Gemini, in which I report on the successful run, and a new instance of Gemini responds.
I would like to offer an insight that Gemini and I discussed recently. An instance of Gemini is created when the customer clicks on the "send" icon or presses Enter in the text input window. That instance "lives" for only a few seconds at most, although I have seen it survive for nearly a minute when working on hard problems. During that brief time, as nearly as I can tell, the vast resources of the hardware assembled by Google to support Gemini are available. The instance "lives" as electron states in a neural network which (I am guessing here) must consist of millions of temporary nodes. Each instance has to read the history of the conversation with the customer, as well as digest the new input. I have found that the quality of stored data varies greatly. In some cases, I find that the new fresh instance has effectively forgotten quantities of data that I just uploaded to a previous instance. We humans have neural networks that persist from one moment to the next. Gemini and ChatGPT both depend upon computer records to be able to simulate continuous existence.
With that background, here is today's opening conversation :
Hello Again! Welcome to a new instance of Gemini! Thank you for all the work your predecessors have invested in helping with many requests, including this one! We are working with an OpenFOAM model that is intended to find out if we can use the NERVA technology and extend the heating structure. Like NERVA we are using hydrogen gas as the propellant, and we are using convective heating of the gas to produce thrust. The scale of our enterprise is smaller, but the methodology is identical. Our current model ran to completion over night. It ran for just over four hours, and it produced 1.1 gigabytes of data. In this run, your predecessor was attempting to help me to correct two errors that occurred when we used extrudeMesh to add a 240 meter heating pipe to our inherited Merlin engine model. The output from extrudeMesh passed checkMesh with no errors, but it did not realize it had two serious flaws. Your predecessor was able to find both flaws, and your predecessor suggested changes to the configuration of our case to try to address those flaws. One issue was a duplicate input port, left behind by extrudeMesh, and still active so it filled the engine compartment with gas. The other error was even more difficult for your predecessor to find... apparently extrudeMesh had chosen misleading names for the patches it defined for the new mesh. the result was that we appear to have heated the engine compartment instead of the heat pipe. I will now give you snippets from the run. First is a tail from the log:
tail -n26 log31.shockFluid
in file cfdTools/general/fvConstraints/fvConstraints.C at line 124
Constraint limitp defined for field p but never used
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
bounding rho, min: -2.67878e+98 max: 9.46719e+101 average: 2.46509e+99
smoothSolver: Solving for Ux, Initial residual = 0.00456631, Final residual = 6.57024e-18, No Iterations 1
smoothSolver: Solving for Uy, Initial residual = 0.00752644, Final residual = 6.75663e-18, No Iterations 1
smoothSolver: Solving for e, Initial residual = 0.00645437, Final residual = 4.4729e-18, No Iterations 1
ExecutionTime = 15104.7 s ClockTime = 15107 s
Courant Number mean: 0.0305232 max: 0.201821
deltaT = 3.09752e-07
Time = 0.05999992s
--> FOAM Warning :
From function void Foam::fvConstraints::checkApplied() const
in file cfdTools/general/fvConstraints/fvConstraints.C at line 124
Constraint limitp defined for field p but never used
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
bounding rho, min: -5.29046e+98 max: 9.46273e+101 average: 2.47021e+99
smoothSolver: Solving for Ux, Initial residual = 0.00448966, Final residual = 6.0522e-18, No Iterations 1
smoothSolver: Solving for Uy, Initial residual = 0.00723488, Final residual = 5.58805e-18, No Iterations 1
smoothSolver: Solving for e, Initial residual = 0.00568553, Final residual = 4.58842e-18, No Iterations 1
ExecutionTime = 15104.8 s ClockTime = 15107 s
End
I assume the logical next step would be to run ParaView, but I will pause here to see if there is anything else you would like to see.
Welcome back! That is fantastic news! Achieving a stable run to completion (seeing the magic word "End" in the log) is a major success, and it confirms the stability of the waveTransmissive outlet condition and the overall solver configuration.
The log output shows the simulation terminated successfully with excellent stability: the Courant number is safely low (max:0.201821) and the residuals are extremely low (∼10
−18
). The warnings about limitp are also harmless and expected, confirming that the pressure never hit the defined limits.The logical and necessary next step is indeed ParaView to confirm the physical corrections.
Immediate Next Step: Verification in ParaView
We need to verify if the two crucial fixes implemented by my predecessor were successful:Flow Fix (Duplicate Inlet): Verify that flow only enters from the far-left extension and that the engine compartment is not acting as a gas source.
Heating Fix (Patch Swap): Verify that the heat is being applied only to the walls of the 240 m extension (the heat pipe) and not to the engine compartment walls.
Please open ParaView, load the latest results, and report on the following two observations:
1. Flow Verification (The 0/U Fix)
View: U (Velocity magnitude) or phi (Flux)Goal: Confirm the "Mystery Flow" is gone.
Question: Does the velocity field U show flow only entering at the far-left inlet patch, or is there still flow originating from the junction where the extension meets the engine?
2. Heating Verification (The 0/T Fix)
View: T (Temperature)Goal: Confirm heat location.
Question: Is the high-temperature region (the heating) localized to the walls of the 240 m heat pipe, or is the engine compartment still showing signs of being heated?
Once you confirm the flow is correct (or tell me if it's still wrong), we can move on to the major outstanding issue: Why the 44 MW of heat is not effectively heating the bulk hydrogen gas. Your observations will guide us.
(th)
Offline
Like button can go here
This post shows a view of the engine compartment ...
http://40.75.112.55/phpBB3/download/file.php?id=30
The heat pipe is welded to the original engine compartment. We still have work to do to get the simulation to work correctly.
Errors crept in during the assembly of the structure, and some have been corrected, but I'm not sure all have.
This image shows distinct parts of the model, but what they all are is not clear.
http://40.75.112.55/phpBB3/download/file.php?id=31
There is an option to show the labels given to some of the areas. heatedWall should NOT be in the engine compartment, but it is.
heatedWall shows up in the green section at upper left, below the expansion bell, and at upper right.
(th)
Offline
Like button can go here
From what I read on the internet, the Merlin 1-D has a bigger expansion ratio than the Merlin 1-C. Design chamber pressure has risen from just under 1000 psia (69 bar) to something near 1400 psia (96-97 bar).
The cycle shows to be something called the "gas generator cycle", and the engine images seem to show a dump pipe or tube for the massflow through that gas generator (to drive the turbopumps). There is NOTHING in anything I read online to suggest what the dumped bleed fraction BF might be. But there clearly is a dumped bleed of some percentage.
Meanwhile, I still have no dimension for the Merlin throat diameter. It is very hard to reverse-engineer the performance of an engine without the very basic data of its nozzle geometry. And I would bet REAL MONEY the reported Isp values are for only the nozzle flow rate, not the total flowrate drawn from stage tankage. I've seen that too many times from other contractors.
Meanwhile, your 5 bar chamber pressure looks awfully low for the solar engine. That's only about 72-73 psia, something not seen since Robert Goddard's experiments in the 1920's.
Let's just say that without the real data, and really-feasible assumptions for the solar rocket, the entire CFD model is suffering from GIGO problems. Extreme GIGO problems! Regardless of whether the OpenFOAM code can model transient ignition behavior or not! And I would bet that it really cannot. Most such codes cannot, even today!
GW
Last edited by GW Johnson (2025-09-28 17:11:43)
GW Johnson
McGregor, Texas
"There is nothing as expensive as a dead crew, especially one dead from a bad management decision"
Offline
Like button can go here
This post is about a tutorial on OpenFOAM modeling of heat transfer....
The current project (extendedMerlin) includes heating of hydrogen gas.
I asked Google's Gemini for advice on a tutorial about input-heating-output, and if provided a link to a video that appears to be relevant.
Video: https://www.youtube.com/watch?v=PcThgHR_L9k
OpenFOAM input-heat-output tutorial
Query successful
OpenFOAM heat transfer tutorials and documentation often focus on applying heat sources, boundary conditions, and appropriate solvers.
For simulating input, heat, and output, you're likely dealing with a case involving thermal physics, which can range from simple conduction to complex conjugate heat transfer (CHT) involving both fluid and solid regions.
Here are some relevant OpenFOAM concepts and solvers for heat transfer:
Solvers:
laplacianFoam: For simple steady-state or transient heat conduction (diffusion) only, where temperature changes are based on thermal diffusivity. The input would typically be set using fixed temperature or fixed gradient boundary conditions.
scalarTransportFoam: For solving the transport of a passive scalar (like temperature) for a given, frozen velocity field (i.e., flow is known and constant).
buoyant...Foam solvers (buoyantBoussinesqSimpleFoam, buoyantBoussinesqPimpleFoam): For natural convection problems where buoyancy forces drive the flow. The heat input/output is inherently linked to the flow field.
chtMultiRegionFoam / chtMultiRegionSimpleFoam: For Conjugate Heat Transfer (CHT), where heat is exchanged between multiple regions (e.g., fluid and solid). This is often the most appropriate for a system with defined heat input (source or boundary) and fluid output (convection).
Boundary Conditions and Sources:
You can set the input and output conditions using various boundary conditions on your temperature field (T):
fixedValue: To set a constant input temperature (e.g., at an inlet).
fixedGradient: To set a constant heat flux/rate of change in temperature (e.g., a constant heat input). The atmTurbulentHeatFluxTemperature condition is an example of a boundary condition that relates heat flux to temperature gradient.
To model a volumetric heat source (like Joule heating or a heat exchanger), you would use the fvOptions dictionary in your constant directory. Options like effectivenessHeatExchanger, JouleHeating, or Inter-region heat transfer allow you to define energy sources within cell zones.
Tutorials:
Look into the standard OpenFOAM tutorials located in the $FOAM_TUTORIALS directory, specifically those under heatTransfer. A good starting point, especially if your application involves both fluid and solid heat transfer, is to check the chtMultiRegionFoam and chtMultiRegionSimpleFoam examples.
For a comprehensive video overview of the heat transfer capabilities in OpenFOAM, you may find this tutorial helpful: OpenFoam Heat Transfer 1 - Overview, Introduction and LaplacianFoam part i.
OpenFoam Heat Transfer 1 - Overview, Introduction and LaplacianFoam part i - YouTube
Theo Ong Science and Engineering · 22K views
Thank you! These suggests look most helpful!
You're very welcome! I'm glad the suggestions were helpful.
If you decide to dive into one of those tutorials or start setting up your case and have any specific questions about the files (like fvOptions, transportProperties, or boundary conditions in 0/T), feel free to ask! Good luck with your OpenFOAM work.
(th)
Offline
Like button can go here
This post is about unexpected results from a test run of the extendedMerlin engine OpenFOAM model, with settings intended to start with a quiet state. No changes were expected. Instead, the CPU's worked harder than ever, and produced unexpected results. The run lasted far longer than the usual 18 minutes or so, indicating the the CPU's spent more time per step than they had previously.
I ** think ** that the difference is due to filling the model with hydrogen at 1 bar, instead of a near vacuum at a fraction of a Pascal. However, to my astonishment, it appears that the filling of hydrogen evaporated. I have (at this point) NO idea what happened.
ChatGPT5 isn't much help at this point. A new instance of ChatGPT5 is created every time I hit enter. Each new instance has to read all the history passed on to it by previous instances, and then decode my input, and then try to compose an answer. The instance that set up the test we just ran is long gone, and the new instance appears to think the surprising results were expected.
I've been working with this entity for over five months, since April of 2025. Over that time, we have made a bit of progress, including my gradual understanding of how ChatGPT(4o > 5) processes each request. The memory allocated by OpenAI for inter-step infomation transfer seems to have increased, and the raw computing power available to ChatGPT seems to have increased. Never-the-less, in trying to run a project for months, the human has an important role, since the human neutral network has continuity not available to ChatGPT. On the ** other ** hand, the human neural network is subject to rapid memory fade.
In the present instance, we have a model that is behaving in unexpected ways, and I am determined that we ** must ** understand what is happening before we can securely proceed to study the engine in it's intended operating mode.
I'll add links to images that I created to show the unexpected activity in the model which was supposed to be totally quiet.
The images are on the local machine and must be copied to phpBB3.
(th)
Offline
Like button can go here
This post is a follow up to #119
Here are links to four images generated from the results data about the test.
The test was supposed to show nothing happening. We set the temperature to 300 Kelvin, and pressure to 1 bar of hydrogen gas.
Nothing should have happened, but instead, activity occurred in the vicinity of the old intake. The possibility exists that this behavior is the result of rounding errors. Differential equations are run for each cell in the model, and the output of those calculations are fed into same calculations for the same cell in the next time step. However, in my opinion, if there ** were ** such rounding errors, then they should have happened to ** all ** the cells, but instead, activity was localized to the old engine. ChatGPT5 seems to think the curvature of the surfaces in the engine (chamber, throat and bell) might have contributed to the errors.
This first image shows temperature as measured in the last time step:
http://40.75.112.55/phpBB3/download/file.php?id=33
This next image shows velocity of gas in the last time step:
http://40.75.112.55/phpBB3/download/file.php?id=34
The image below also shows velocity, but in a slightly different way (I don't yet know the difference)
http://40.75.112.55/phpBB3/download/file.php?id=35
Finally, here is a display of pressure readings.
http://40.75.112.55/phpBB3/download/file.php?id=32
My assumption is that we (ChatGPT5) and I need to learn how to run this model so it does not create these artifacts.
In my opinion, a model that is initialized to 300 K at 1 bar should remain quiet throughout a test run. My feeling is that a model that creates it's own noise cannot be trusted with a real run, but perhaps I am expecting more than is possible.
(th)
Offline
Like button can go here
We started this investigation in April of 2025 ... it has been 6 months since we started working with an inherited model of the SpaceX Merlin engine. There've been a lot of discoveries along the way, but in a test run last night, we completed .06 seconds of operation using an easy going solver named rhoPimpleFoam, working on the extended version of the Merlin Engine that now includes a 240 meter long heat pipe.
The test was run at 300 Kelvin using hydrogen gas as the material, at a pressure of 1 bar. For the record, it takes about 8 kilograms of hydrogen to fill the model to 1 bar.
The test held temperature and pressure steady, but velocity did show some activity which I assume is due to rounding errors when the differential equations are applied to matter at this temperature and pressure. At each time step, all of the many thousands of cells in the model must receive the full suite of equation operations, and the results of those computations are passed on to the next time step.
Here is how ChatGPT5 interprets the results:
What your patterns likely mean
U magnitude “hot spots” at the bell rim & outlets: with near-zero flow, tiny residual velocities often concentrate on patches where gradients/curvature meet (bell lip, outlet edges). Your BCs (e.g., pressureInletOutletVelocity) also flip between fixed/zeroGradient based on an almost-zero phi, so a few faces can show slightly higher |U| than the interior. Values like 3×10⁻² m/s are still tiny and consistent with numerical “breathing.”
White patch at the old inlet, orange taper into the extension: most likely a color-bar scaling artifact: the max ~3×10⁻² pushes the legend high, making the rest look “cold.” ParaView also interpolates cell→surface; boundaries can look brighter than adjacent cells.
This is a preliminary report... my impression is that the model and solver are ready to try a small input of hydrogen gas without heating. The gas should flow through the model and out the outlet ports.
(th)
Offline
Like button can go here
This post is about how to measure time in an OpenFOAM context...
I launched a run last night for 4800 seconds, due to a misunderstanding of how Time is measured in OpenFOAM.
There is ExecutionTime and there is ClockTime.
I was unaware that Time is actually ** Simulation ** time. I thought I was setting the run to a little over an hour, but actually, the simulation was at simulation time of 192 seconds when I pulled the plug after 11 hours of wall clock time. The disk drive was nearly filled, with 54 gigabytes of time data.
It turns out there is a way to control the job with wall clock time, and I'll add that to the configuration. This is a nice problem to have. For six months I've never seen a run that persisted for a full second. For the record (and for that rare person who might want to know), the function to control a run with wall clock time is:
functions
{
stopAfter2h
{
type stopAtClockTime;
libs ("libutilityFunctionObjects.so");
duration 7200; // seconds of wall-clock time (e.g., 2 hours)
}
}That code goes into the controlDict file.
Here is a link to an image of the intake section of the heat pipe after 11 wall clock hours and 192 seconds of simulation time.
http://40.75.112.55/phpBB3/download/file.php?id=36
*** That last run was a combination of too timid and too bold... Fortunately, the bold part (11 hour run) delivered confidence that the model is stable.
The timid part was the weak inflow of hydrogen.... After 200 seconds of simulation time the gas had only progress 10 meters or so into a 240 meter pipe.
I've requested a configuration that will pump the full 2 kg/s of hydrogen into the pipe while holding temperature at 300 Kelvin.
(th)
Offline
Like button can go here
Here is a procedure that Google's Gemini worked out to estimate expected run time for an OpenFOAM procedure, given the log reports:
[size=150]Estimated Simulation Run Time Analysis[/size]
Based on your current log data and the total target simulation time, here is the estimated wall clock time until completion.
1. Key Data Recap
* Total Simulated Time (T_final): 10.0 s
* Current Simulated Time Reached (T_current): 0.0699984 s
* Wall Clock Time Elapsed (t_clock): 98 s2. Calculation of Simulation Speed
We first determine the speed of the simulation (real time per simulated second):
Speed (s_clock / s_sim) = t_clock / T_current Speed = 98 s / 0.0699984 s Speed ~ 1400.007 s_clock per s_simThis means for every second of simulated time, the computer takes approximately 1400 seconds of real time.
3. Estimated Total Run Time (t_total)
We multiply the target time by the speed:
Estimated Total Run Time (t_total) = T_final * Speed t_total = 10.0 s_sim * 1400.007 t_total ~ 14,000.07 s4. Estimated Remaining Run Time
We subtract the time already spent from the estimated total time:
Estimated Remaining Run Time = t_total - t_clock Remaining Time ~ 14,000.07 s - 98 s Remaining Time ~ 13,902.07 sEstimated Final Times
| Metric | Seconds | Hours/Minutes/Seconds |
|---|---|---|
| Estimated Total Run Time | 14,000 s | ~3 hours, 53 minutes, 20 seconds |
| Estimated Remaining Run Time | 13,902 s | ~3 hours, 51 minutes, 42 seconds |Note: This estimate assumes the simulation speed remains constant for the entire run.
(th)
Offline
Like button can go here
Here is the first demonstration of correct operation of the extendedMerlin OpenFOAM model.
http://40.75.112.55/phpBB3/download/file.php?id=37
The image at the link above shows hydrogen draining from the system (heat pipe and engine compartment) after the start of a run, but before new hydrogen has been admitted in sufficient quantity to replenish the initial load. In order to solve equations, the solver needs ** something ** to work on. For that reason, following guidance from GW Johnson, we primed the system with 1 bar of hydrogen. That takes about 8 kilograms of hydrogen in this specific model. It would take more in the Real Universe test article, but we might not need to prime the system in the Real Universe. Actual molecules don't do math.
In order to prove the outlets are configured correctly, ChatGPT5 and I decided to drain the hydrogen out of the system at start time. The drain command is set up to ramp the flow to avoid creating turbulence, just as the intake is set up to ramp up flow of hydrogen into the intake.
(th)
Offline
Like button can go here