Is there a way to speed up the calculation process?

When I first opened this, I thought it looked familiar. Searching through your past threads, and I see that I have looked at this spreadsheet before.

First thing I had to do was run through a few iterations (repeatedly press F9) to clear the errors from the sheet.

Having recognized the sheet, I knew I did not want to try to reverse engineer the circular references again, so I assumed the sheet was structured correctly.

Then I started looking at the UDFs. I notice that all of them have application.volatile in them, which can slow things down. A quick look at the code suggested to me that they did not need to be volatile, so I removed the volatile statements from them. This seemed to improve calculation times a little, but not dramatically. I also have no idea if the calculations are correct or not, so could not tell if removing the application.volatile had an adverse effect on the accuracy of the calculation. As good practice, I would determine if these need to be volatile or not. If they do not need to be volatile, then remove the application.volatile statement. If they do need to be volatile, figure out how to code the procedures so they won't need to be volatile.

The next thing I did was to check if there are numeric algorithms (involving loops which can be very slow if the algorithm requires many iterations to converge). I found what looks like a bisection algorithm in function WetBulb() and what looks like a brute force algorithm in function Tinput2cfm1(). I put a Stop statement after the For counter=1 to 1000..Next counter loops in Wetbulb as well as after the Do While..Loops in Tinput...() so that it would enter debug mode at those points in those procedures. I observe that the brute force loops in Tinput...() are consistently taking about 70 iterations to terminate. Even worse, I observe that the bisection loops in WetBulb() are often (well over half of the function calls) taking all 1000 iterations before terminating. When these loops did terminate normally, they were taking about 50 iterations.

This looks to me like a major bottleneck. I would probably proceed by trying to figure out why the bisection loop is not terminating normally. I have not looked in more detail, since I don't understand the engineering behind these calculations and didn't want to get lost in things I don't understand. If you can get this part of the procedure to terminate in 50 iterations rather than 1000, that should improve your calculation times.

Then I might ask myself if bisection is the best algorithm here, or if I could possibly use a Newton-Raphson type algorithm that would normally converge in fewer iterations. I might also ask myself if brute force is really the only suitable algorithm for Tinput...().

I don't expect you will ever get 8600 copies of this calculation to calculate near instantaneously. But debugging/improving those two procedures should dramatically improve calculation times.