Ok, I just merged a version of the component that can accept a folder of air speed values that align with the sensors. After you run the Versioner and restart Rhino, you’ll see that you can plug the folder into the _wind_speed_ input of the recipe:
… and this is what the folder should look like in relation to the model sensor grids:
It looks like the Edddy team did a good job making it easy to run OpenFOAM simulations when the meshing isn’t complex and everything is aligned to the mesh grid. So I’m happy people have an easy option to account for wind in these cases.
I hear what you are saying, @dmitry , but we expect this input to be used for many cases beyond simulations of short time periods and the Grasshopper interface will get incredibly slow if you try to input air speeds for an annual simulation with 1000 sensor points (that’s over 8 million air speed numbers that would be in the Grasshopper UI). So, if you really needed something like this, I’d much rather write a custom GHPython component with a few lines of code that can take Data Trees output from Eddy and write them to a CSV that you can then plug the parent folder of into the recipe. If someone internalizes an Eddy DataTree of hourly air speed values along with some sensor points (aka. OpenFOAM probes), I can put together a sample showing how you can format them for input to the UTCI recipe.
And, yes, @Asisnath . The wind is pretty important to outdoor comfort. As you might already know, it was the next-most important thing after sky heat exchange in some simulations I helped run a long time ago to help understand what is most important for outdoor thermal comfort mapping.