SET Comfort error when analysis period grater than 5 months

Mostapha and Chris,

I am using the SET Comfort component from your YouTube presentation, but when I plug-in a Analysis Period larger than 5 months the component crashes and the error balloon says: “1. The calculation has been terminated by the user!”

Same behavior if I don t plug-in any Analysis Period.

Is that a bug or some other logical limitation?

I attach the relevant images and GH file.


Dimitris (474 KB)

Interesting Dimitrios,
Just to stress a bit more the issue, it happens when the MetabolismRate is higher than 2.3. Up to this Met value it works.
I suppose such a high values causes some division by 0 in the calculations at some point, and that’s why it fails.

Thanks for reporting Dimitrios and, Abraham, your instincts are very close to the problem. You are absolutely right to point out that the issue is not with the analysis period but with the data that the analysis period includes.

To be perfectly honest with you guys, this is an error that I have know about for a while. It happens when you have both a very high wind speed and a high metabolic rate is fed into the PMV function, which can happen if you have an hour of your weather file that is in an intense storm and you hook up a high met activity like walking. The original PMV model was not meant to handle these very extreme cases (being derived from climate chamber tests) and it is only through some mathematical tricks that scientists have found ways of gradually converging on a solution that describes these cases. Unfortunately, sometimes, this iterative process flies off the handle instead of converging on a solution and so there is another mathematical trick that has to be used to find the solution. What was happening here was that the initial function was not recognizing when this flying off the handle was happening in order to pass on the results to the other mathematical trick.

I probably should have addressed the issue a while back but I knew that it was an issue in the original code that I got from the ASHRAE model inside the CBE tool ( and it felt a bit wrong to edit code that is a part of the standard. I see now, though, that it was really just a matter of recognizing that the result was flying off the handle and passing it to the next function so I do not feel so bad about making this change.

Attached you can find your fixed file and an updated PMV and LB_LB component is now on the github.

-Chris (475 KB)

Hi all! Very interesting.

Chris, I have two minor comments that you may want to consider.

  1. I think you need to catch the errors either in smaller part of the code or by considering type of exception so you can give a more related warning/error message.

  2. You may also want to give a warning to the user in cases that you are using the alternate methodology.


Wow very interesting!

Thank you very much!

Works great!


To clarify my comments, the fix that I made here still ensures results that are in line with ASHRAE 55 PMV Standard. As such, I think it is a bit unnecessary to alert people to the exact method by which the PMV values are reached since the calculation is considered valid by a large scientific consensus and by ASHRAE. The slight difference in methodology seems to have to do more with historical reasons for how the PMV model was developed and the fact that the human body takes a while to reach equilibrium when in conditions of high wind.

To clarify further, an iterative method is used to calculate PMV any time that the wind speed is above 0.15 m/s. The original published PMV model was done in climate chambers and was made to describe indoor environments where wind speeds above this were uncommon. As people began to adapt the PMV model to help understand outdoor conditions and to develop OUT_SET, an iterative methodology was developed to help calculate values in conditions of high outdoor wind.

Let me know if this is clear,