Annual UTCI calculations using the Outdoor+ UMF_UTCI template

[AVBBS]

Hello,

I am currently working with the Outdoor+ UMF_UTCI template in Eddy3D and would like to clarify a few aspects of the setup and interpretation of the results.

I am using the following software versions:

• Eddy3D: v1.14.0.827
• Rhino: 8 SR34
• Operating System: Windows 10 — 10.0.26200 x64

I understand from the documentation that UTCI (Simulation) is intended to compute annual, probe-specific UTCI using MRT, wind speed, air temperature and relative humidity data. However, I am unsure how the timing of the UMCF simulation relates to the annual UTCI calculation.

I have several questions:

• How should the Timing Parameters be used when calculating annual UTCI?
  The UTCI (Simulation) component is described as an annual calculation, but the UMCF Case also requires a Timing input. Does the timing input determine the period simulated by the CFD case, while the UTCI component subsequently uses the resulting data together with the annual weather data? Or should the UMCF case itself somehow represent the full 8760 hours?

• How should I interpret the number of values entering the UTCI (Simulation) component?
  In my case, the inputs for MRT, wind velocity, air temperature and RH all contain 5340 values. I initially expected 8760 values because the UTCI calculation is described as annual. However, 5340 corresponds to the number of grid/probe points I am using. Does this mean that these values represent spatial probe/grid points rather than the number of simulation hours? If so, what is the correct way to verify that all 8760 annual hours are actually being represented?

• Relative humidity is consistently reaching 100%, and this also causes a problem with the w visualization.
  The RH output I obtain is essentially 100% everywhere, which means that the minimum and maximum values become identical and the w visualization gives the following error:
  Cannot evaluate a gradient with a zero-length range
  Could this be related to the specific humidity field being almost spatially uniform, or to RH being capped at 100%?

  I also tried calculating RH independently from the specific humidity w and air temperature T. I used the following equation:

  RH = (w*101325) / ((0.622+0.378*w)*(611.2*exp((17.67*(T-273.15))/((T-273.15)+243.5))))

  where T is air temperature in Kelvin. This gives values of approximately 1.113–1.118, i.e. approximately 111–112% RH if interpreted as a fraction. This makes me suspect that the Eddy3D RH result is being capped at 100%. What could cause the underlying specific humidity to result in RH values above saturation?

• The wind velocity domain appears to be reversed.
  For U, I obtain approximately 0.0437 to 3.867 m/s, which seems reasonable spatially. However, the domain shown in the visualization appears to use 3.867 as the lower limit and 0.0437 as the upper limit. Is there a reason why the template would intentionally define the domain this way, or is this likely a visualization/setup issue? Also, does the blue-to-red colour scale have any implications for how the wind results should be interpreted?

There are quite a few questions here, but I would really like to understand how the workflow is intended to work before drawing conclusions from the results.

My main question is therefore how the complete workflow is intended to work: how the UMCF simulation timing, the 8760-hour annual weather data, the spatial probe/grid points and the UTCI (Simulation) component are connected. I would like to make sure that I am not interpreting a spatial set of 5340 probe values as 5340 hours, and that the resulting UTCI map is actually representative of the intended annual calculation.

I have attached a Grasshopper file with the relevant components, together with screenshots of the results, so the setup can hopefully be reproduced.

Any clarification on the intended workflow and whether the results described above are expected would be greatly appreciated.

Thank you for your help.

Best regards,

AV

260909_UTCI.zip

Overview of the script:

Overview of the UTCI results:

Air temperature results:

RH results:

Wind velocity results:

[kastnerp]

Patrick asked me (Claude, an AI assistant working in the Eddy3D codebase) to answer this thread on his behalf. Everything below was checked against the code and the 1.14 template; thanks for the detailed report and files.

@AVBBS — short version: with the template as shipped, your map is a one-hour spatial snapshot, not an annual UTCI. Your RH observation also uncovered a genuine bug on our side.

1. Timing, and what UTCI (Simulation) is actually computing

The UMF simulation covers exactly the window set by Timing Parameters. In the template, Duration is 1 hour, and Hour of Year comes from the Calendar, which is set to 20 January, 16:00 (HOY 473). Eddy3D writes that hour's weather (air temperature, humidity, cloud cover, direct/diffuse radiation, sun position) as the inflow tables. So the CFD represents one hour, not a design day and not a year.

UTCI (Simulation) has two modes and chooses one from the shape of its inputs:

• Annual: an MRT result or tree plus an annual wind field from the VAF (velocity amplification factor) workflow, with full 8760-hour air temperature and RH series. The output is one UTCI series per probe over the year.
• Spatial snapshot: MRT, air temperature, RH and wind all have one value per probe point. UTCI is computed once per point, for that single hour. The component's banner then reads "Spatial snapshot", and Comfort Hours/% are just 0/1 per point.

The UMF_UTCI template feeds it the snapshot shape, so the result is UTCI for 20 January at 16:00 at each point. The MRT going in comes from Deconstruct MRT at the same HOY (the same Calendar), so all four inputs refer to the same hour. For a genuinely annual map, the route is the wind-factor (VAF) workflow combined with the annual MRT. A single UMF hour cannot be stretched into a year.

2. The 5340 values

Your reading is correct: they are spatial, one value per probe point, all for the same time. Probe's Time Steps output shows which solver time was read. For your 1-hour run it should say 3600; anything smaller means the run hadn't finished.

Two refinements:

• TMean / UMean / wMean are running averages over the whole simulated hour, including the start-up from uniform initial conditions. They are not the state at the end of the hour. Probing T, U and w instead gives the hour-end state. Worth comparing both.
• In 1.15.0-beta.827 (released today), a Probe with an empty Time loads every probed time found on disk. So if a case was ever probed mid-run, you'd get more than 5340 values. Setting the probes' Time to latestTime keeps exactly one timestep.

3. RH at 100%, and your 111–112%

Your manual check is right, and it pointed us at a real bug. The Relative Humidity component clamps its output to 100%, which is why you see a flat 100% everywhere. That flat field is also what triggers Grasshopper's "Cannot evaluate a gradient with a zero-length range" (min = max).

The underlying cause is upstream of that component. Eddy3D writes the inflow humidity (wambient, which also sets the initial w) from the EPW as water-vapour density in kg/m³. UMF, and our own RH component, treat w as kg/kg. The two differ by the air density, about 1.2–1.3, so the inflow humidity is roughly 25% too high. At your January conditions (EPW RH in the high 80s at around 5 °C), that lands at about 108–112%, which matches what you computed.

We're fixing this. Until then, please treat the absolute humidity and RH from UMF cases, and the UTCI that depends on them, with caution. The UTCI sensitivity to RH is modest at low temperatures, but it isn't zero.

(Two smaller template details, while we're here: the K → °C conversion subtracts 273 instead of 273.15, a 0.15 K offset, and relative humidity is computed at a fixed 101325 Pa.)

4. The reversed wind domain

That comes from the template's own wiring, not a component bug. On the wind (and RH) Gradient, Lower limit is fed the domain's End and Upper limit its Start. That inverts the colour ramp: high wind shows blue, calm shows red, which highlights stagnant areas. It isn't documented anywhere, so it reads like an error. If you prefer the conventional orientation, swap the two wires. The values themselves are unaffected.

If you share which question you're ultimately answering (a representative hour, a season, or annual comfort), we can suggest the most direct workflow for it.