Outdoor+ UMCF: duplicate material cellZone names in exported transportProperties

[KnhY200505]

Hi Eddy3D team,

I found a possible bug in Outdoor+ UMCF. My terrain has a surface material and a soil material. The mesh correctly creates terrain_layer1 and terrain_layer2, but both material entries in constant/terrain/transportProperties are written as name terrain_layer1;. The second one should be terrain_layer2?

transportProperties.txt

This causes the error: In solid region terrain, a cell is assigned to more than one material cellZone!

Thank you！

[kastnerp]

Thanks for the report, and especially for attaching the file — that is what made this decidable in minutes instead of guesswork.

You found a real bug. It is fixed (PR #813), and the fix will ship in the next release.

What was actually happening

Both entries in your transportProperties carry Surface Material's defaults — rho 1980, cap 820, lambda1 1.35. Soil Material's defaults are 1150 / 650 / 1.5. So both entries came from a Surface Material component: one set to HamstadConcrete, one set to Soil, the second wired into Terrain Region's Soil Material input.

Surface Material always writes the zone name terrain_layer1, Soil Material always writes terrain_layer2. A material component has no way to know which socket it was plugged into, so it writes a placeholder name and the Terrain Region component — which owns the two sockets, and therefore knows which layer is which — is supposed to correct it. Building Region has always done that. Terrain Region did not: it passed both Settings straight through, so your second material kept the name terrain_layer1 and the two entries collided.

Your mesh was fine, which is why this surfaced so late — both cellZones really do exist, and urbanMicroclimateFoam only notices in the solid-region setup, after meshing, with an error that names no component. Exactly the kind of thing that costs an afternoon.

Workaround on 1.9.0.827

Replace the second Surface Material with the Soil Material component (same Terrain tab) on the Terrain Region's Soil Material input. The case will then export terrain_layer1 + terrain_layer2 and the solver error goes away. Note the two components also ship different defaults, since a soil layer is not a paving layer — Soil Material's 1150 / 650 / 1.5 are probably closer to what you want for the lower layer than the 1980 / 820 / 1.35 your file currently has there.

What changes in the next release

Patrick asked me to fix the underlying behaviour rather than just answer the thread, so three things change:

1. The socket decides the layer. Whatever material Setting arrives on Soil Material now configures terrain_layer2 and whatever arrives on Surface Material configures terrain_layer1, whichever component produced it. Your graph, unchanged, will export a solvable case — with a warning on the component telling you what was re-assigned and which component belongs there.
2. The same class of miswiring is caught on the buildings side too. Wiring a single material component into both Building Region sockets used to rename one shared object twice and collapse both layers onto buildings_layer2 — the identical solver abort by a different route. That is fixed in the same change.
3. The case build refuses to pretend. If a cellZone ends up claimed by two materials, or by none, the Outdoor+ Case component now shows an error naming the region and the zone, with the solver message it would have produced — before you spend the meshing time, not after.

Regression tests are pinned against your file: the test suite builds a real case, asserts the written dictionary reproduces the two-terrain_layer1 output you attached, and then asserts the fixed path produces terrain_layer1 + terrain_layer2 with both of your material models preserved.

Thanks again — a clean report with the artifact attached is worth a lot, and this one was a genuine gap.

---

Answer drafted by Claude (Anthropic's AI assistant), at the instruction of Patrick Kastner (Eddy3D maintainer).

[kastnerp]

Closing: the fix (PR #813) shipped in 1.10.0.827 on 2026-08-25. Update via the Rhino Package Manager and the two terrain materials will be written as terrain_layer1 / terrain_layer2. Reopen if it still happens on that version or later.