he TOF and TSRF indices. They show, how "distant" is your _PV_SWHsurface from the optimal _PV_SWHsurface surface in terms of tilt and azimuth angles.However, in your case we are not interested in TOF and TSRF indices. We would just like to know what are the _PV_SWHsurface optimal tilt and azimuth angles, regardless of the supplied _PV_SWHsurface.
So the circular surface supplied to the "TOF" component's _PV_SWHsurface input is irrelevant. It can be of any area, and any tilt/azimuth angle.The PV_SWHsurfacesArea output of the "PV SWH system size" component depends on a couple of factors:moduleActiveAreaPercent_ (leave it at 90%).
moduleEfficiency_,
systemSize_.Calculation of systemSize_ depends on your electricity demand, cost of the PV system, type of the object, country, local regulations etc. This is something that an engineer needs to determine.For example, in USA for a residential house in the Sunbelt, depending on finances, a household would try to cover 100% of its annual electricity needs with their PV system. Which means that the systemSize_ you chose needs to cover the annual electricity consumption. You can perform EnergyPlus simulation or use any other way to get the annual electricity consumption.
Ladybug "Photovoltaics Performance" component can calculate the optimal systemSize_ by given the annual electricity consumption.However the component is made to address fixed tilt and azimuth PV systems only.An approximate way to overcome this is to calculate the optimal systemSize_ for fixed tilt and azimuth PV system, and then multiply it with the "difference in %s" panel at the very right of the fixed_vs_tracker_PV2.gh file. Again, this is not what Ladybug "Photovoltaics Performance" component is made to do, but it will probably get you in a ball park.
Inputted 32 degrees for north_ direction is actually 328 degrees.This is due to Ladybug Photovoltaics being based on NREL model which uses clockwise angles convention. This convention is also most commonly used in solar radiation analysis.
Dubai weather data files are uploaded in here.
…
them can be addressed before winter.
Bugs:
. Vector preview is great, but it doesn't refresh (clear) when you disconnect components. You must delete the component or reconnect to refresh the vector previews.
. When passing values through a note pad, note pad fails to update continuously. Moving the notepad updates the display.
. Cannot pass a notepad integer into an fx1
. Point preview in RH5 appears as large red blocks, not as red crosses. (This is an old bug, may have been fixed with RH5 update in the meantime.)
. After adjusting Graph in dialog box, graph appears to be a solid grey object until moved.
. After copying and pasting, a lot of components are broken, return nulls. Requires reconnect to recompute (haven't had this problem in a while, will see if I can find a file that recreates it)
. BIG ONE: Loading a graph mapper with a file not found creates broken file... graph mapper disappears off canvas and the output wire appears turns orange and appears to be coming from the 0,0 pixel of the canvas. This happens any time you try to port a .ghx file to another system with different drive letters/paths, etc.
Wish list:
Mass addition for vectors
Interactive domain control for Image Sampler (like with Gradient Mapper)
Allow Addition Component to handle String values (A + B = AB)
BIG ONE: Request Override for Icon display for Parameters, Wireless receiver, and script components if you change the name
BIG ONE: Add new behavior for Stream Filter and Stream Gate: Allow multiple index numbers. The Index number picks the value/object in the corresponding index position in the selected list.
For instance:
List 0: A, B, C, D, E
List 1: 1, 2, 3, 4, 5
List 2: .1, .2, .3, .4, .5
Index Stream: 0, 2, 2, 1, 1, 2, 1, 0, 1
Results: A, .2, .3, 4, 5 (This is new behaviour and more useful than Weaving)
I have attached a GHX that includes VB components that do this, but it would be better to have GH components with I/O manager options and data matching behavior, etc.
Thanks,
Marc Syp
Knowlton School of Architecture
The Ohio State University
Columbus, OH…
curves A and B.
For each point pA on curve A,
you need the corresponding tangent vector tA on curve A, and the lists of "cone" vectors pB(j)-pA and tangent vectors tB(j) on curve B. so you have three vectors tA, tB(j) and AB(j)
these three vectors define a parallelogram thas varies along j
3d determinant of the three vectors above gives you the volume of this parallelogram. When 3dDet = 0 then it means it's flat, the vectors are coplanar. Thats what we're looking for.
So you just need to plot the curve 3Ddet = f(pB) , still for each point on A
'pB is the parameter here'
graphically solve these cuves to find the zeros and you feed back the resulting parameter in curve B. draw te line, done.
You can manage double solutions or cusps directly on the plot by using clostest point and >= conditions to kill unwanted results.
I do it twice, from crv A to crrv B and from B to A to make sure I catch start and end generatrices each time.
The videos you posted are interesting. I don't understand how it works with just 2 slider to tune the curves.
…
as passing this extra check and because of that it was running faster. It doesn't mean that the first analysis is totally wrong as it depends on the analysis case and should be checked and optimized before running the final analysis.
You can read more about radiance parameters here (http://radsite.lbl.gov/radiance/refer/Notes/rpict_options.html), and here (http://radiance-online.org/community/workshops/2011-berkeley-ca/pre...). Since you have a light-shelf I suggest you to add to the number of ambient bounces (ab).
Now back to your wish to have the analysis run faster you can comment the line hb_writeRADAUX.checkInputParametersForGridBasedAnalysis() inside Honeybee_runDaylightSimulation and it won't overwrite the initial values but make sure that you run a number of test cases and compare the results between the runs.
Back to your definition, it looks good to me. You could have saved yourself some time by using MassToZone component and then just adding the ceiling separately but there's nothing wrong with your approach.
The main place in the definition that can change is how you're generating the vertical fins. I imagine you can use a single set of components to generate every group of the fins but again your definition will work.
I updated your file to the latest version, which means you also need to update Honeybee and Ladybug in case you're looking to modify the file.
Hope it helps,
Mostapha…
ky.exe did not accept -p parameter and made empty sky.cal file.
----
Edit: solved run problem, Bee did not download OpenStudioMasterTemplate.idf
Get it here: https://github.com/mostaphaRoudsari/Honeybee/issues/119
Now get empty HDR:
C:\ladybug\prox\imageBasedSimulation>rpict -i -t 10 -vtv -vp 245.129 -226.458 20 0.405 -vd -0.549 0.656 -0.518 -vu -0.332 0.397 0.855 -vh 42.862 -vv 26.991 -v l 0 -vs 0 -vl 0 -x 800 -y 600 -af prox_RAD_Perspective.amb -ps 8 -pt 0.15 -pj 0.6 -dj 0 -ds 0.5 -dt 0.5 -dc 0.25 -dr 0 -dp 64 -st 0.85 -ab 2 -ad 1024 -as 175 -ar 150 -aa 0.200 -lr 4 -lw 0.050 -av 0 0 0 prox_RAD.oct 1>prox_RAD_Perspectiv e.unf rpict: 0 rays, 0.00% after 0.0000 hours rpict: skybright`c__ladybug_skylib_cumulativeSkies_SINGAPORE_SGP_SINGAPORE_SGP_1 : undefined variable rpict: 1020 rays, 4.91% after 0.0000 hours
----
Hi friends,
trying to get a cumulative sky image metric to run and encountered an issue with the image-based metrics component. It throws:
Runtime error (KeyNotFoundException): honeybee_materialLib Traceback: line 768, in main, "<string>" line 1442, in script
I guess this is some sort of setup issue on my end, or I messed up the definition? Any help appreciated.
Thanks,
Max
…
ace when I start running Galapagos/Octopus (below is "room orientation optimization" shared at http://hydrashare.github.io/hydra/viewer?owner=mostaphaRoudsari&fork=hydra_1&id=Room_Orientation_Optimization&slide=0&scale=1&offset=0,0) It may take quite some time to see some results. That's fine for the above simulation. But my real challenge is, when I am going to optimize room dimension with respect to ASE and sDA calculations, either Galapagos or Octopus goes wildly and never come up with a solution. I believe the time-consuming calculation, especially sDA with higher -ab numbers, trigger the lag a lot? Any suggestion/trick to improve it?
Most importantly, based on your experience, for example to optimize window/exterior shades sizes and achieve ASE<10% and sDA>55% (LEED v.4 requirements), Octopus (due to its capacity of multiple objectives) is the only choice? Any other approaches within grasshopper?
The alternative approach in my mind as a GH beginner is as follows. But I am not sure whether it is doable. Again, your comments will be greatly appreciated.
Since all my room/window/shades dimension are controlled by number sliders, I am thinking whether a component from GH will trigger these number sliders (not necessary to be all of them but one by one) automatically. If this is possible, I can do "data recorder" to record outputs from ASE and sDA. Eventually I will have a database of the input parameters and sDA/ASE results.
Does it make sense? Is there a component which can trigger number slider output at certain step?
Many thank!
Cheney …
ect + Geco
TUTORS:
Arturo Tedeschi (Authorized Rhino Trainer) + Maurizio Arturo Degni
Il workshop avanzato ECOLOGIC PATTERNS affronta l’impiego di strategie parametriche all’interno del processo progettuale, approfondendo l’utilizzo di Grasshopper in sinergia con plug-in, software di analisi ambientale e simulazione fisica. Obiettivo fondamentale è la generazione della forma come risultato di tecniche di form-finding e di input ambientali (solari, termici e acustici). Verranno acquisiti nuovi strumenti operativi e di simulazione al fine di costruire modelli parametrici ottimizzati in grado di adattarsi a diverse condizioni di contesto.
MORE INFO…
, Engineer and Researcher from France with broad programming experience. He is the author of the City in 3D Rhinoceros plugin for creation of buildings according to geojson file and with real elevation. Guillaume already created a new component: "Address to Location". It enables getting latitude and longitude values for the given address:
2) Support of Bathymetry data: automatic creation of underwater (sea/river/lake floor) terrain. This feature is now available through new source_ input of the "Terrain generator" component. Here is an example of terrain of the Loihi underwater volcano, of the coast of Hawaii:
3) A new terrain source has been added: ALOS World 3D 30m. ALOS is a Japanese global terrain data. Gismo "Terrain Generator" component has been using SRTM 30m terrain data, which hasn't been global and was limited to -56 to +60 latitude range. With this addition, it is possible to switch between SRTM and ALOS World 3D 30m models with the use of source_ input.
4) 9 new components have been added:
"Address To Location" - finds latitude and longitude coordinates for the given address.
"XY To Location" - finds latitude and longitude coordinates for the given Rhino XY coordinates. "Location To XY" - vice versa from the previous component: finds Rhino XY coordinates for the given latitude longitude coordinates. "Z To Elevation" - finds elevation for particular Rhino point. "Rhino text to number" - convert numeric text from Rhino to grasshopper number. "Rhino unit to meters" - convert Rhino units to meters. "Deconstruct location" - deconstructs .epw location. "New Component Example" - this component explains how to make a new Gismo component, in case you are interested to make one. We welcome new developers, even if you contribute a single component to Gismo! "Support Gismo" - gives some suggestions on how to make Gismo better, how to improve it and support it.
5) Ladybug "Terrain Generator" component now supports all units, not only Meters. So any Gismo example file which uses this component, can now use Rhino units other than Meters as well. Thank you Antonello Di Nunzio for making this happen!!
Basically just forget about this yellow panel:
This panel is not valid anymore, so just use any unit you want.
6) A number of bugs have been fixed, reported in topics for the last couple of weeks. We would like to thank members in the community who invested their time in testing, finding these bugs and reporting them: Rafat Ahmed, Peter Zatko, Mathieu Venot, Abraham Yezioro, Rafael Alonso. Thank you guys!!! Apologies if we forgot to mention someone.
The version 0.0.2 can be downloaded from here:
https://github.com/stgeorges/gismo/zipball/master
And example files from here:
https://github.com/stgeorges/gismo/tree/master/examples
Any new suggestions, testing and bug reports are welcome!!…
Added by djordje to Gismo at 5:13pm on March 1, 2017
(1) I have been exporting small sections of a larger model into Maya from Rhino as FBX. In Maya I rotate and scale the models (-90 in X, Scale XYZ 0.001). The Named Views are being saved, but do not have a successful import into the Maya model. They do not appear as in Rhino, and the problem is not solved by scaling or rotating the cameras.
(2) If I try going the other direction, the cameras exported from Maya as FBX are also not aligning with the model in Rhino as they are in Maya.. I will do my best to post some images of the problem and hope you can help.
error !!
This is what the named views look like
here I am trying to the other way with a good view from Maya
strange placement..
This is the best result I can achieve, after I scale the camera by 1000
Any Advice???
Thanks, Robert.
…
ysim.ning.com/
When you run the simualtion you will notice on the batch terminal that Daysim is also being called, so you may want to consider how Daysim uses Radiance files & data.
Regarding your current problem, I think you stumbled onto something weird and interesting.
Interior and exterior readings appear to differ by 40 in the best case scenarios. Even setting the transmittance to 1 yields similar results. I tried changing from cummulative sky to climate sky and got similar values. Changing the test points did nothing either.
I think, (yet I'm too lazy to prove this) that the difference in values stems from diffuse radiation over the sky dome.
If you delete everything except the glass you'll notice that interior values are like 80-90% of the exterior values (this seems like the expected behaviour with a transmittance of 1). So, if we consider that a vertical window, part of an opaque box, is receiving radiation from 25% of a sphere, as you start to inset the interior test points the radiation they receive will be a fraction of the 25%.
Let me try to explain this better...The exterior surface receives radiation from a section of a sphere calculated by 180degrees on the xy plane (let’s call this angle theta) and by 90degrees (let’s call this angle phi) in azimuthal elevation. If you integrate this over spherical coordinates (theta from 0 to pi; phi from 0 to pi/2) you will find that it comes to a quarter of a sphere. By comparison, the interior surface will not integrate theta from 0 to 180degrees,nor phi from 0 to 90degrees, instead it will be the subtended angle from the exterior surface as a function of their separation; the farther in you go the smaller the view of the outside.
If my hypothesis is correct there shouldn't be that much difference since the separation is only 10cms...the subtended angle would be like 170 instead of 180 for theta and 85 instead of 90 for phi...overall if you integrate both spherical areas there should only by a difference of 10%.
In conclusion, I believe the unexpected behaviour stems from the previous subtended angle thing. If direct radiation was the only factor the difference would be the aforementioned 10%, which suggests that an additional source of energy is also affected by this. Perhaps indirect and diffuse radiation from other areas of the sky dome.
I’m definitely intrigued on why this is happening. Please post if you figure it out.
Regards,
Mauricio
…