a reply.
Q1. I run two generations in my generation 0 I can distinguish 3 lines...what do they refer to? I got my Fitness as 5 values Heating, Cooling etc and thought there will be 5 lines
Q2. What are values on X/Y/Z axis and color legend? What colors means I got black 409.87 and red 33.63 amd tis dot 99.2:5 and green 2.27:4?
Q3. I can see that in every generation my values are condensed ...of course I shall run this for many more generations... but as result of my simulation which is minimize energy will be the last one that head down?
Q4. I was reading this forum and there is no current way of savings all results for each run ?
Q5. If there are some any general advice how I shall tackle my problem this would be great!
Ps. I will try to run this example over the weekend to see what is the result.
…
using Grasshopper.Kernel.Data; using Grasshopper.Kernel.Types;
using System; using System.IO; using System.Xml; using System.Xml.Linq; using System.Linq; using System.Data; using System.Drawing; using System.Reflection; using System.Collections; using System.Windows.Forms; using System.Collections.Generic; using System.Runtime.InteropServices;
/// <summary> /// This class will be instantiated on demand by the Script component. /// </summary> public class Script_Instance : GH_ScriptInstance { #region Utility functions /// <summary>Print a String to the [Out] Parameter of the Script component.</summary> /// <param name="text">String to print.</param> private void Print(string text) { /* Implementation hidden. */ } /// <summary>Print a formatted String to the [Out] Parameter of the Script component.</summary> /// <param name="format">String format.</param> /// <param name="args">Formatting parameters.</param> private void Print(string format, params object[] args) { /* Implementation hidden. */ } /// <summary>Print useful information about an object instance to the [Out] Parameter of the Script component. </summary> /// <param name="obj">Object instance to parse.</param> private void Reflect(object obj) { /* Implementation hidden. */ } /// <summary>Print the signatures of all the overloads of a specific method to the [Out] Parameter of the Script component. </summary> /// <param name="obj">Object instance to parse.</param> private void Reflect(object obj, string method_name) { /* Implementation hidden. */ } #endregion
#region Members /// <summary>Gets the current Rhino document.</summary> private readonly RhinoDoc RhinoDocument; /// <summary>Gets the Grasshopper document that owns this script.</summary> private readonly GH_Document GrasshopperDocument; /// <summary>Gets the Grasshopper script component that owns this script.</summary> private readonly IGH_Component Component; /// <summary> /// Gets the current iteration count. The first call to RunScript() is associated with Iteration==0. /// Any subsequent call within the same solution will increment the Iteration count. /// </summary> private readonly int Iteration; #endregion
/// <summary> /// This procedure contains the user code. Input parameters are provided as regular arguments, /// Output parameters as ref arguments. You don't have to assign output parameters, /// they will have a default value. /// </summary> private void RunScript(bool bake, List<GeometryBase> G, Point3d L, Color C) { COL = C; LOCATION = L; NAME = ""; pnts.Clear(); crvs.Clear(); breps.Clear();
foreach(GeometryBase geom in G){ switch(geom.GetType().Name){ case "Point": pnts.Add(((Rhino.Geometry.Point) geom).Location); break; case "Curve": //create a new geometry list for display break; case "PolyCurve": crvs.Add((PolyCurve) geom); break; case "Brep": breps.Add((Brep) geom); break; default: Print("Add a new case for this type: " + geom.GetType().Name); break; } }
if(bake){ Rhino.DocObjects.InstanceDefinition I = doc.InstanceDefinitions.Find(NAME, false);
if(I != null) doc.InstanceDefinitions.Delete(I.Index, true, true);
int index = doc.InstanceDefinitions.Add(NAME, "description", Point3d.Origin, G); doc.Objects.AddInstanceObject(index, Transform.Scale(L, 1)); } }
// <Custom additional code> //GEOMETRY Lists to display
List<Point3d> pnts = new List<Point3d>(); List<PolyCurve> crvs = new List<PolyCurve>(); List<Brep> breps = new List<Brep>();
string NAME; Point3d LOCATION; int THICKNESS = 2; Color COL;
//Return a BoundingBox that contains all the geometry you are about to draw. public override BoundingBox ClippingBox { get { return BoundingBox.Empty; } } //Draw all meshes in this method. public override void DrawViewportMeshes(IGH_PreviewArgs args) {
}
//Draw all wires and points in this method. public override void DrawViewportWires(IGH_PreviewArgs args) { foreach(Point3d p in pnts) args.Display.DrawPoint(p, Rhino.Display.PointStyle.ControlPoint, THICKNESS, COL);
foreach(PolyCurve c in crvs) args.Display.DrawCurve(c, COL, THICKNESS);
foreach(Brep b in breps) args.Display.DrawBrepShaded(b, new Rhino.Display.DisplayMaterial(COL));
args.Display.DrawPoint(LOCATION, Rhino.Display.PointStyle.ActivePoint, 3, Color.Black); args.Display.Draw3dText(NAME, Color.Gray, new Plane(LOCATION, Vector3d.ZAxis), THICKNESS / 3, "Arial"); }
// </Custom additional code> }…
guages I'd recommend all use the RhinoCommon SDK and thus all have access to the same functionality.
How long would it take me to understand and write my own code?
If you already know how to program, it probably won't take too long. If you're past the hurdle of what it means to declare and assign variables, how conditionals and loops work and what scope is, you've already rounded the hardest corner.
Is it even worth it?
That really depends. "Learn programming" is clearly not blanket good advice. Most people out there do not have to learn programming to be happy with their lives and successful in their careers. For some people it can make a small difference, and for a few people it can make a huge difference. If you feel you're in the 'some' category then this is indeed a question you have to answer. Note that the investment for learning programming is a continuous process. Unless you keep up your skills and learn about new stuff that becomes available, you'll lose the ability to write successful code over time.
Where do I start?
Step 1 is to answer the previous question. It is unlikely that anyone besides yourself can answer it, but you can start by making a list of things you do manually now that may be programmable. Then make a list of the things you are unable to do now but which you might be able to do with programming. If while looking at these lists your reaction is: "meh", the answer is probably no.
Step 2 is to pick a language. This is again a very personal thing; there's no wrong answer, because there's no right answer.
Step 3 is to start learning this language. My experience is that the best way to learn a programming language is to try and solve a real problem that you understand very well. If the problem statement is nebulous or poorly understood, you'll be learning two things and that's a recipe for unnecessary frustration.
Here are my thoughts on language:
Python: I don't use Python myself, I can sort of read it while moving my lips. I don't particularly like Python though. The indentation sensitiveness stresses me out, and I find the lack of type-safety disturbing. However it is a good language for mathematical/scientific programs. There are lots of additional code libraries you can easily import that will ease the development of mathematically intense algorithms.
C#: I like C# very much, but it does suffer from geekerosis. A lot of the keywords used in the language are not self-explanatory (abstract, sealed, virtual). For me this is no longer a problem as I've memorised what they all mean. C# is designed to be an efficient language to write, rather than an easy one to learn.
The great thing about C# though is that there's a huge amount of material out there for learning it. It is one of the most popular, mature and modern languages you can hope to pick.
VB: I learned VBScript as my first language, and then moved on to VB5, VB6 and VB.NET. It is somewhat more friendly than C#, and functionally it is almost identical. The switch from VB to C# is reasonably low-threshold and there are excellent tools for translating VB code to C# and vice versa.
Since you already know some Python, it probably makes the most sense to continue on that path. If you want to switch, C# is more like Python than VB, so C# would be my next suggestion.
As for where to get information... you have 4 major options when developing code for Rhino.
If it's a question about the language itself, StackOverflow is a great resource. It can be a pretty hostile place for beginner questions, but I find that mostly the questions I'm asking have been asked already and the answers on SO tend to be good. In fact usually when I google my questions, the first few hits are always SO posts.
If it's a question about the Rhino SDK or Grasshopper, you can ask it either on the GH forums (where we are now), or on Discourse. We're not as quick on the draw as SO, but we do know about Rhino.
If you're looking for a basic explanation of what a keyword or a type is for, perhaps with an example, MSDN is the best first choice. In fact if you google the name a of a .NET type, the first hit is almost always an MSDN page.…
Added by David Rutten at 2:03pm on December 3, 2014
umbrella of Urban Heat Island (UHI) and I am going to try to separate them out in order to give you a sense of the current capabilities in LB+HB.
1) UHI as defined as a recorded elevated air temperature in an urban area:
If you have access to epw files for both an urban area and a rural area, you can use Ladybug to visualize and deeply explore the differences between the two weather files. Ladybug is primarily a tool for weather file visualization and analysis and it can be very helpful for understanding the consequences of UHI on strategies for buildings or on comfort. This said, if you do not have both rural and urban recorded weather data or you want to generate your own weather files based on criteria about urban areas (as it sounds like you want to do), this definition might not be so helpful.
2) UHI defined by air elevated air temperature but viewed as a computer model-able phenomenon resulting primarily from urban canyon geometry, building materials, and (to a lesser degree) anthropogenic heat:
This definition seems to fit more with they type of thing that you are looking for but it is unfortunately very difficult and computationally intensive such that we do not currently have anything within Ladybug to do this right now. I can say that the state-of-the art for this type of modeling is an application called Town Energy Budget (TEB) and this is what all of the advanced UHI researches that I know use (http://www.cnrm.meteo.fr/surfex/spip.php?article7). Unfortunately for those trying to use it in professional practice, it can take a while to get comfortable with it and it currently runs exclusively on Linux (this does mean that it is open source, though, and that you can really get deep into the assumptions of the model). A couple years ago, a peer of mine translated almost all of TEB into Matlab language making it possible to run it on Windows if you have Matlab. He wrapped everything together into a tool called the Urban Weather Generator (UWG), which can take an epw file of a rural area and warp it to an urban area based on inputs that you give of building height, materials, vegetation, anthropogenic heat, etc. I would recommend looking into this for your project, although, bear in mind that is it not open source like the original TEB tool and that you may need to get a (very expensive) copy of MATLAB (http://urbanmicroclimate.scripts.mit.edu/uwg.php).
3) UHI as defined by a thermal satellite image of an urban area depicting an elevated average radiant environment that reaches a maximum a the city center and changes by land use:
This is the definition of UHI that I am most familiar with and was the basis of much of my past research. I feel that it is also a definition of UHI that is a bit more in line with where a lot of contemporary UHI research is headed, which is away from the notion of UHI as a macro-scale meteorological phenomena that is averaged as an air temperature over a huge area towards one that accepts that different land uses have different microclimates and (importantly) different radiant environments. While the air temperature difference between urban and rural areas usually does not change more than 1-4 C, the radiant environment can be very different (on the order of 10-15 C differences). The best way to understand UHI in this context is with Thermal satellite images, for which there is ha huge database of publicly available data on NASA's glovis website (http://glovis.usgs.gov/) or their ECHO website (http://reverb.echo.nasa.gov/reverb/#utf8=%E2%9C%93&spatial_map=satellite&spatial_type=rectangle). I tend to use thermal data from LANDSAT 5-8 and ASTER satellites in my research. Unfortunately, there is a lot f bad data with a lot of cloud cover mixed in with the really good stuff and it can take some time to find good images. Also, there aren't too many programs that read the GeoTiff file format that you download the data as. I know that ArcGIS will read it, a program called ENVI will read it (I think that the open source QGIS can also red it). I have plans to write a set of components to bring this type of data into Rhino and GH (I may get to it a few months down the line).
4) UHI as a computer model-able notion of "Urban Microclimate" with consideration of local differences and the local radiant environment:
This is where a lot of my research has lead and, thankfully, is an area that Honeybee can help you out a lot with. EnergyPlus simulations can output information on outside building surface temperatures and these can be very helpful in helping get a sense of the radiant environment around individual buildings. Right now, I am focusing just on using this data to fully model the indoor environments of buildings as you see in this video:
https://www.youtube.com/watch?v=fNylb42FPIc&list=UUc6HWbF4UtdKdjbZ2tvwiCQ
I have plans to move this methodology to the outdoors once I complete this initial application to the indoors. For now, you can use the "Surface result reader" and the "color surfaces based on EP result" components to get a sense of variation in the outside temperature of your buildings.
I hope that this helped,
-Chris
…
it seems that was this. Now all is working fine !
Glad that it worked! But I am still a bit worried. Gismo components only modify the gdal-data/osmconf.ini file and no other MapWinGIS file. So your MapWinGIS installation files should not be compromised. The fact that you did not get the "COM CLSID" error message when running the "Gismo Gismo" component suggests that MapWinGIS has been properly installed. So I wonder if the cause for the permanent "invalid shapes" warning has again something with the fact that your system is again not allowing the MapWinGIS to properly edit the osmconf.ini. Maybe this problem will appear again, and again, and reinstallation of MapWinGIS every time can be somewhat bothersome.
- About the terrain generation, is it possible to have the texture from google or other provider mapped onto the terrain surface from gismo component ? (Same as using the ladybug terrain generator in fact). I try to used the image extracted by ladybug component and then applied it to the gismo terrain but the texture is rotated by 90°.
The issue with the rotation can be solved by swapping/reversing the U,V directions of the terrain surface. A slightly more important issue is that terrain surface generated with Gismo "Terrain Generator" component might have a bit smaller radius than what the radius_ input required. This stems from the fact that the terrain data first needs to be downloaded in geographic coordinate system, and then projected. Some projecting issues may occur at the very edges of the projected terrain, so I had to slightly cut out the very edges of the terrain which results in the actual terrain diameters being slightly shorted in both directions. This means that if you apply the same satellite image from Ladybug "Terrain Generator" component to Gismo "Terrain Generator" component the results may not be the same.I attached below a python component which tries to solve this issue by extending the edges of Gismo "Terrain Generator" terrain, and then cutting them with the cuboid of the exact dimensions as the radius_ input. Have in mind that this extension of the original terrain at its edges is not a correct representation of the actual terrain in that location. But rather just an extension of the isoparameteric curve of the terrain surface. So basically: some 0 to 10% (0 to 10 percent of the width and length) of the terrain around all four edges is not the actual terrain for that location, but rather just its extension.The python component is located at the very right of the definition attached below.
Also, if you would like to use the satellite images from Ladybug "Terrain Generator" component along with "OSM shapes", sometimes you may find slight differences in position of the shapes. This is due to openstreetmap data not being based on Google Maps (that's what Ladybug "Terrain Generator" component is using), but rather on Bing, MapQuest and a few others.
- About the requiredKeys_ input of OSM shapes, I understand what you mean and your advice, but in most cases I use it, the component was working fine even without input. I think it's better to extract all tags, values and keys of the selected area, instead of searching for specific ones as I try to find all data related to what I want after, isn't it ? To check what keys are present on the area also.
Ineed, you are correct.I though you were trying to only create a terrain, 3d buildings and maybe find some school or similar 3d building, for these two locations. The recommendation I mentioned previously is due to shapefiles having a limit (2044) to how many keys it can contain. This requires further testing of some big cities locations with maybe larger radii, which I haven't performed due to my poor PC configuration. But in theory, I imagine that it may happen that a downloaded .osm file may have more than 2044 keys. In that case shapefile will only record 2044 of them, and disregard the others. That was my point.But again 2044 is a lot of keys, and I haven't been checking much this in practice. For example, when I set the radius_ to 1000 meters, and use your "3 Rue de Bretonvilliers Paris" location I get around 350 something keys, which is way below the 2044.Another reason why one should use the requiredKeys_ input is to make the Gismo OSM components run quicker: for example, the upper mentioned 350 something keys will result in 350 values for each branch of the "OSM shapes" component's "values" output.Which means if you have 10 000 shapes, the "OSM shapes" component will have 10 000 branches with 350 items on each branch (values). This can make all Gismo OSM components very heavy, and significantly elongate the calculation process.With requiredKeys_ input you may end up with only a couple of tens of items per each branch.Sorry for the long reply.…
Added by djordje to Gismo at 8:57am on June 11, 2017
ight be able to provide more insight). Whenever you run a new simulation in Radiance, it is not always necessary to re-write all of the initial simulation files from scratch. These initial simulation files include both a .rad geometry file as well as a separate .pts file that contains the test point locations. If all that you are changing in a given parametric run is the locations of the test points (like your case), it is not necessary to re-write (or reinterpret) the entire .rad geometry file. My guess is that there is some type of check for this built into either code Mostapha wrote or radiance functions that Mostapha is calling. As such, it seems that the rad geometry file is not being re-written (or re-interpreted by radiance) completely when all that you change is the test points and this actually seems to be saving you an extra 10 seconds each time that you run the component without changing the materials or the building geometry. Other times (like when you plug in custom radParameters), it seems that it re-writes (or re-interprets) the .rad geometry file from scratch since this file is probably affected by customized rad parameters.
So far, if this explanation is holding, it seems like there would be no concern on your end but I also recognize that the difference between these long and short simulations is giving you radiation results that are ever so slightly different from each other (by my estimates, they differ by about 0.2%). Compared to the other types of assumptions that the radiance model is making, though, these are mere rounding errors that probably originate from the number of decimal places in the vertices of the rad geometry file. Rather than worrying about whether your simulations are giving you the right rounding errors to give you matching results, I would encourage you to instead contemplate how much your radiance results are matching reality given all of the assumptions that you are making about the climate (with the epw file for a "typical" year) and with the number of light bounces in the radiance simulation. To give you an example, I ran your model with a higher quality of simulation type (3 ambient bounces) and this gives you results that differ by 1.1% from the original simulation that you were running with only 2 ambient bounces (this is practically an order of magnitude larger than 0.2%).
To address your unease I will say that, for a long time, I also felt uneasy any time that I encountered something that seemed unpredictable in software that I was using. Once I started coding my own stuff, though, I realized quickly that unpredictable behavior is an unavoidable aspect of all software. There is always a tradeoff between accurate results and the time it takes to get them, which produces a multitude of possible ways to arrive at a solution. Add into this complex situation the fact that you might have an almost infinite number of possible inputs to a given set of code.
Because of the unpredictable multitude of cases, there is no application that is completely free from limitations and assumptions. In this light, what ends up being more important than the actual calculation method used is the social infrastructure that is in place to help understand what is being run under the hood, hence why both Radiance and Honeybee are open source and why we try to build a robust community of support through forums like this one!
-Chris…
bsp;
-Vehicle elements (3D objects and a component for custom vehicles; models from Google Warehouse)
-Traffic Velocity Graphs, drawn on every trajectory curve (allow custom graphs drawn)
-Traffic regulation elements (such as Traffic Lights and Stop Signals) and traffic density
-Particle Systems on trajectory curves, just to manage the traffic regulations and avoid collisions based on security distances
-Traffic Vehicle Animation Modes (Dots, Bounding Boxes or complex Meshes with attributes for final rendering (Giulio Piacentino´s Render Animation)
-Vehicle Lights and Vehicle Sights, to make visual studies
Team:
-Sergio del Castillo Tello (Doctor No, lead programmer)
-Everyone that wants to be involved, support.. these tools
The development of Roadrunner is planned to take part within a Research Group Program at ETSAM (University of Architecture in Madrid); This forum group is created just to test the interest of the community, while we keep on developing (it is still being tested), probably we will share the whole thing in the future. Cheers!
Traffic Cluster Scheme
Traffic Elements
Traffic Urban Systems
Vehicle Elements
Roadrunner - overview
Roadrunner 0 Basics
Roadrunner 1 Modes
Roadrunner 2 Elements
Roadrunner 3 Urban Systems…
me of the dimensions that changed ( become Diagonal after they were Vertical or Horizontal)
I sometime use Record History in rhino for saving time, but when I change some points of curves or trim curves , I have problems with dimensions (see the two pictures below).
Problem 2 :
After trimming , only two dimensions should be changed depending on their place in changed curves . But what happens is that all the dimensions become crazy!!!!!!
I always use Aligned dimension in rhino. Now I know that dimensionsdo not exist in grasshopper. So I ask you if we have expertise in BV , C#, can we create a script for dimensions or is it impossible ??
If we can , I only need Aligned dimension.
I hope that I find or create a script that can define all points: start and end of curve ribs and create dimensions from grasshopper to rhino directly with or without the ability to change automatically .
Thank you
…
occur more than once in the same list, and different elements with identical values can occur more than once. Also, a list may contain lack of elements, referred to as "nulls".
Sets. Strictly speaking a Set is a mathematical construct which adheres to a strict collection of rules and limitations. Basically, a Set is the same as a List, with the exception that it cannot contain the same element more than once, or indeed two or more different elements with the same values. You see, in mathematics there is no difference between a value and an instance of that value, they are the same thing. In programming however it is possible to store the number 7 in more than one spot in the RAM. Grasshopper does not enforce this rule very strongly though, you can use a lot of Set components on lists that have multiple occurrences of the same value. The big difference between Lists and Sets in Grasshopper is that Sets are only defined for simple data types that have trivial equality comparisons. Basically: booleans, integers, numbers, complex numbers, strings, points, vectors, colours and intervals. Lists can contain all kinds of data.
Strings. Strings are text. There's nothing more to it. I don't know why early programmers chose to call them strings, but I suppose it's a better description of the memory representation of them. Strings are essentially sequences of individual characters.
Trees. Trees are the way all data is stored in Grasshopper. Even when you only have a single item, it will still be stored in a tree. A tree is a sorted collection of lists, where each list is identified by a path. A specific path can only occur once in a tree, when you merge two trees together, lists with identical paths are appended to each other. Trees are an attempt to losslessly represent not just the data itself, but also the history of that data. Imagine you have 4 curves {A,B,C,D} and you divide each into 3 points {X,Y,Z}. Then, for each of those points you create a new line segment {X',Y',Z'} and then divide each of those line segments again into 5 points each {K,L,M,N,O}. The way data is stored in trees, it should be possible to figure out whether a point M belongs to X' or to Z', and whether that X' or Z' came from A, B, C or D. This is why paths are often quite long after a while, because they encode a lot of history.
Paths. A Path is nothing more than a list of integers. It's denoted using curly brackets and semi-colons: {A;B;...;Z}. A Path should never be empty {} or have negative integers {0;-1}, but it is certainly possible to create a path like this and it probably won't even crash Grasshopper. Paths are 'grown' by components that (potentially) create more than one output value for a single input value. For example Divide Curve. It creates N points for every single input curve. In cases like this a new integer is appended to the end of the path.
In the next release the Path logic in Grasshopper is somewhat different. I fixed a number of obscure bugs (hopefully without introducing new fresh bugs) and special cased certain operations to somewhat reduce the speed at which paths grow. This may well break files that rely on a specific tree layout, but I hope the temporary sacrifice will be worth the long-term benefits.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
nts for Ladybug too. They are based on PVWatts v1 online calculator, supporting crystalline silicon fixed tilt photovoltaics.
You can download them from here, or use the Update Ladbybug component instead. If you take the first option, after downloading check if .ghuser files are blocked (right click -> "Properties" and select "Unblock").
You can download the example files from here.
Video tutorials will follow in the coming period.
In the very essence these components help you answer the question: "How much energy can my roof, building facade, solar parking... generate if I would populate them with PV panels"?
They allow definition of different types of losses (snow, age, shading...) which may affect your PV system:
And can find its optimal tilt and orientation:
Or analyse its performance, energy value, consumption, emissions...
By Djordje Spasic and Jason Sensibaugh, with invaluable support of Dr. Frank Vignola, Dr. Jason M. Keith, Paul Gilman, Chris Mackey, Mostapha Sadeghipour Roudsari, Niraj Palsule, Joseph Cunningham and Christopher Weiss.
Thank you for reading, and hope you will enjoy using the components!
EDIT: From march 27 2017, Ladybug Photovoltaics components support thin-film modules as well.
References:
1) System losses:
PVWatts v5 Manual, Dobos, NREL, 2014
2) Sun postion equations by Michalsky (1988):
SAM Photovoltaic Model Technical Reference, Gilman, NREL, 2014
edited by Jason Sensibaugh
3) Angle of incidence for fixed arrays:
PVWatts Version 1 Technical Reference, Dobos, NREL, 2013
4) Plane-of-Array diffuse irradiance by Perez 1990 algorithm:
PVPMC Sandia National Laboratories
SAM Photovoltaic Model Technical Reference, Gilman, NREL, 2014
5) Sandia PV Array Performance Module Cover:
PVWatts Version 1 Technical Reference, Dobos, NREL, 2013
6) Sandia Thermal Model, Module Temperature and Cell Temperature Models:
Photovoltaic Array Performance Model, King, Boys, Kratochvill, Sandia National Laboratories, 2004
7) CEC Module Model: Maximum power voltage and Maximum power current from:
Exact analytical solutions of the parameters of real solar cells using Lambert W-function, Jain, Kapoor, Solar Energy Materials and Solar Cells, V81 2004, P269–277
8) PVFORM version 3.3 adapted Module and Inverter Models:
PVWatts Version 1 Technical Reference, Dobos, NREL, 2013
9) Sunpath diagram shading:
Using sun path charts to estimate the effects of shading on PV arrays, Frank Vignola, University of Oregon, 2004
Instruction manual for the Solar Pathfinder, Solar Pathfinder TM, 2008
10) Tilt and orientation factor:
Application for Purchased Systems Oregon Department of Energy
solmetric.com
11) Photovoltaics performance metrics:
Solar PV system performance assessment guideline, Honda, Lechner, Raju, Tolich, Mokri, San Jose state university, 2012
CACHE Modules on Energy in the Curriculum Solar Energy, Keith, Palsule, Mississippi State University
Inventory of Carbon & Energy (ICE) Version 2.0, Hammond, Jones, SERT University of Bath, 2011
The Energy Return on Energy Investment (EROI) of Photovoltaics: Methodology and Comparisons with Fossil Fuel Life Cycles, Raugei, Fullana-i-Palmer, Fthenakis, Elsevier Vol 45, Jun 2012
12) Calculating albedo: Metenorm 6 Handbook part II: Theory, Meteotest 2007
13) Magnetic declination:
Geomag 0.9.2015, Christopher Weiss…