Traceback:
line 1476, in parallelMRTCalc, “”
line 1486, in mainSimple, “”
line 1543, in script
Note that the component works fine with the cumulative sky matrix and with radiation that comes straight from the import epw component.
Thank you for your help
I apologize for the incredibly late response here. I had this post up as a tab in my browser for over a week as I wanted to get take the time to answer it correctly (sorry again it took so long). This type of reflection-heavy solar adjusted MRT calculation in the old file that you reference has gotten a lot easier, more powerful, and more accurate in the [+] plugins. This is not only because @mostapha and @sarith designed the Honeybee[+] Annual recipe to be able to return separate values for direct and diffuse radiation but also because I recently re-designed the SolarCal methods to be able to estimate solar-adjusted MRT using horizontal components of direct and diffuse radiation.
Here you can find a Grasshopper definition that uses these most-recent capabilities: HBPlus_SolarAdjusteMRTExample.gh (510.4 KB)
Note that you must have the latest version of the Honeybee[+] libraries on your system to be able to run it and, for most users, this involves re-running the HoneybeePlus Installer component and restarting Grasshopper a couple of times.
Here, you can see that we can even produce time-lapse images of the MRT over the course of a day using the new components:
With all of this said, I want to point out that THE NAME OF THIS POST IS MIS-LABELED. This is because mean radiant temperature is NOT surface temperature. Radiant temperature is a theoretical concept and you can think of solar-adjusted radiant temperature as an answer to the question “what would happen if I took a thermal camera and pointed it directly at the sun?” The reading that you get from your camera isn’t the temperature of the camera lens and this is analogous to the fact I stated earlier: that Mean Radiant Temperature is not surface temperature. However, solar-adjusted MRT gives you an idea of the sun’s contribution to the someone’s overall thermal sensation, which is probably closer to an average between the air temperature and radiant temperature (though it ultimately depends on a wide range of factors including the time someone is in the sun, the air speed, etc.).
If you need actual surface temperature, there is probably a way to do it with the E+ object that I mentioned in this discussion but that is an advanced topic for another discussion.
Thank you @chris or your response. I was starting to worry that my post wasn’t clear enough but I am glad you took the time anyway. I see now that the post is mislabeled, the truth is that I just copied the same label from the discussion I am quoting at the beginning of the post without paying much attention. I will take a look at the HB+ component and the definition you sent on Monday and I will let you know how it worked. I am glad there is an easier way now.
I did some E+ calc at the beginning using another workflow you describe in one of the Performance Network presentations that is for exterior spaces, since my analysis here is for exterior, but I soon realized that this workflow we are discussing here fits better my question at hand.
Thanks for your time again
Mili
Thanks again for your patience with our response. I know that the title of the post was derived from the old Grasshopper forum one and it’s ok to leave it that way for the sake of aligning with search terms. That’s why I wanted to include a clear message to others visiting this post that we aren’t actually calculating surface temperature here.
Using E+ can help you get surface temperatures but E+'s built-in ray tracing methods to calculate solar radiation aren’t nearly at the level of Radiance. So they really are not the best tool in the shed for situations like this one where reflected solar is so important. Running a Radiance study and using that to input radiation to E+ through E+'s SurfaceProperty:SolarIncidentInside object would be the state-of-the-art but, again, that is an advanced topic that merits its own discussion. We can cross that bridge when someone has a question about it here on the forum.
@chris, I tried the workflow you suggested and it works perfectly for what I wanted to achieve. I have one more question: The MRT and MRT delta values seem to be very high both in your example and in my project. How would you interpret numbers between 50 and 70C? Thank you again for your response
@chris many thanks for your wonderful work!
I tried to update LB/HB+ but with no luck…
I am not able to get the latest release of Ladybug+ as well as LadybugPlus_Outoor Solar MRT component (release 27/4/2019).
This is the message I get:
These temperatures are not ureasonably that high for solar-adjusted mean radiant temperatures. Remember what I had mentioned that radiant temperatures are not surface temperatures (or the temperature of any object for that matter). The temperatures of the actual objects under the reflected heat are likely closer to the operative temperature, which will make them only 35C warmer than the surrounding air rather than 70C.
It’s also worth noting that the object in the example simulation that I ran is really reflective (90%). Most common reflective objects that you find in the outdoors will have half of that reflectivity.
@alberto.bruno . You have to restart rhino/grasshopper and run only that component twice (there have been a lot of updates recently)
@chris ok, this makes sense. I assume that the workflow could continue with the utci component to better communicate the implications on comfort. I am attaching an image showing that. it seems to make sense
Hi @chris,
I want to add to @alberto.bruno, that i also tried quite a few times. At some point the component turned workable (from red).
Now it complains about:
Solution exception:HourlyContinuous
Which in the code corresponds to:
Traceback:
line 827, in get_aligned_collection, “C:\Users\Abraham\AppData\Roaming\McNeel\Rhinoceros\6.0\scripts\ladybug\datacollection.py”
line 56, in _get_coll, “C:\Users\Abraham\AppData\Roaming\McNeel\Rhinoceros\6.0\scripts\ladybug_comfort\collection_base.py”
line 551, in effective_radiant_field, “C:\Users\Abraham\AppData\Roaming\McNeel\Rhinoceros\6.0\scripts\ladybug_comfort\collection\solarcal.py”
line 67, in script
The files are updated to today, but i noticed that the ghuser file was not downloaded.
I think a lot of the issues that @AbrahamYezioro and @alberto.bruno are experiencing result from the fact that the updater component has been updated itself. Also, it only works correctly if you drop the update component on the canvass and only run it once, then you restart Rhino Grasshopper. The updating process has gotten a bit more complex for the + plugins and this is compounded by all of the changes that have been made in the last few months. For this reason, I think a lot of the issues @AbrahamYezioro and @alberto.bruno are experiencing will be addressed when they start from a new stable release, which we can hopefully push to Food4Rhino in the not-too-distant future.
@AbrahamYezioro , the specific issue that you are facing now was the result of a recent bug that has been fixed in the init.py file in the ladybug core libraries. I would suggest you run the update component one more time and restarting but I see that @mostapha pushed a bunch of changes to honeybee core in the last few days, which have created new incompatibilities with the honeybee grasshopper components. So my response to this issue was probably premature and it may be best to wait a bit until our development is a bit more stable.
In the meantime, @Mili, I am glad you at least got a working version out of this for now and what you are doing for the comfort analysis is the correct workflow. If you want to do an analysis that is true to the EPW, file, though, you might want to replace the ASHRAE Clear Sky WEA I used in the sample file with one that is derived from the EPW’s radiation values (You will see that there’s a component for that under the ‘Light Sources’ tab.
@AbrahamYezioro and @alberto.bruno - it also took me some time to get this run without any errors. It is hard to recall which exact move did the trick, I remember replacing .py files in the scripts Rhino folder and also re-bringing some components to the library folder and one of those tries worked.
@chris I tried to use the actual wea file I got from the weather file, but I got this error: 1. Solution exception:AssertionError . I tried a couple of different locations to make sure it is not the file’s problem but I got the same error for all. Using the TauClearSky component didn’t create the error and I was able to run it
Hi @chris,
I decided to give it a rest for some time. I did update today and some other components are not working now. I suppose it is because the work in progress. I’ll try in a few days from now. Is not that i need this utilities, but just wanted to test.
Hello there, please excuse me for the reply after 2 years.
Is there any new progress about SurfaceProperty:SolarIncidentInside or the function related to it?
Thank you in advance!
The entire workflow described in the file I posted in this part of this topic has been wrapped into the latest Comfort Mapping recipes of the LBT plugin. So you can use those comfort maps if you want to run the simulation described above and understand the temperatures people would experience in a particular location in an urban environment.
I’ll also just note that the method we use to estimate shortwave solar irradiance over time doesn’t do the best job of modeling reflected solar energy since it diffuses the direct-reflected sun over a few sky patches. You can get around this by running a point-in-time irradiance simulation and feeding the results into the Solar MRT from Solar Components component like so:
