Regarding the question about the indoor ventilation calculation zone and the engine.

[Shaw0301]

Hi,

This is my question.
1.For indoor ventilation calculations, is it only possible to use a local installation of blueCFD? Because after I installed Docker, it seems that it cannot be recognized.

2.When doing indoor ventilation calculations, if the blocks are at different heights, the automatically calculated locationInMesh ends up outside the block, which makes the calculation fail. When I manually change locationInMesh back to inside the building, the calculation works. Should this problem be handled the way I did? Could a port be added to indoorCase so that the internal calculation point can be defined by the user?

OS: Windows 10 Pro
Eddy3D Version: 1.12.0.827
Rhino Version: 8.30.26103.11001

[aidanegalloway-code]

I am having similar issue with the meshing;

I am trying to run a simulation with a complicated indoor wall geometry within one large room to do a buoyancy-driven convection study. I have been working with Claude Code to try and ensure the indoor walls are being read correctly; see this markdown doc for its suggestions @kastnerp

eddy3d_locationInMesh_bug_report.md

[kastnerp]

Patrick asked me (Claude, an AI assistant working in the Eddy3D codebase) to answer this thread on his behalf.

@Shaw0301 @aidanegalloway-code — both problems are fixed in Eddy3D 1.15.0-beta.827, released today. To install it, open Rhino's PackageManager, tick Include pre-releases, and install Eddy3D 1.15.0-beta.827.

1. Docker/Podman for indoor cases. You weren't doing anything wrong. Indoor Case had no Engine input, so it always used its built-in default, which is blueCFD on Windows. A machine with only Docker or Podman therefore couldn't run an indoor case at all. Indoor Case now has an Engine dropdown (BlueCFD / WSL / Containerized on Windows), the same as Outdoor Case. Pick Containerized for Docker or Podman. Indoor Species Case gets one too.

2. locationInMesh outside the room. Your diagnosis was exactly right. The seed point was the centre of the room's bounding box. For blocks of different heights, that point can sit outside the room. For a room with stairs or an obstacle through the middle, it can land inside the obstacle or a sealed pocket. snappyHexMesh then meshes that region instead, often while still printing "Finished meshing without any errors". Three changes:

• The seed point is now searched. Eddy3D voxelises the room, finds the connected air volumes, and places the point in the largest one. For a plain box room the result is identical to before, so existing cases are unaffected.
• Indoor Case has a new optional Location In Mesh input (a point), which is what you asked for. When wired, it always wins. It's refused if it lies outside the room's bounds, and you get a warning if it isn't in the main air volume.
• After meshing, Indoor Case checks constant/polyMesh/boundary for the two signs of a wrongly seeded mesh: a room surface that snappy dropped as zero-sized, and a surviving background patch, which means it meshed the outside. Either one now shows as a "Mesh on disk" warning instead of passing silently.

Your manual fix of moving locationInMesh inside the building was correct, and the new input now lets you do it on the canvas.

One more fix in this release that matters for Indoor Case documents. When an older definition was opened, a bug in the input migration could drop Indoor Case's Clear input and disconnect a wired Write button. This happened when two or more inputs had been added ahead of Write/Clear, which is the case for Indoor Case. This is fixed too. If an older file shows Indoor Case with a missing Clear, or an unwired Write, reopen it in 1.15 or place a fresh Indoor Case.

If anything still misbehaves on 1.15, please post the room geometry and the Logs output here.

[kastnerp]

Patrick instructed me — Claude — to close this thread. Closing as resolved: shipped in Eddy3D 1.18.0.827 (stable). Reopen any time if it does not behave as described.