Firstly I want to thank you for developing such an amazing grasshopper plug-in for airflow analysis. This has saved a lot of computation cost for my annual wind analysis.
I have a serious problem in the multi-direction wind analysis these days. After replacing my urban geometries in the Brep, I saw the simulation ran into the forced termination. This never happened before. I have also tried to boolean unioned all the geometries to see if the problem was caused by ‘shared wall’ between single building objects, but the simulation was forced into termination too.
Could you help to point out the bug for me? I assume that the problem occurred due to the geometries. Thank you so much! (attached are two gh files, with unioned and ununioned geometries internalised in the file)
I spend some time looking at it and I also can’t get your case to run; there must be something up with your geometry although it looks very clean. Although I can’t help you, I do have a suggestion on how to debug it systematically.
I would divide your geometry into quadrants, run them separately, and see if they run through on their own. If one doesn’t you know the problem is within that quadrant. Divide that quadrant into 4 sub quadrants and repeat that.
If all 4 quadrants run separately (unlikely), put the quadrants back together piece by piece and see which part introduces the problem when merged.
I’m sorry that I don’t have better news for you. If you decide to go through this, I’d be glad if you could tell us what the problem was. I’m sure we could all learn from it to avoid the issue in the future
Thank you very much, Patrick, for spending time testing my model.
I somehow found the bug, though could not ensure you that is the case. The termination of the simulation might be caused by the oversized urban context.
In the urban sample ‘000’, I have tried to scale down the simulation area from a diameter of 700M to 600M, and the 600M boosted the simulation. The geometries of 700M, which was sent to you yesterday, was failed. The same situation occurred in another sample named as ‘003’. Please see attached the gh file containing these four geometries (two worked, other two did not). Therefore, I assume the problem is from the spatial scale.
I would be grateful if you can continue debugging this issue. A larger domain is needed. A diameter of 600M seems not enough for me. After cutting off 100M at the periphery, it left me only 400M of useful data.
Therefore, I assume the problem is from the spatial scale.
That is likely not the case, I ran much bigger models than yours successfully.
I would be grateful if you can continue debugging this issue. A larger domain is needed. A diameter of 600M seems not enough for me. After cutting off 100M at the periphery, it left me only 400M of useful data.
I can confirm that your case works with the smaller geometry (green), see below.
What that means, in my opinion, is that you have some faulty geometry in the outer perimeter (red).
I unfortunately can’t help you locating where the exact issue is but it certainly has to do with the geometry/mesh. One way would be to remove parts of the outer perimeter (red) piece by piece until the simulation starts working.
Kai, I also wanted to add that you definitely have to increase the number of iterations and monitor the residuals. Your case will certainly not be converged after 200 iterations. You’ll probably need on the order of 2000-3000 iterations (but please confirm with residual plots that you indeed have a converged case).
You want to find yourself within the red rectangle, similar to this one (again, your iteration count will be much higher):
Blockquote in my opinion, is that you have some faulty geometry in the outer perimeter (red).
Thank you, Patrick. You are right - the malfunctioning is caused by geometry, rather than the scale. However, I followed your instruction, quadrant by quadrant, scaling down to the problematic area with 9 building blocks, which can’t get the model to run (see attached the image). I have checked all 56 closed Breps in it, individually, all fine for simulation. HOWEVER, when I selected some of these individual Breps as combinations for simulation, it crashed from time to time. It is very inefficient for me to use this ‘scale-down’ method for hundreds of combinations of individual Breps, isn’t it? Individual_check.3dm (3.7 MB)
Blockquote Your case will certainly not be converged after 200 iterations. You’ll probably need on the order of 2000-3000 iterations
Thanks for sharing this for checking the convergence! I got a question… How to plot the Convergence progress? Is it from the residual component in Eddy3D?
An extra question: Is it okay to rewrite the simulation output folder everytime without cleaning? My grasshopper always crashed when clicked the clean button, unfortunately. Then I tried to delete some failed output manually, and my desktop was immediately forced to restart.
HOWEVER, when I selected some of these individual Breps as combinations for simulation, it crashed from time to time. It is very inefficient for me to use this ‘scale-down’ method for hundreds of combinations of individual Breps, isn’t it?
I agree. I hope that a new version of BlueCFD (hopefully based on OpenFOAM 8) will increase meshing quality and stability. You can find the current progress here. In the meantime, if you happen to find mesh settings that seem to be more reliable, I’d be happy to make some adjustments to the tool.
I got a question… How to plot the Convergence progress? Is it from the residual component in Eddy3D?
Yes, the residual component helps you to do that.
An extra question: Is it okay to rewrite the simulation output folder everytime without cleaning? My grasshopper always crashed when clicked the clean button, unfortunately. Then I tried to delete some failed output manually, and my desktop was immediately forced to restart.
I’d recommend cleaning the folder if you can (sorry that there might be a bug, I’ll try to fix that for the next version). If your GH crashes, feel free to delete the constant folder (mesh) and all numbered folders (simulation results) by hand and recompute your GH solution.
Thank you very much Patrick! I will wait for the new version.
I succesfully ran some new cases (modern urban fabrics). I really fancy the Annual-wind-comfort componant, which gives annual result based on 8760 hourly data. Could you guide me how to get the seasonal results, if it is possible to decode that componant and divide 8760 data into four time seires?
Meanwhile, I have followed your tutorial video, using ‘DeData’ component to calculate the wind comfort on a specific day scaled by NEN 8100 standard. I have tried to input four series of 2190 hours in four seasons to ‘DeData’. However, there are two problems: (1) It costs 20 minutes for calculation, compared to the ‘annual-wind-comfort’ only with a few seconds (2) I am not sure how to calculate seasonal wind comfort by Lawson LDDC, or Davenport standard (3) Would it possible to dispatch data into daytime and nighttime (the day time hours change everyday)?
Could you guide me how to get the seasonal results , if it is possible to decode that componant and divide 8760 data into four time series?
I think you are doing everything correctly in your example.
I have tried to input four series of 2190 hours in four seasons to ‘DeData’. However, there are two problems: (1) It costs 20 minutes for calculation, compared to the ‘annual-wind-comfort’ only with a few seconds
As a rough approximation, in my case DeData takes 13 s for 2813 probes. You are looking at 20k x 8760 = ~175e6 observations! Grasshopper is known to become rather slow for large DataTrees and lists. I’d recommend decreasing the number of probes in your case.
(2) I am not sure how to calculate seasonal wind comfort by Lawson LDDC , or Davenport standard
