Bugs about UMCF 0.0.27

[WahfeiWong]

Hi Patrick and the Eddy3d team,

Thank you for developing the building environmental performance analysis tool based on Rhino-Grasshopper, which makes OpenFOAM much more user‑friendly for non‑CFD professionals. I have tried the latest version 0.0.27 of UMCF (Eddy3d Outdoor Plus) and encountered a few issues. I have also tested versions 0.0.12 and 0.0.20. Version 0.0.27 improves the multi‑layer material settings and basic terrain addition – that is really great. However, to help with the iteration of the tool, I would like to report some detailed issues:

1. In UMCF 0.0.27, the reference wind speed reference height Zref (fixed value 10 m), building internal temperature Tbuilding (fixed 23 °C), terrain solid domain internal temperature Tterrain (surprisingly fixed 37 °C), and leaf area density LAD (fixed 1) cannot be changed via the corresponding components. This forces users to manually modify the U, T, LAD, etc. files in the 0/air folder, which is very inconvenient. This problem did not exist in version 0.0.20.

2. In previous versions (0.0.12 and 0.0.20 that I tested), the initial fields of temperature T and humidity w (time step 0) were automatically extracted from the EPW file (the first value of the meteorological time series). This ensures that the results of consecutive simulations align strictly with the EPW data. However, version 0.0.27 uses fixed initial values, which can cause discontinuous or abnormal results in the first few time steps. For example, if the input air temperatures are 10, 12, 14 °C, the solver’s boundary conditions will be 23 (the fixed value), 12, 14 °C corresponding to time0, time1, time2. Since time0 initialises the fields, the correct results might be time1 ≈ 11 °C, time2 ≈ 13 °C, but without manually modifying the T file, the actual results may become time1 ≈ 18 °C, time2 ≈ 15 °C (because the initial temperature of 23 °C deviates from reality, causing a cooling curve that diverges from the true solver accuracy).

3. I looked at the source code. The plant parameters H (canopy height), Rl0 (longwave radiation at canopy top), and minCellSizeFactor do not seem to be used by the urbanMicroclimateFoam model. You might want to confirm this. The four parameters a1, a2, a3 and D0 are only used in the commented‑out plant stomatal resistance model (type2), but it is nice that they are kept. I recompiled a plant model library, enabled that commented‑out model, and can freely replace it – this kind of freedom is one of the exciting aspects of open‑source software.

4. Additionally, it would be great if a grass model could be implemented (looking at the source code, it seems essentially similar to the vegetation model, so perhaps vegetation could be used instead of grass) as well as more flexible terrain modelling. However, apart from possibly needing to manually modify some files, version 0.0.27 is already very good. Lastly, I want to thank Patrick for open‑sourcing Eddy3d. I tried to fix some MRT‑related functionalities, and the MRT calculation is faster than that of Ladybug Tools. Thank you again for your excellent work.

[kastnerp]

@WahfeiWong I tried to fix some MRT‑related functionalities, and the MRT calculation is faster than that of Ladybug Tools. Thank you again for your excellent work.

Could you please submit your fixes as a pull request?

[WahfeiWong]

I'm still a bit new to GitHub, so I'll take some time to learn how to use it properly. For now, I've sent the fixed Eddy3d source files and the test GH script to your email at pk373@cornell.edu.

[kastnerp]

@WahfeiWong Thanks for the super detailed bug report! I am glad 0.0.27 did better than the previous version but yes, we still have a lot of bugs to fix. Could you please see if v0.0.28-beta fixes your issues?

[WahfeiWong]

Great, I'll test it when I have time.

[WahfeiWong]

Hi Patrick, due to time constraints, I did not conduct in-depth testing this time. I only briefly checked the initial configuration files generated by the UMCF0.0.28beta version for OpenFOAM solvers and found the following issues that still exist:

1. The input for LAD is invalid (the 0/air/LAD file always uses the default value of 1 for LAD);
2. The input for aerodynamic roughness length z0 is incorrectly mapped to the zground parameter (the 0/air/U file). Perhaps adding a zground input in the ABL condition component would be better.

Best.