Sorry for the late response here. I know that this type of capability of integrating CFD results is in high demand and I’m working towards exposing it. In fact, this ladybug-comfort mtx utci command that’s being run under the hood of the UTCI recipe already has an input for --air-speed-mtx, which is meant to take an input exactly like what you have there. I just have to expose it on the recipe inputs but this presents some questions.
For example, I’ve been trying to find the best way to handle cases like multiple sensor grids. Should I expect an input of multiple air speed CSV files in this case? So you have one CSV file per sensor grid? If you have any thoughts on this, please feel to share them.
In the meantime, I can give you a workaround for postprocessing the UTCI comfort map results in Grasshopper to include your CFD air speeds. I just added a component that can parse the raw MRT results from the comfort map into Grasshopper:
So you can use the Ladybug “UTCI Comfort” component to post-process the raw MRT results as you wish:
You’ll just have to format your CFD wind speeds as a list of data collections in order to plug them into the _wind_vel_ input of the UTCI component. It’s by no means optimized for speed or scale-ability but at least you can do it.
Unless anyone has any thoughts on this, I’m going to implement it in a way that you need to plug in a folder for wind speeds and this folder must contain a CSV matrix for each sensor grid in the model. Each CSV file must have a name matching the identifier of the grid in the model.
This method could be a bit more prone to errors and typos but it will allow people to keep things organized into different sensor grids if they need to perform analysis separately on each grid.
Hi @chris. Once I had worked out a script with Legacy version of HB UTCI and it was accepting the wind factor annual. I read your conversation above, if you are implementing the way you said above will the output from the CFD component (as in image below) as shown in the image below will work? I can share that script personally if you want.
The short answer is that you’ll be able to get integrate whatever CSV you want as long as you format it with the parent folder as the input and you coordinate the CSV file name with your Honeybee model.
What plugin are you using to get wind speeds there?
Thanks so much four your reply and an update of the UTCI map component! This is exactly what I was looking for and now I’ll be able to overcome the limitations I had earlier!
As per the thoughts on the format for the wind speed matrixes: a folder with a CSV matrix for each sensor grid will do and seems to be a quite universal workflow. However, I would consider just accepting a tree of values of the wind speed matrix as an input, where each branch represent a sensor grid. It would be easier to implement and would not require additional steps of saving the CFD results from GH to CSVs to import it back, if the CFD workflow is already inside GH. I’m using Eddy3D and the wind speed matrixes are in GH. In any case, it is easy to parse the CSV files into the GH trees if needed.
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:
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.
Superb @chris . This is great. As you said I will be replicating the old legacy UTCI script that worked with eddy3d output with lbt tool. I will post the working script here as an example for you to check. I am on it. Thanks again!
Man, that Grasshopper sample is quite slow. I think 3 million numbers must be close to the limit of what the Grasshopper UI can easily handle. It took me a while waiting every time I connected something new to a component but here’s a component that writes all of these values to a CSV you can use in the recipe:
I’m doing research in this field recently. The wind speed data obtained in CFD forms a CSV file. If you put CSV files into HB UTCI for simulation, infinite repeated simulation will be generated.I don’t know why.