on for curves, if you make an algorithm that dynamically defines the possition of the controlpoints for NURBS curves as a function of the parameteres in F(t, a1,...,b1,...,c1,...)= x(t, a1, a2...)+y(t, b1, b2...)+ z(t, c1, c2...) or F(x, a, b ,c...)?
…
dred 500x500 images using blurring radii smoothly ranging from 2 to 200 pixels. Ie. about 650 milliseconds for a blurring radius of 200 pixels, and ~10 milliseconds for a radius of 2 pixels.
During the process, my CPU load varies between 80% and 90%, but that includes all the stuff the system is doing (always a few percent).
…
rkup) as below:
float coeff_perez [] is from Perez's paper in solar energy vol. 50, No.3. pp235-245, 1993.
i would like to adjust A3, A4, A5, A6 and A7 using measurement irradiance data over a whole year for every minute or hour, and update these coefficients under the file perezlum.cal. It means i may need to re-compile gendaylit.exe, which i have no idea how to do it.
i found radiance has another version on gendaymtx.c v2.13. it includes static const double PerezCoeff[8][20]. I am wondering which version of gendaymtx does ladybug GenCumulativeSkyMtx use.
Thanks for your suggestions on honeybee plugin. I will take a look and see how.
Cheers,
Le
…
be done easier, but later on the geometry will change and therefore this seems the better option. But coming back to the problem
First, there were some problems concerning the zone, although it seems solved still the “runenergysimulation” gives the following warning:
1. The simulation has not run correctly because of this severe error:
** Severe ** UpdateZoneSizing: Cooling supply air temperature (calculated) within 2C of zone temperature
Do one of you know what went wrong? It probably will solve most of it.
Second, “set Zone Thresholds” gives the following warning:
1. Solution exception:global name 'maxHumidity_' is not defined
However, the component is missing the max humidity input on the list, has this to do something with the error?
All the components are up to date.
I hope it will be an easy fix.
Gr Lars
“set Zone Thresholds” runtime error
{0;0;0}0. Runtime error (UnboundNameException): global name 'maxHumidity_' is not defined1. Traceback: line 80, in checkTheInputs, "<string>" line 282, in script
"runenergysimulation” report
{0;0}0. Current document units is in Meters1. Conversion to Meters will be applied = 1.0002. TypeError('Waarde kan niet null zijn.\r\nParameternaam: source',)3. Failed to copy the object. Returning the original objects...This can cause strange behaviour!4. [1 of 8] Writing simulation parameters...5. [2 of 8] No context surfaces...6. [3 of 8] Writing geometry...7. [4 of 8] Writing Electric Load Center - Generator specifications ...8. [5 of 8] Writing materials and constructions...9. [6 of 8] Writing schedules...10. [7 of 8] Writing loads and ideal air system...11. [8 of 8] Writing outputs...12. ...... idf file is successfully written to : c:\ladybug\unnamed\EnergyPlus\unnamed.idf13. 14. Analysis is running!...15. c:\ladybug\unnamed\EnergyPlus\eplusout.csv16. ......
Done! Read below for errors and warnings:
17. 18. Program Version,EnergyPlus, Version 8.3.0-6d97d074ea, YMD=2016.03.02 20:55,IDD_Version 8.3.019. 20. ** Warning ** IP: Note -- Some missing fields have been filled with defaults. See the audit output file for details.21. 22. ************* Beginning Zone Sizing Calculations23. 24. ** Warning ** GetInternalHeatGains: People="CLASSROOMOFFICEPEOPLE", Activity Level Schedule Name values25. 26. ** ~~~ ** fall outside typical range [70,1000] W/person for Thermal Comfort Reporting.27. 28. ** ~~~ ** Odd comfort values may result; Schedule="SCHOCCUPANCYSCHEDULE".29. 30. ** ~~~ ** Entered min/max range=[0.0,1.0] W/person.31. 32. ** Warning ** Calculated design heating load for zone=CLASSROOM is zero.33. 34. ** ~~~ ** Check Sizing:Zone and ZoneControl:Thermostat inputs.35. 36. ** Severe ** UpdateZoneSizing: Cooling supply air temperature (calculated) within 2C of zone temperature37. 38. ** ~~~ ** ...check zone thermostat set point and design supply air temperatures39. 40. ** ~~~ ** ...zone name = CLASSROOM41. 42. ** ~~~ ** ...design sensible cooling load = 25499.10 W43. 44. ** ~~~ ** ...thermostat set point temp = 0.000 C45. 46. ** ~~~ ** ...zone temperature = 15.334 C47. 48. ** ~~~ ** ...supply air temperature = 15.000 C49. 50. ** ~~~ ** ...temperature difference = -0.33433 C51. 52. ** ~~~ ** ...calculated volume flow rate = 197273.21341 m3/s53. 54. ** ~~~ ** ...calculated mass flow rate = 237634.19357 kg/s55. 56. ** Warning ** ManageSizing: For a plant sizing run, there must be at least 1 Sizing:Plant object input. SimulationControl Plant Sizing option ignored.57. 58. ************* Testing Individual Branch Integrity59. 60. ************* All Branches passed integrity testing61. 62. ************* Testing Individual Supply Air Path Integrity63. 64. ************* All Supply Air Paths passed integrity testing65. 66. ************* Testing Individual Return Air Path Integrity67. 68. ************* All Return Air Paths passed integrity testing69. 70. ************* No node connection errors were found.71. 72. ************* Beginning Simulation73. 74. ************* Simulation Error Summary *************75. 76. ** Warning ** The following Report Variables were requested but not generated77. 78. ** ~~~ ** because IDF did not contain these elements or misspelled variable name -- check .rdd file79. 80. ************* Key=*, VarName=ZONE PACKAGED TERMINAL HEAT PUMP TOTAL COOLING ENERGY, Frequency=Hourly81. 82. ************* Key=*, VarName=ZONE PACKAGED TERMINAL HEAT PUMP TOTAL HEATING ENERGY, Frequency=Hourly83. 84. ************* Key=*, VarName=CHILLER ELECTRIC ENERGY, Frequency=Hourly85. 86. ************* Key=*, VarName=BOILER HEATING ENERGY, Frequency=Hourly87. 88. ************* Key=*, VarName=FAN ELECTRIC ENERGY, Frequency=Hourly89. 90. ************* Key=*, VarName=ZONE VENTILATION FAN ELECTRIC ENERGY, Frequency=Hourly91. 92. ************* Key=*, VarName=EARTH TUBE FAN ELECTRIC ENERGY, Frequency=Hourly93. 94. ************* Key=*, VarName=PUMP ELECTRIC ENERGY, Frequency=Hourly95. 96. ************* Key=*, VarName=ZONE VENTILATION TOTAL HEAT LOSS ENERGY, Frequency=Hourly97. 98. ************* Key=*, VarName=ZONE VENTILATION TOTAL HEAT GAIN ENERGY, Frequency=Hourly99. 100. ************* Key=*, VarName=EARTH TUBE ZONE SENSIBLE COOLING ENERGY, Frequency=Hourly101. 102. ************* Key=*, VarName=EARTH TUBE ZONE SENSIBLE HEATING ENERGY, Frequency=Hourly103. 104. ************* EnergyPlus Warmup Error Summary. During Warmup: 0 Warning; 0 Severe Errors.105. 106. ************* EnergyPlus Sizing Error Summary. During Sizing: 3 Warning; 1 Severe Errors.107. 108. ************* EnergyPlus Completed Successfully-- 5 Warning; 1 Severe Errors; Elapsed Time=00hr 00min 4.65sec109.…
15 and >90 then add "red" to the strings/int list.
pseudocode :
create list of strings
load bitmap from file path
get bitmap height
get bitmap width
count pixels -> (width*height) -> create a new int (pixelCount)
check every pixels color :
loop till i = pixelCount-1
if hue < 20 and >80 then add "red" to string list
if hue >20 and <40 then add ... etc.
output string list
…
exact formula is inside /lib/skybright.cal if this can help you to find the name.
{ RCSid: $Id$ } { Sky brightness function for sunny and cloudy skies.
Additional arguments required for calculation of skybright:
A1 - 1 for CIE clear, 2 for CIE overcast, 3 for uniform, 4 for CIE intermediate A2 - zenith brightness A3 - ground plane brightness A4 - normalization factor based on sun direction A5,A6,A7 - sun direction }
cosgamma = Dx*A5 + Dy*A6 + Dz*A7;
gamma = Acos(cosgamma); { angle from sun to this point in sky }
zt = Acos(A7); { angle from zenith to sun }
eta = Acos(Dz); { angle from zenith to this point in sky }
wmean(a, x, b, y) : (a*x + b*y) / (a + b);
skybr = wmean((Dz+1.01)^10, select(A1, sunnysky, cloudysky, unifsky, intersky), (Dz+1.01)^-10, A3);
sunnysky = A2 * (.91 + 10*exp(-3*gamma) + .45*cosgamma*cosgamma) * if( Dz - .01, 1.0 - exp(-.32/Dz), 1.0) / A4;
cloudysky = A2 * (1 + 2*Dz)/3;
unifsky = A2;
intersky = A2 * ( (1.35*sin(5.631-3.59*eta)+3.12)*sin(4.396-2.6*zt) + 6.37 - eta ) / 2.326 * exp(gamma*-.563*((2.629-eta)*(1.562-zt)+.812)) / A4;
…
hreads where Thread I solves object A1 and Thread II solves object A2. As soon as A1 is completed, Thread I can move on to object B1 and as soon as A2 completes, Thread II can move on to object B3 (whichever comes first). When both A1 and A2 are complete, we can spawn a new thread (III) to take care of object B2.
If B2 completes before B3, then Thread III will terminate. If B3 completes before B2, then Thread II terminates. Whichever thread is last will pick up execution of object C3. And so on and so forth.
This sort of threading is actually not guaranteed to help much though, as it is likely that the bottleneck components in the network will still need to be handled by a single thread.
A more efficient solution would be to divvy up the execution per component to multiple threads. If you're trying to compute the Curve Closest Point for 10,000 points and your machine contains 4 cores, then we can assign 2,500 points to the first core, 2,500 points to the second core etc.
This approach will actually work when there's only a few bottleneck components and it also means the order in which components are solved is no longer important.
An even more fine-grained approach to threading would be to make the Curve Closest Point function in the Rhino SDK threaded. There's a lot of looping going on in any given Curve CP computation so the curve could be broken up into loose spans where each span is solved by a different core. Then the partial results get consolidated once all threads finish.
The benefit here is that it would be multi-core for everyone, not just Grasshopper components.
The bad news: Some functions in Rhino are not thread-safe. Meaning that data structures such as NurbsCurves cannot be modified from multiple threads at once as it will compromise their validity. You might well end up with invalid curves and quite possible weird crashes. In very bad cases it might even be that a specific function in our SDK can only be running once, so even if you were to duplicate the curve it would still not work.
Until our SDK is thread-safe there can be no global threading in Grasshopper. I don't know where we're headed with this, but I do know that we've started using some threaded algorithms in the display as of Rhino5, so it seems we're at least getting our feet wet.
--
David Rutten
david@mcneel.com
Seattle, WA…
Added by David Rutten at 5:47pm on November 17, 2010
in the .gh-file below. However, it takes a very long time to generate this calculation, even four about five panels or so, while I have about 1600 on the hyperbolic paraboloid. You once told me in another discussion that the TOF component did less calculations than the PV Surface component and would therefore be faster. However, it seems to go even slower when you have multiple surfaces.
So what I would like to know is how to have an idea of which PV panels would be worth of keeping on the hyperbolic paraboloid. For instance, to visually represent the panels with a TOF of >90%, >80%, >70% and so on, without too long calculation time.
(You will have to zoom out quite a bit to see the surfaces. The TOF component is in the red group and there is some part of the code that is irrelevant for this question, but it's quite clear.)…
it we thought our stands will be made with a fixed depth (80 or 90 cm) and incremental heights like 30-32-34-36...cm, and that is the list you have to supply.
The script will iterate over the different possible measures until it finds the smallest one that complies with your desired C value, but it wont be the exact, just the best approximation within your list.
2. Changing this also depends on the combinations of riser height and depth you provide, if you enter 1m and 1m in both lists you will get an 45º slope.
Anyway, getting a fixed-c value script would be easier (much easier than what is already there) but IMO it wouldn't have a direct application in real stadiums unless you are ready to make each stand different from the rest, discarding any pre-cast solution.
Hope this helps.
Roberto…