thanks for your reply. The problem is not with getting the wind speeds - I’ve got it from the CFD simulation and can synchronise it with the grid points.
The issue is the UTCI components, in my understanding, not allowing to assign wind speed for every point (UTCImap) or can handle only the Opaque shading object (UTCI).
P.S. I’m trying to simulate a case with glazed partitions and overhangs, protecting from the wind and solar radiation.
Hi @dmitry ,
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.
In the legacy version it was accepting the Wind factor annual
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?
@chris I am using Eddy3d for cfd and outdoor comfort metric
This was the result with and without cfd in UTCI
Hi @chris ,
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:
… 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.
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!
Hi @chris . I have attached a sample file with internalised test probe points and annual wind factor from eddy3d. Can you pls help me to create the excel file with appropriate format. I have also sent you the full eddy script also in private message for your reference in case you need it.
https://drive.google.com/drive/folders/1sVgOLA0VAoF4-xfjLKyLioH1SMgVqQ5-?usp=sharing
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:
Here’s the GH file with all of your data cleared out of it such that it’s small enough to upload:
UTCI_CFD_Energyplus_LBT_CWM.gh (222.9 KB)
I really hope the Eddy people add some way to access these wind speeds that doesn’t involve loading them all into the Grasshopper UI.
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.
Hi @chris,
I am trying to input a different wind speeds for each test probe points using the component “Write Wind Speed”. Is there a format for assigning data into “Annual wind speeds”?
Hi Team,
Please can you explain this in more details. How the recipe look like and the CSV format itself look like.
It is highly appreciated if you should step by step how to put the wind speed point by point to run UCTIMap.
Thanks,
Hello @chris
thanks for your work of combination of cfd and utci! It works well at version LBT 1.5 for me.
However, something wrong happened when I updated to LBT 1.6.0. Below is screenshot in GH.
I’ve also checked the log data. The problem maybe about “utf-8” code. Please check the screenshot below.
How can I fix it or would you please provide another suggestion?
Thanks in advance!
Already solved because the flip matrix of air speed in *.csv
