I’m trying to analyze the UHI behavior in LCZ1 using a GH parametric block model created for in the range of LCZ1 geometric and surface covers for my final year thesis
I’m almost done with my city model and first tried testing with the provided Urban_Weather_Generator_Workflow.gh located in the Dragonfly-master\resources, folder. All the other components seem to be working but RunUWG component does not give any output when the toggle is set to true. I tried everything possible but no response
Installed the Matlab compiler 9.0 (64-bit) and UWG works in manual mode
CCWorldWeatherGen is installed to the C:\CCWorldWeatherGen folder and HadCM3data folder is in there.
Python 2.7.15 is installed on the system
IronPython2.7.8 is installed on the system
Running on windows 10
@Dilushan, the reason the RunUWG component isn’t working is because it hasn’t been written yet. You’re looking at the work-in-progress .ghuser objects that was being used to test and prototype the next Dragonfly release.
If you are able to wait until the new release, all of this should be solved and you can do your UHI simulations. @chris is working on this right now, and he can give you a better idea of when the release date will be. It should be a few weeks or less(?).
As for your dependencies, in the new Dragonfly we’re not using the matlab-based UWG engine, so you won’t need the UWG exe, or the Matlab compiler. The IronPython 2.7 that is packaged with Rhino 6 will do everything.
@SaeranVasanthakumar Thanks for the reply. Yes, unreleased version, but I thought it’s like a beta version and didn’t know it’s incomplete My final submission is due to 07th of June, so it’s not possible to wait for a couple of weeks, possibly I can wait a week, while completing the literature review in the meantime.
So I guess I have no choice but to stick with the version 0.0.01, but the thing is, it gives me the same FATAL ERROR message cristina_mg was talking about in another post.
Is there any way to get it working?
Ah, then the main problem is the FATAL ERROR. I can’t guarantee we have a solution for that yet (even with the new Dragonfly), but if you attach your grasshopper file, with geometries internalized, I can take a look at it.
When I was trying to refine themodel to attach, I found that it works for some parametric values of the model.
This parametric model represents the properties of a basic city block for Local Climatic Zone 1, When I ran the UWG for a single city block, it came with the FATAL ERROR.
Then I tried an array of 9 blocks, (with same input values) It worked fine.
But for some changed input values, it shows the FATAL ERROR and the rest works! (around 50% of iterations).
It is not clear to me what’s causing the problem, much appreciated if you could give some suggestions on how to avoid/minimize the FATAL ERROR situations.
@Dilushan ,
I’m glad that @SaeranVasanthakumar was able to answer the question and, yes, the fatal error is the big reason why there hasn’t been a formal release of Dragonfly on Food4Rhino. The error isn’t likely to be fixed yet in the Python version of the UWG that @SaeranVasanthakumar has built but, since him and I understand the UWG code now, we can hopefully at least catch the exception and find some better way of dealing with it than totally abandoning the simulation.
Dragonfly 0.0.2, which will work with the python UWG should be available in 2-3 weeks (the minimum viable prototype is almost there).
In the meantime, you might have to find a better way of getting at the question you are trying to answer (like only running the UWG for a typical week rather than the entire year).
I’ve been suspecting for a while that there may be a some intrinsic problem with the xml input that is compounding the FATAL ERROR issue. I’ve been working a lot with the .m file input methods and have yet to run into the particular error, it’s only come up when I use the xml method. The only thing preventing me from confirming this right now is that I’m unable to read the xml files on my matlab due to some bug, or some version incompatibility.
However, in this case, I can confirm that I ran Dilushan’s epw file, and an approximation of his urban configuration with a custom .m file input, and the UWG_Matlab version worked fine.
@Dilushan this FATAL ERROR bug may take a while to sort out. If you need an immediate method of simulating the UHI, one potential solution we can try is to use the underlying urbanWeatherGen simulator directly.
This method lacks the customization of building typologies (both in terms of geometry and non-geometric energy model inputs) that Dragonfly has, but if your urban block geometries are simple enough that you can derive the input parameters seen in the example below, and you are okay with using the building material/systems properties defined in the DOE Reference buildings for the actual energy simulation, it could potentially work. Let me know if this is something you might be able to do, and we can test to see if this might side-step the bug.
@SaeranVasanthakumar Finally got it fixed! The issue was caused by ignoring the area under the building footprints to the pavementBreps. After counting the footprints for the pavement input, it didn’t give me a single FATAL ERROR yet. Then only I read the input note and realized it has mentioned there, to add them. Everything is working fine now.
Thanks very much for the support.
@chris It is much convenient PavementBrep input has already changed to input the terrainBrep and only the grass-cover surfaces separately in the UWGcity component now. Waiting for the next release. Thanks!
My final submission is due to 07th of June, so it’s not possible to wait for a couple of weeks, possibly I can wait a week, while completing the literature review in the meantime.