Surface Temperature under reflected solar heat gain

Starting from this post I tried to calculate potential thermal discomfort in an outdoor environment due to the reflectance that comes from a new building. I created the annual radiation profiles per the solar radiation analysis and input them to the outdoor solar temperature adjustor component, but the component doesn’t like it and gives me the error: “1. Solution exception:One or more errors occurred.”

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

Is anyone able to help me with this error. Thank you in advance!

@Mili ,

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: (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.

1 Like

@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:

Let me know and thanks in advance!

@Mili ,

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)

1 Like

@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 sorry to bother you again, but I tried again and again to restart and update LB/HB+ but with no luck.
My set up is

  • Rhino 6.1
  • LB+ 0.0.04 11 mar 2019
  • HB+ 0.0.05 10 mar 2019
  • Ironpython 2.7.3
    Any tip?
    Thanks in advance

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:

  1. Solution exception:HourlyContinuous

Which in the code corresponds to:

line 827, in get_aligned_collection, “C:\Users\Abraham\AppData\Roaming\McNeel\Rhinoceros\6.0\scripts\ladybug\”
line 56, in _get_coll, “C:\Users\Abraham\AppData\Roaming\McNeel\Rhinoceros\6.0\scripts\ladybug_comfort\”
line 551, in effective_radiant_field, “C:\Users\Abraham\AppData\Roaming\McNeel\Rhinoceros\6.0\scripts\ladybug_comfort\collection\”
line 67, in script
The files are updated to today, but i noticed that the ghuser file was not downloaded.

Any ideas?


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 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.


@AbrahamYezioro ,

I got the chance to touch base with @mostapha today and we fixed all of the issues. If you update and restart again now, everything should work.


Thanks @chris and @mostapha,
Now it works smoothly. Nice.

There are issues with some of the weather files on my location, but i will post at the github.
Thanks again,