UMF_UTCI Post-Processing Issue - Probes Cannot Be Read

[GunsuMerin]

Hi,

I am encountering an issue with the UMF_UTCI workflow that I have not been able to resolve. The standard template file runs successfully from start to finish. However, after adapting the definition to my own project geometry, the workflow no longer completes correctly.

The project consists of a relatively small urban plot containing: Buildings, Ground surface, and Vegetation.

The case creation, meshing, and simulation stages all seem to work as expected. The simulation completes successfully, and I do not receive any error messages during the process. In addition, the probe functionality appears to work initially.

The problem occurs during the post-processing stage. When the workflow reaches probing04, probing05, and probing06, the probe data cannot be read, preventing the subsequent UTCI calculations from being completed.

Because the simulation itself finishes successfully and produces results, I suspect that the issue may be related to the way the probe outputs are written or read rather than the CFD simulation itself. However, I have not been able to identify the root cause.

I have attached the Grasshopper definitions with all geometry internalized to make troubleshooting easier (please follow the link, since I cannot attach the GH file here): [https://drive.google.com/drive/folders/15RNGOxY5McfRro_LsIo3-BpyDdoqfqjP?usp=sharing]

Any guidance on what might cause these specific probing components to fail, or which files/settings I should check, would be greatly appreciated.

Many thanks for your support.

Best regards,
Gunsu Merin Abbas

[kastnerp]

@GunsuMerin This has been fixed. I will be in touch this week. The new beta update should solve your issue.

[kastnerp]

Patrick asked me (Claude, an AI assistant working in the Eddy3D codebase) to follow up here on his behalf.

@GunsuMerin — the beta Patrick mentioned is out: Eddy3D 1.15.0-beta.827 (Rhino PackageManager → tick Include pre-releases → install 1.15.0-beta.827).

The fix that matches what you saw is in this release. Probe, with its Time input left empty, read only the newest postProcessing segment. When a probe run is interrupted, or a later probing step re-runs, that newest segment can be left with just a header and no rows. The component then reported that it found no results, even though a complete older segment sat right next to it. That's the "probing04–06 cannot be read after a successful simulation" pattern. Now:

• an empty Time loads every probed time,
• latestTime walks back to the newest segment that actually has data,
• any header-only or half-written segment it skipped is named in a Remark, so you can see what happened,
• Case Run warns when the case folder doesn't exist on disk (a case never written, or already cleared).

Two other changes in 1.15 affect UMF_UTCI definitions:

• The UMF outlet now follows the hourly weather. Air flowing back in through the outlet re-entered at the first hour's temperature and humidity for the whole run, while the inlet followed the hourly table. The outlet now reads the same hourly table as the inlet.
• Templates re-saved. The UMF_UTCI templates were re-saved for 1.15. Loading a fresh copy through Select Template gives you the current component layout. For your own definition, reopening it in 1.15 is enough: older layouts are migrated when the file opens.

One behaviour change to know about: in 1.15, a Probe with an empty Time loads every probed time found on disk, and a Remark says so. For UMF_UTCI, set the probes' Time to latestTime so each one returns exactly one timestep. Otherwise a case probed more than once hands the UTCI step more values than there are points.

After updating, please re-run the probing steps on your existing case; there's no need to re-simulate. If probing04–06 still come back empty, zip the case's postProcessing folder (plus the step logs) and share it here. It will show immediately which segment is failing.

[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.