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.…
et's say I have five heights. The tree of points would then be 5 branches, with 50 items each... and I want to dispatch each branch based on the same 50-item list as before.
1) The Tree Statistics component only reads the number of branches, and cannot be pointed one layer in to read the number of items. How can I "dive one level deeper" so that in each branch, the items' indices are replaced by unicode values?
2) Is there a flipmatrix'd way to think about this: can I first dispatch the first height's points into groups as David's script already does, then move all points to five different heights, and still be able to select (five heights of) each branch-group as the Visualize portion of David's script?
Thanks again for any insight,
Richman…
alculates the centre of gravity where parts of the route between the object and target are pre-defined. So the gravity object is always located at one end of the curve and does not move, the force must always travel through all the curve (and the curve is fixed), at the other end of the curve the route of the force can be direct from the end of the curve to the centre of the object.
Imagine an elastic band between 2 objects where 50% of the band is forced into a particular path. I think I explained it badly before.
…
Added by John Everist at 6:54am on January 20, 2017
n due at the end of march. i am hoping to see if i can do this as a sort of "HIVE MIND" experiment with one or two or more posters to the forum. i have uploaded two files to http://www.formpig.com/nine_bar-FAR and I have the following goals:
1. To "kinematically iterate" various formal building envelopes based upon a 50' x 100' lot that "conform" to the nine bar linkage geometry.
2. This lot would have "setbacks" consisting of two 5' side setbacks, a 10' rear yard setback and a 25' front yard setback. max height on the structure is 32' and the allowable overhangs into the setbacks are 2'. I would like to find a way to use the "nine bar geometry" to construct a series of iterations for "floors", "walls" and "ceilings", which would then be tied to a volumetric (cubic volume), or a total square footage (perhaps based upon two horizontal section cuts) which was based upon a given number that I will provide per local building code.
3. Laid on top of this we would also have "mcmansion ordinance" requirements based upon the pdf enclosed. i expect to have this "tent restriction" data in digital form to upload to ftp shortly.
It would be up to you individually or collectively to determine how best to position this "in the real world" based upon the lot, setbacks, zoning requirements etc. For instance, perhaps the nine bar configuration has its vertices coplanar with the 50' x 100' x 32' envelope restrictions and then the chosen volume is "trimmed' by the setback requirements. Or perhaps the nine-bar configuration is generated completely within the setbacks, or perhaps it is generated 2' outside of the setbacks so as to take advantage of the 2' overhang allowance on the setbacks, etc.
*
Given an opportunity to develop the work in a second phase we would have an opportunity to tie this into various efficiencies such as Bill of Materials (wall floor and ceiling square foot calculations), envelope to volume calculations, solar panel efficiencies (solar orientation and envelope geometry) etc, etc (love to get suggestions for this).
*
I've become /really/ convinced that this would be a /really/ interesting entry based upon my just finishing up Kas Oosterhuis' Towards a New Kind of Building: A Designer's Guide for Non-Standard Architecture". In an ideal world I was hoping that it would be possible to hash this out discussion-wise and then literally passing it around on the list after someone eventually made the first move by tossing out a rough ghx script. My expectation would be to finalize it rapidly in the next two weeks. Something of a contemporary version of a design charette.
However, I realize this may not be workable so if you have experience in this arena and particularly if you think this is a brief that is straighforward enough to be almost literally implemented in Grasshopper, please contact me for any wage and/or contract fee requirements.
I'm getting a bit of a late jump on this but my hope is that with the right participant(s) that I can thrash it together quick enough for the first round.
info@formpig.com…
omplished i decide to post my version anyway (mine only works on Points though)...
tPts (total Points) are the total number of points to work from
intS (integer Split) is the value to split the list around. so if tPts is 50 and intS is 2 then the final returned value are 2 objects containing list of 25 points.
oh, and the "item sel" node is a utiltiy node i wrote that lets me scrub through and look at individual values in an index.
if you're game feel free to give me feedback about my coding style... im still trying to get hang of this.
M
…
he start point.
Generation (2) i have 4 points + (3*3points) = 13 points.
Generation (3) i have 13 points + (9*3points) = 50 points.
But when i bake the python component i have 157 points ? Why ?
What's the logic behind this ?
Also how can i have in a, lists of points according to generations and for exemple in b lines according to generations too ??
Here's the code:
import rhinoscriptsyntax as rsimport random as rr.seed(seed)
def Main():....allGenerations = []....allGenerations.append(startPt)....curGeneration = []....curGeneration.append(startPt)....for i in range(gens):........newGeneration = []........for pt in curGeneration:............ang1 = r.randint(-30,30) ............ang2 = r.randint(90,150) ............ang3 = r.randint(210,270) ............dist1 = r.randint(10,40) ............dist2 = r.randint(10,40) ............dist3 = r.randint(10,40) ............zV = -1 ............newPoints = branch(pt, ang1, ang2, ang3, dist1/(i+1), dist2/(i+1), dist3/(i+1), zV) ............newGeneration.extend(newPoints) ............curGeneration = newGeneration ............allGenerations.extend(newGeneration)....return allGenerations
def branch(pt, ang1, ang2, ang3, dist1, dist2, dist3, zV):....ptP1 = rs.Polar(pt, ang1, dist1)....ptP2 = rs.Polar(pt, ang2, dist2) ....ptP3 = rs.Polar(pt, ang3, dist3) ....ptA1 = rs.AddPoint(ptP1)....ptA2 = rs.AddPoint(ptP2)....ptA3 = rs.AddPoint(ptP3) ....pt1 = rs.MoveObject(ptA1, [0,0,zV])....pt2 = rs.MoveObject(ptA2, [0,0,zV])....pt3 = rs.MoveObject(ptA3, [0,0,zV]) ....ln1 = rs.AddLine(pt, pt1)....ln2 = rs.AddLine(pt, pt2)....ln3 = rs.AddLine(pt, pt3) ....return [pt1, pt2, pt3]
a = Main()
Thanks for you replies and sorry for my noob questions...
…
e path overlap to reduce tool wear. 50% might be a good estimate.
- Most of the time, you will route in two steps (roughing for volume and finish for surface) both with different tools.
That will get you a rough length of the overall tool path. Add some more for tool positioning.
Now for the time factor:
Cutting speed (vc) for wood is about 300m/s. That's for a single tooth or blade throught the material.
You can calculate the optimal RPM by
n [RPM] = (vc [m/min] *1000) / (3.14 * Ød1 [mm])
the travelling speed can be estimated by
f [mm/min] = n * fz * z
with z = number of edges and fz depending on material and tool diameter (0.05 as an estimate)
There are some online calcualtion tools, that help you... still you will need a bit of knowledge about the technology to use them.…
re 2 solutions: (last boolean toggle)
true - interpolated point while rebuilding surface from points;
this means the final surface will touch the input curve and the curvature is almost the
same as original (but not perfect, this is still a rebuild).
false - not-interpolated;
the final surface will not touch the input curve but the surface nurbs point will...
the surface will be visibly different from original
P.S. the slider at "50" is to decide how % of divisions to put above the curve an under...
If you need an even more relaxed/uniform point grid, we could divide isocurves "V" with an incremental t (curve parameter) values...
tell if...
bye!
maje
…
orders from bottom to top. There are three pre-set heights: 20,000 / 50,000 / 80,000 (or 20, 50, 80 meters, I'm working in mm).
So if the three cantilevering volumes would be numbered 0,1 and 2, then I'm looking for a way to let Grasshopper generate the following:
A = 20m-position
B = 50m-position
C = 80m-position
(A,B,C):
0,1,2
0,2,1
1,0,2
1,2,0
2,0,1
2,1,0
Attached is wat I have so far, I have only managed to make simple translations per geometry.
…
g energy use of electric lighting dimming system.
But I found a major mistake in my previous test file, that is, the "lighting Power" used in the daylight simulation and the E+ simulation are NOT equal by my carelessness. The former was 250w (default value in "Honeybee_Lighting control Recipe") while the later was 11.8403571*50=592.018w (lightingDensityPerArea*Areaoffloor=lightingpower).
Having corrected this mistake (by using 592.018w for both of them), the results of electric lighting energy obtained from daylight and E+ simulations are much closer with each other and more reasonable. In order to see how close they are, I made 3 tests using 3 different weather files (New York, Amsterdam, Guangzhou). The results are listed as follows respectively:
New York (3.4% difference)
Amsterdam (2.7% difference)
Guangzhou (3% difference)
It seems that the difference (around 3%) is acceptable?
You are right. Having checked the IDF file created, as you mentioned above, there is no data in the Daylighting class (since the daylight control are not implemented in the E+ simulation). But, the light is "fully/partially" on according to the "fractions" in the generated lighting schedule list, which already takes in account the dimming system by the setting in "Honeybee_Lighting control Recipe" in daylight simulation.
Then, what the E+ simulation did in terms of calculating electric lighting energy use is just as the following formulation: lightingDensityPerArea * Areaoffloor * sum of lighting schedule list (generated by daylight simulation in this case) = electric lighting energy use, which has been verified by the comparison of results obtained from E+ simulation and calculated by the above formulation. (The results are exactly the same.) Please see the updated gh file attached.
Therefore, I assume that the E+ results generated in this way (using the lighting schedule generated by the daylight simulation) are still reliable, although there exist some tiny difference (around 3%) for some unknown reason (Maybe Daysim does not follow the same formulation mentioned above? Can you imagine the possible reason?).
In addition,
- I am not clear with what you mentioned as "they definitely don't share daylight considerations". What "daylight considerations" here refer to? (sky condition / sky file? but in the annual Daylight Simulation, only weather file is required instead of sky file)
- A basic question: In E+ simulation, has the waste heat generated by the electric lighting been considered as "internal heat gain" (showed in the above image)? If so, can I say that "energy use for electrical light" is fully converted to "the waste heat" + "Illuminance in lux".
Namely, energy use for electrical light = the waste heat + Illuminance in lux (lux can be converted to electric power in watts)?
Many thanks!
Best,
Ding…