les, also this image shows where i'm defining/assigning all of them:
BTW, the warehouse stuff appears ONLY in the exportToOpenStudio option.
Finally, i'm not conditioning the zones. Explicitly i asked to set the isConditioned_ input in the HB_createHBZones to False. The discussion you mentioned approaches this differently oversizing the heating/Cooling so you never need the AC. The IDF created don't have any definition of IdealSystems, so i don't believe this is the problem. If you want to see the IDF files you can see them above (attached in a previous message).
Weird ...
Thanks,
-A.
…
nnot calculate (too many digits).
Or you want just to fill that space with random configuration and find some good for you?
Here's my first thoughts:
Again, as some other cases, iterative process.
(Conway's game of life, a cellular_automata-like process (?)... Install anemone.)
I would create 3 grids:
1 - grid of 100 values, cell's center points
these values can have more integer values like 0=free 1=occuped
2 - grid of 81 values, grid vertex points (excludig perimeter)
these values are where the center of 2x2 cells could be. 0=possible location 1=not possible location
3 - "grid" of 180 values, grid segment center, where 1x2 center could be
again 0 and 1
Then it's needed a "topology" between those 3 grids:
At each iteration those values updates each other by basing on placed cells and adjacent values.
At each iteration a new cell (random from A or B) is placed in a random possible location.
This is just my madness, and maybe I'm already far away from a result.
For sure a fasterst, simpler, smarter solution exists.…
rsity building with 81 thermal zones. I wanted to use this model on my master thesis, but I am afraid I won't be able. So I would really appreciate some help.
The purpose was to set different insulation thicknesses and glazing types depending on the orientation. Therefore I created every zone by using "createHBsrfs" components. At the same time different zones would have different "building programs".
I created all the zones, I added windows as "child surfaces" for every zone. And I created the adjacencies. No errors or whatsoever.
But from this point I cannot connect the model to any other component without GH being frozen. So although the model is correct maybe it is to heavy for the software, however I am not sure if that is the reason.
Is it stupid what I have done? Is there any easier way to accomplish my purpose?
Any thought or help will be much appreciated.
I attach the GH file.
Thank you,
Eduard
Version: HB 0.0.59 / LB 0.0.62…
can be found in "C:\Documents and Settings\<user name>\Application Data\McNeel\Rhinoceros\5.0\Plug-ins\IronPython\settings\lib\rhinoscript" folder on WinXP. So could have used yours too.
RhinoCommon is a SDK and basically the power behind grasshopper and rhinoscriptsyntax functions. In fact each time you call a rhinoscriptsyntax, a RhinoCommon code gets executed.
And, yes:
import Rhino - imports RhinoCommon
import utility - enables importing utility.coercebrep() (or coerce3dpoint() coercecurve() ... so on)
Item access means an input is consisted of a single item.List access means an input is a list.Tree access means an input is consisted of a tree with data on different branches.rs.BooleanDifference requires both of it's arguments to be lists, so it would be logical to set the inputs b1 and b2 as lists. But there is one problem, that Mitch pointed out to me: it seems that python components (like grasshopper components) are "intelligent", and can distinguish whether you are inputting item, list, or tree. Setting your input as list, might disable this ability and leave you with only possible type of input (list).So honestly I do not know why in this case, setting the inputs to Lists worked - due to mentioned "intelligence" of python component, even an Item type would work.This might be a question for an experienced user, I am just a beginner.…
assume we want to format two numbers, one integer and a floating point value. The integer represents an index and it should appear inside square brackets, then we want the floating point number rounded to a maximum of 4 decimal places (but always using at least one decimal place, even if it's zero), and then, in parentheses a scientific notation representation using 8 decimal digits of the number.
So, assuming the index is 16 and the value is 47.280006208, what we are after is:
[16] 47.28 (4.72800062E+001)
To make this work, we need a formatting pattern that looks like:
[{0}] {1:0.0###} ({1:E8})
The square brackets, spaces and parenthesis are just part of the output, they have no meaning whilst formatting. Everything inside the curly brackets though will be replaced with a specific formatting of one of the values.
When using the Format component as shown above, the formatting pattern is just text data. The component knows that it is supposed to use the Format() function using the pattern text and whatever additional data is provided.
When you invoke the Format() method in an expression, you do need to make sure that the pattern is actually text:
So here the pattern needs to be encased in double quotes, otherwise it will be treated as code, rather than text.
You cannot use the formatting method in the internal expression of a number parameter, because this method returns text, whereas the number parameter is only capable of storing numbers. Any expression that you put into a number parameter had better return numbers as a result.…
n make it possible to Motivation generate
a variety of interesting objects, from abstract fractals to plant-like
branching structures, their modeling power is quite limited. A major
problem can be traced to the reduction of all lines to integer multiples
of the unit segment. As a result, even such a simple figure as an
isosceles right-angled triangle cannot be traced exactly, since the ratio
of its hypotenuse length to the length of a side is expressed by the irrational
number √2. Rational approximation of line length provides only
a limited solution, because the unit step must be the smallest common
1
1
√2
denominator of all line lengths in the modeled structure. Consequently,
the representation of a simple plant module, such as an internode, may
require a large number of symbols. The same argument applies to angles.
Problems become even more pronounced while simulating changes
to the modeled structure over time, since some growth functions cannot
be expressed conveniently using L-systems. Generally, it is difficult
1.10. Parametric L-systems 41
to capture continuous phenomena, since the obvious technique of discretizing
continuous values may require a large number of quantization
levels, yielding L-systems with hundreds of symbols and productions.
Consequently, model specification becomes difficult, and the mathematical
beauty of L-systems is lost.
In order to solve similar problems, Lindenmayer proposed that numerical
parameters be associated with L-system symbols [83]. He illustrated
this idea by referring to the continuous development of branching
structures and diffusion of chemical compounds in a nonbranching filament
of Anabaena catenula.
The following is an example of its application:
starting string: A
p1: A F(1)[+A][-A]
P2: F(s) F(s*R)
which I think is basically trying to say
F(s) = move forwar a step of length s > 0.
Thanks again,
Mateo…
h Shading--DC to AC derate Factor--Photovoltaics Module, can calculate the ACenergy of different pv arrays by Galapagos. The process can evaluate the self shading from the input analysisGeometry and surrounding shading from the input context.
2. PV SWH Systemsize, can also do that, but there would be no second type of self shading for the chosen minimalSpacingPeriod_ criteria.
3. TOF outputs optimal angle and azimuth.
So my question is, if I choose to make a curved roof to form a best pv array with best ACenergy, whether should I only choose the first above, the second PV SWH Systemsize can only deal with the angled or flat surface, not the curved? What's the relationship between TOF and PV SWH Systemsize?
Also, I'll do my best to make a parametric model as soon as possible and upload it to you, so we can make the discussion more detailed.
Best regards.…
face, the larger the number of modules and system size, there for the higher annual energy generation.baseSurface_ - this input exists only for "PV SWH system size" component. It's purpose is to represent a mounting plane on which the PV modules will be put onto. The dark blue colored roof in the photo below is that mounting surface in this case:
So the size of area of the baseSurface_ is not important but its plane.
2) It is important. It basically sets the initial losses of the system.
If that is the soiling value you have, then yes, you need to add it to the DC to AC derate factor component, and then plug its output to "DCtoACderateFactor_" input. I did that in the attached definition below.
3) The north vector/numeric value is not propagated due to possible independent usage of components.I plugged the 0 value to all three component's which have "north_" input. You can change it to what ever value you need.
Please let me know if I didn't answer completely to your questions, or if you have more of them.…
rs interface og dykker derefter ned i mere komplekse parametriske modeller. Vi vil desuden arbejde med forskellige funktioner, der hjælper med til at gøre modeller mere responsive og interaktive.
Efter kurset vil du have/kende til:
Basale inputs og parametre, punkter og vektorer, og små geometriske eksempler
En forståelse for Grasshoppers interface og teorien bag den visuelle programmering
Kendskab til og forståelse af de væsentligste komponenttyper i Grasshopper
Matematiske principper, der giver mulighed for sortering gennem sandt/falsk og mindre-end/større-end udsagn
Dataflow: midlertidige og permanente data
Forene og styre data-input, samt en dybere forståelse af Grasshoppers datastyring.
Styring af lange data-lister og data-træer i Grasshopper
Eksempler på parametrisk geometri, som feks. attractorpoints
Brugen af Grasshopper som et panel værktøj, der giver mulighed for at beklæde overflader med paneler baseret på underindelinger, gradienter og attractor points
forberedelse af egne definitioner, med fortsat fokus på projektets responsibilitet.
…
on this, but to my understanding, the Δt_pr used is the same - the equations used to calculate are not. Take a look at this (from EN 7730 as well):
If I can make some wishes too; it would be cool, if you included the last local comfort metrics from EN7730 in LB/HB as well. Besides the local asymmetry there are: an equation for warm/cold floors, stratification and draught. I know, that you will need preform a CFD simulation to properly calculate stratification and draught, but the comfort equations are really simple and seeing that you have(might have) a CFD tool under way it could be useful. Anyways I think it would possible to import external generated CFD data to grasshopper.
The pictures in my previous post are from a paper called: "A simplified calculation method for checking the indoor thermal climate" by B.W. Olesen, it can be found in ASHRAE 1983, vol. 25, issue 5. I don't know if there have been any updates to it since '83.
Looking forward for the new components, and if there is anything I can help with please let me know.
/Christian
…