Search Results - 分分快3最准高手助赢计划-『8TBH·COM』福利彩票开奖结果012期查询--2023年3月19日6时48分50秒.H5c2a3.5jexii16x-gov-hk

Comment on: Topic 'How can I sort in two dimensions?': you may know, PCS (from now I will call polar coordinate system with PCS, and cartesian one with CCS) describes point position with 2 values (like x and y in CCS) which are r and theta(r,theta). r is for distance from PCS center, theta is angular dimension which is in 0 to 360 or 0 to 2*pi domain. To hark back to David's guide line - here it is replaced with guide circle. Why to sort points like this ? As usual, one image tells more... Here is logic behind all this stuff : Find an average point of all given points* Search for furthest point from an average point* Create a circle with center at average point and radius = distance from average point to furthest point* *Steps 1-3 can be replaced with custom hand-made circle, I decided to automate it that way. For each point find closest point on circle - this will be used for finding theta value For each point find distance to average point - this is r value To overcome problem with same theta (t) values (like same x values in CCS), instead of multiplying by 1000, we will use a new create set component. This component creates set of integers, each one representing one unique input value. So if points A, B, C, D, E are (r,theta) : A (1, 30) B (2, 30) C (3, 30) D (1, 45) E (1, 60) Then create set will output list of integers = 0,0,0,1,2 (same theta for A, B, C other theta for D and E). Now its getting really easy - remap r values to domain 0 to 0.5 (or any less then 1), and add integers from create set component to remapped r values. 7. So what we have now is list of floating point numbers : A=0, B=0.25, C=0.5, D=1, E=2 Profit of remapping is that r values will never affect integers representing theta values - and all the information is stored in one floating point number ! By sorting these values we will obtain proper order of points - to complete this, we need to sort points parallel with values. What's really cool about polar sorting - there could be any amount of points, but polyline connecting all of them will never self-intersect. Probably there is some relation with 2d convex hull.…; Added by Mateusz Zwierzycki at 11:03am on May 23, 2012

Comment on: Topic 'Hardware requirements and suggestions': east make all our algorithms thread-safe, so they can all be called from multiple threads, this is the first step towards multi-threading. But multi-threading is not just something you switch on or off, it's an approach. Let's take the meshing of Breps for example. Let's assume that at some point one or more breps are added to the document. The wireframes of these breps can be drawn immediately, but the shading meshes need to be calculated first. How do we go about doing this? Allow me to enumerate some obvious solutions: We put everything on hold and compute all meshes, one at a time. Then, when we're done we'll yield control back to the Rhino window so that key presses and mouse events can once again be processed. This is the simplest of all solutions and also the worst from the users point of view. We allow the views to be redrawn, mouse events and key presses to be handled, but we perform the meshing in a background thread. I.e. whatever processor cycles are left over from regular use are now put to work on computing meshes. Once we're done computing these meshes we can start drawing the shaded breps. This is a lot better as it doesn't block the UI, but it also means that for a while (potentially a very long time) our breps will not be shaded in the viewport. This approach is already a lot harder from a programming perspective because you now have multiple threads all with access to the same Breps in memory and you need to make sure that they don't start to perform conflicting operations. Rhino already does this (and has been doing for a long time) on a lot of commands, otherwise you wouldn't be able to abort meshing/intersections/booleans etc. with an Escape press. So we can compute the meshes on the UI-thread or on a background thread. How about using our multiple cores to speed up the process? Again, there are several ways in which this can be achieved: Say we have a quad-core machine, i.e. four processors at our disposal. We could choose to assign the meshing of the first brep to the first processor, the second brep to the second processor, the third brep to the third processor and so on. Once a processor is done with the meshing of a specific brep, we'll give it the next brep to mesh until we're done meshing all the breps. This is a good solution when multiple breps need to be meshed at once, but it doesn't help at all if we only need to compute the mesh for a single brep, which is of course a very common case in Rhino. To go a level deeper, we need to start adding multi-threading to the mesher itself. Let's say that the mesher is set up in such a way that it will assign each face of the brep to a new core, then -once all faces have been meshed- it will stitch together the partial meshes into a single large mesh. Now we've sped up the meshing of breps with multiple faces, but not individual surfaces. We can of course go deeper still. Perhaps there is some operation that is repeated over and over during the meshing of a single face. We could also choose to multi-thread this operation, thus speeding up the meshing of all surfaces and breps. All of the above approaches are possible, some are very difficult, some are actually not possible if we're not allowed to break the SDK. A further problem is that there's overhead involved with multi-threading. Very few operations will actually become 4 times faster if you distribute the work across 4 cores. Often one core will simply take longer than the other 3, often the partial results need to be aggregated which takes additional cycles and/or memory. What this means is that if you were to apply all of the above methods (multi-thread the meshing of individual faces, multi-thread the meshing of breps with multiple faces and multi-thread the meshing of multiple breps) you're probably worse off than you were before. -- David Rutten david@mcneel.com Poprad, Slovakia * an example would be the z-sorting of objects in viewport prior to repainting, which is a step performed on every redraw as far as I know.…; Added by David Rutten at 11:22am on July 9, 2012

Comment on: Topic 'Ideal Loads Outdoor Air Economizer': the results myself and I am open to changing the name/description of the input based on what you have found here. modulateFlowOrTemp is not the best name for what seems to be going on and we should change it to reflect more what is happening in the IDF. Here is how I am understanding the results of the different cases: 1) When the variable flow option is selected (and the outdoor air set to "None"), the heating and cooling of the space seems to happen only through re-circulation of the indoor air. My comparison to a VAV system was not appropriate and perhaps it would be better to compare it to a window air conditioner or a warm air furnace, which, as far as I understand, only re-circulate indoor air and do not bring in outside air. 2) My reasoning for the name modulateFlowOrTemp came mostly from my realization that the supply air temperature remained within the defined limits when the variable flow option is selected (and the outdoor air set to "None"). When the outdoor air was set to Maximum or Sum, the supply air temperature went way out of the temperature limits that I initially set. I realize now that the flows are varying in both cases and the name of the input really must change. 3) I think that the reason why we don't see any effect from the air side economizer is because the heating/cooling energy results that you get from an ideal air system are just the sum of the sensible and the latent heat added/removed from the zone by the system. This value of heat added or removed from the zone does not change whether the added/removed heat comes from outside air or from a cooling/heating coil. Since there is no cooling coil or boiler or chiller in an ideal air system, there is no way to request an output of the energy added/removed by such a coil or chiller as opposed to that removed/added by outside air. In other words, the air side economizer option on the ideal air system is practically useless because it does not help us differentiate the cooling that comes from the outside air vs. that which comes from a coil. All that it does is change the outdoor air fraction while keeping the reported cooling/heating values the same. Please let me know if you think that this explanation makes sense, Burin and, in light of all this, I am very interested in your suggestions. From my own perspective, I am now convinced that the default should definitely have the outside air requirements set to "None" since, otherwise, we cannot distinguish cooling/heating that happens from addition of outside air and that which must be supplied by a coil. At least when we get rid of the outside air requirement, we can be sure that the ideal air system values are only showing heating/cooling from a coil or HVAC system. I have decided to remove the airsideEconomizer input since it seems to give misleading expectations. I am going to recommend here on out that, if you want to estimate the effect of increasing outside air on cooling, you should use the "Set EP Airflow" component, use fan-driven natural ventilation, and you should connect a custom CSV schedule of airflow. You will have to create such a schedule with native GH components using the outside air temperature, your zone setpoints, and the times that you are cooling in your initial run of E+. Either you do this or you set up a full-blown system with OpenStudio. I have also decided to get rid of the heatRecovery input since it seems like this will also produce misleading expectations by the same logic. Lastly, I am going to change the name of the modulateFlowOrTemp_ input to outdoorAirReq_. The default will be to have no indoor air requirement as stated above but you can input either "maximum" or "sum" to have the IDF run accordingly. Let me know if this sounds good or if you have suggestions. Updated GH file attached. The github has the new Ideal Air Loads component. Make sure that you have sync correctly and restart GH after updating your components. -Chris…; Added by Chris Mackey to Ladybug Tools at 2:11am on March 1, 2015

Comment on: Topic 'what's meaning of value in the panel': e current data should be turned to be original data, is that right?there are 3 cases. what do this components effect the performance after if i turn the component to be flatten and graft and to connect to other component? {, is that0} {0;0} {0;0;0} {0;0;0;0} {0;0;0;0;0} {0;0;0;0;0;0}…; Added by Joyce Ho at 7:53am on July 4, 2015

Comment on: Topic 'Building a computer around Kangaroo Physics/Grasshopper': with this machine. As Jason says, Rhino and Grasshopper are mainly single-threaded, so I prioritized single core speed and got an i7 4790k, which comfortably overclocks to 4.7GHz (with a decent air cooler, but no fancy liquid cooling). The Kangaroo2 solver is actually multi-threaded now, but the difference this makes is not great as you might imagine. Using 4 cores is certainly nowhere near 4 times faster, because although parts of the calculation are easily parallelized, everything still needs to be recombined at each iteration, and this is usually the bottleneck. I think there is still room for some improvement in how it is multi-threaded, but I wouldn't hold your breath for any massive changes on this front soon. I'd be interested to know how the performance scales with the Xeon chips (more cores, significantly more expensive, but relatively low clock speeds). At the time I made the guess that they weren't worth it, but it would be good to really test this out. RAM is relatively cheap these days, so I went with 32GB of it at 2133MHz. It does seem that the speed of the RAM matters, as enabling XMP in the BIOS (to make it run above the default 1333) seemed to make a noticeable difference. Graphics-wise my personal feeling is that the gaming oriented GTX cards offer better value than the much more expensive 'professional' Quadro range - and have read that the hardware between the 2 has historically been very similar or even identical despite the Quadros being several times the price, with the difference being mainly in the drivers. There are some threads on discourse.mcneel.com about this, and it seems that recent GTX cards like the 970 do very well in Holomark (the Rhino performance benchmarking tool). I got a GTX 770 (this was just before the 900 series came out), which is probably way overkill just for Rhino/Grasshopper, as they don't use the GPU for more than display (Though some of the render plugins do, and I think for those more CUDA cores is what matters, so there GTX is probably still better value.) Probably swapping this for a much cheaper card wouldn't make much difference to Rhino/GH performance anyway (though if you want to use the PC for other stuff like gaming or virtual reality it does). I don't have much experience with AMD cards, so can't comment on how they compare to Nvidia. Eventually I do hope to make Kangaroo run the physics on the GPU, and potentially this does have a big speed impact. Nvidia recently released some impressive demos of their FLEX engine, which really fly with a decent graphics card. That is very much game-physics, and not suitable for most of the things Kangaroo is used for, but theoretically Kangaroo could also be adapted to use CUDA (or OpenCL), though it involves a lot of big changes, and I don't have a timeline for this yet. In the much shorter term there are some things in the pipeline that should speed up Kangaroo for certain things like collisions between large numbers of objects, just by using some different algorithms. Altogether my machine was still well under €2K, and I've been really happy with it. That said, the difference in performance between this and my 4 year old €700 i5 laptop is actually not that huge in day-to-day Grasshopper usage. It does seem that there is a strong case of diminishing returns with buying a PC - I'd hazard a guess that even spending 3 times this amount (as another thread on this forum was discussing recently) you'd be hard pushed to get anything that made a really significant difference to the experience of using it, and if you really want to spend more money, you would be better off just upgrading more frequently (and getting a nice monitor(s)). Anyway, a long ramble, I hope some of it is useful. As I said, I'm no hardware expert, and would be interested to hear different opinions. I also think it will be nice to make a simple benchmarking tool for Kangaroo and have people run it on their various machines and report back results (as with Holomark), to help others make informed decisions on these things. I'll try and put something together for this soon. …; Added by Daniel Piker to Kangaroo at 4:53am on July 13, 2015

Topic: Orientation Study: onents (radiation, sunlight-hours and view analysis) which let you study the effect of the orientation of your building and the analysis result. When you come to a question similar to "what is the orientation that the building receives the most/least amount of radiation?" is probably the right time to use this component. HOW? I'll try to explain the steps using a simple example. Here is my design geometries. The building in the center is the building to be designed and the rest of the buildings are context. I want to see the effect of orientation on the amount of the radiation on the test building surfaces from the start of Oct. to the end of Feb. for Chicago. First I need to set up the normal radiation analysis and run it for the building as it is right now. [I'm not going to explain how you can set up this since you can find it in the sample file (Download the sample file from here)] Now I need to set up the parameters for orientation study using orientationStudyPar component. You can find it under the Extra tab: At minimum I need to input the divisionAngle, and the totalAngle and set runTheStudy to True. In this case I put 45 for divisionAngle and 180 for the totalAngle which means I want the study to be run for angles 0, 45, 90, 135 and 180. [Note1: The divisionAngle should be divisible by totalAngle.] [Note 2: If you don't provide any point for the basePoint, the component will use the center of the geometry as the center of the rotation.] [Note 3: You can also rotate the context with the geometry! Normally you don't have the chance to change the context to make your design work but if you got lucky the rotateContext input is for you! Set it to True. The default is set to False.] You're all set for the orientation study, just connect the orientationStudyPar output to OrientationStudyP input in the component and wait for the result! The component will run the study for all the orientations and preview the latest geometry. To see the result just grab a quick graph and connect it to totalRadiation. As you can see in the graph 135 is the orientation that I receive the maximum radiation. Dang! If you want to see all the result geometries set bakeIt to True, and the result will be baked under LadyBug> RadaitionStudy>[projectname]> . The layer name starts with a number which is the totalRadiation. Mostapha…; Added by Mostapha Sadeghipour Roudsari to Ladybug Tools at 3:31pm on February 17, 2013

Topic: Shaded/Rendered View Memory Leak during script?: ly this is a Rhino.Python problem and not a Grasshopper issue, but it could apply to both! I was trying to take a simple example of moving a ball around and see how it could be animated through Rhino.Python. The code works great in wire frame with now memory issues at all. However, when I switch the view to Shaded or Rendered, things go south pretty quickly. The RAM usage of Rhino which was steady around 350mb (ish) now grows every frame after a minute or so, it is in the GB's and never drops even after the script has stopped.What gives? Clearly this must be possible because Bongo does something similar when it does animations. Check out my code below and I would love to hear your thoughts. import time import rhinoscriptsyntax as rs import Rhino height = 100 width = 100 x = 0 y = 0 xspeed = .1 yspeed = .3 start_time = time.time() end_time = 60 run_time = 0 sphere = rs.AddSphere((x,y,0), 5) while run_time < end_time: x = x + xspeed y = y + yspeed if x > width/2 or x < -width/2: xspeed = xspeed * -1 if y > height/2 or y < -height/2: yspeed = yspeed * -1 rs.MoveObject(sphere, (xspeed, yspeed, 0)) Rhino.RhinoApp.Wait() run_time = time.time() - start_time…; Added by Ryan Gathmann at 8:33am on May 3, 2013

Topic: Cooling and heating loads are missing from my output: ting. Thanks Rania ** Warning ** IP: Note -- Some missing fields have been filled with defaults. See the audit output file for details. ** Warning ** Version: in IDF="'8.2.7'" not the same as expected="8.2" ** Warning ** ManageSizing: For a zone sizing run, there must be at least 1 Sizing:Zone input object. SimulationControl Zone Sizing option ignored. ** Warning ** ManageSizing: For a plant sizing run, there must be at least 1 Sizing:Plant object input. SimulationControl Plant Sizing option ignored. ************* Testing Individual Branch Integrity ************* All Branches passed integrity testing ************* Testing Individual Supply Air Path Integrity ************* All Supply Air Paths passed integrity testing ************* Testing Individual Return Air Path Integrity ************* All Return Air Paths passed integrity testing ************* No node connection errors were found. ************* Beginning Simulation ************* Simulation Error Summary ************* ** Warning ** The following Report Variables were requested but not generated ** ~~~ ** because IDF did not contain these elements or misspelled variable name -- check .rdd file ************* Key=*, VarName=ZONE IDEAL LOADS SUPPLY AIR TOTAL COOLING ENERGY, Frequency=Hourly ************* Key=*, VarName=ZONE IDEAL LOADS SUPPLY AIR TOTAL HEATING ENERGY, Frequency=Hourly ************* Key=*, VarName=ZONE PACKAGED TERMINAL HEAT PUMP TOTAL COOLING ENERGY, Frequency=Hourly ************* Key=*, VarName=ZONE PACKAGED TERMINAL HEAT PUMP TOTAL HEATING ENERGY, Frequency=Hourly ************* Key=*, VarName=CHILLER ELECTRIC ENERGY, Frequency=Hourly ************* Key=*, VarName=BOILER HEATING ENERGY, Frequency=Hourly ************* Key=*, VarName=FAN ELECTRIC ENERGY, Frequency=Hourly ************* Key=*, VarName=ZONE IDEAL LOADS SUPPLY AIR LATENT HEATING ENERGY, Frequency=Hourly ************* Key=*, VarName=ZONE IDEAL LOADS SUPPLY AIR LATENT COOLING ENERGY, Frequency=Hourly ************* Key=*, VarName=ZONE IDEAL LOADS SUPPLY AIR SENSIBLE HEATING ENERGY, Frequency=Hourly ************* Key=*, VarName=ZONE IDEAL LOADS SUPPLY AIR SENSIBLE COOLING ENERGY, Frequency=Hourly ************* Key=*, VarName=SYSTEM NODE MASS FLOW RATE, Frequency=Hourly ************* Key=*, VarName=SYSTEM NODE TEMPERATURE, Frequency=Hourly ************* Key=*, VarName=SYSTEM NODE RELATIVE HUMIDITY, Frequency=Hourly ************* There are 3 unused schedules in input. ************* There are 5 unused week schedules in input. ************* There are 13 unused day schedules in input. ************* Use Output:Diagnostics,DisplayUnusedSchedules; to see them. ************* ************* ===== Recurring Surface Error Summary ===== ************* The following surface error messages occurred. ************* ************* Base Surface does not surround subsurface errors occuring... ************* Check that the GlobalGeometryRules object is expressing the proper starting corner and direction [CounterClockwise/Clockwise] ************* ** Warning ** Base surface does not surround subsurface (CHKSBS), Overlap Status=No-Overlap ** ~~~ ** The base surround errors occurred 1 times. ** ~~~ ** Surface "839A5ADACCE44BC0AF00_GLZP_31" misses SubSurface "839A5ADACCE44BC0AF00_GLZP_31_GLZ_31" ** Warning ** Base surface does not surround subsurface (CHKSBS), Overlap Status=Partial-Overlap ** ~~~ ** The base surround errors occurred 1 times. ** ~~~ ** Surface "839A5ADACCE44BC0AF00_GLZP_34" overlaps SubSurface "839A5ADACCE44BC0AF00_GLZP_34_GLZ_34" ************* ** ~~~ ** The base surround errors occurred 2 times (total). ************* ************* EnergyPlus Warmup Error Summary. During Warmup: 0 Warning; 0 Severe Errors. ************* EnergyPlus Sizing Error Summary. During Sizing: 2 Warning; 0 Severe Errors. ************* EnergyPlus Completed Successfully-- 7 Warning; 0 Severe Errors; Elapsed Time=00hr 07min 35.94sec…; Added by Ninja to Ladybug Tools at 11:34am on March 17, 2015

Topic: Moment Peaks in Shells/Plates at Point-Supports: : ---------------------------------------------------------------------------------------------- 1) Hi Clemens I've analysed a plate structure using Karamba and wanted to do a convergence analysis on results computed as a function of the number of elements. Now, when strictly looking at the result magnitudes of internal energy (IE) and maximum displacement (w_max), it's acceptable, that their relative deviations are very small. But I cannot explain the tendencies of their graphs. From what I know, FEM should always compute underestimated results when compared to analytical solutions. So I don't understand why both the IE and w_max seem to be decreasing for an increasing number of elements. But my main concern is the behaviour of the peak moment, it seems to be simply hill climbing untill suddenly a singularity kicks in. I initially wanted to use the peak moment as a fitness value for optimisation, but with this behaviour, I don't think that would make sense. I've attached my GH file as well. It would be much appreciated if you could enlighten me on these subjects. Cheers Daniel Andersen 2) Hi Daniel, I could not run your definition because I have not all the plug-ins installed that you use. You are basically right that the displacement should increase with a finer mesh. However the result of the shell analysis also depends on the shape of the triangles (well formed vs. very distorted). In order to test this, I think it would be interesting to use a very simple example (e.g. rectangular plate with one column) where you can easily control mesh generation. Would you like to start a discussion on this in the karamba group at http://www.grasshopper3d.com/group/karamba? It is not a good idea to use the bending moment at a singularity for optimization because the result will be heavily mesh dependent. Also real columns do have a certain diameter and modeling them as point supports introduces an error. Best, Clemens 3) oh, and by the way! Here's some relevant literature on handling peak moments: https://books.google.dk/books?id=-5TvNxnVMmgC&pg=PA219&lpg=PA219&dq=blaauwendraad+plates+and+fem&source=bl&ots=SdDcwnrSA1&sig=6HulPmKNIhqKx4_rGxitteMC4CU&hl=da&sa=X&ved=0CDEQ6AEwA2oVChMIg66k0LPaxgIVgY1yCh1KPAeY#v=onepage&q=chapter%2014&f=false (Blaauwendraad, J., 2010. Plates and FEM : Surprises and Pitfalls, see Chapter 14) It would be great if a feature dealing with peak moments could be incorporated in Karamba. In my work, I ended up exporting my models to Robot in order to verify the moment values. Best, Daniel 4) Hi Daniel, thank you for your reply and the link to Blaauwendraads excellent book! At some point I hope to include material nonlinearity in Karamba which will help in dealing with stress singularities. If you want you could open a discussion with a title like 'moment peaks in shells at point-supports'. Then we could copy and paste the text of our conversation into it. Best, Clemens ----------------------------------------------------------------------------------------------…; Added by Daniel Kolling Andersen to Karamba3D at 4:58am on July 17, 2015

Topic: Is it possible to call the functions of a Grasshopper component from inside a (C#/VB.Net/Python) script?: nside a script. However, it should be noted that to do so introduces a significant amount of overhead, which may impact performance. This is because (to the best of my understanding) all the methods described below actually instantiate and execute a virtual Grasshopper document, with components and everything else. Whenever possible, it is advisable to simply call RhinoCommon functions - these are designed to be called in code and are more streamlined. Python Grasshopper's Python is unique among the scripting languages in that it has a "node-in-code" mechanism for this purpose in the form of the ghpythonlib library and its "components" class. Here is some example code: from ghpythonlib import components as ghcomp import Rhino a = ghcomp.Circle(Rhino.Geometry.Plane.WorldXY,25.0) result = ghcomp.DeconstructBrep(b) faces = result[0] edges = result[1] vertices = result[2] This code will call the "Circle" component with the world XY base plane and a radius of 25, and then call the "Deconstruct Brep" component on a brep (input to the script as "b"). The arguments passed to the function will correspond to the inputs of the component, and the function will return the output (the data itself in the case of a component with only one output, and a tuple of data in the case of multiple outputs, as in the second example above). For more info on this technique, see this post by Steve Baer. C#/VB.Net James Ramsden has described a method for doing this in these two posts on his blog: Run a Grasshopper Component from C# Code Read and edit persistent data in Grasshopper components with C# His examples are in C#, but everything he describes can also be done in VB.net with some syntax tweaks. The core of his method is to programmatically instantiate a component, populate its inputs, and then create a virtual grasshopper document in which to execute the code. He then harvests the outputs and converts them back to simple data. Here is his example code for calling the "Circle by Normal and Radius" component: var cs = new CurveComponents.Component_CircleCNR(); //add the circle centre (input 0) var pp = cs.Params.Input[0] as Grasshopper.Kernel.GH_PersistentGeometryParam<Grasshopper.Kernel.Types.GH_Point>; pp.PersistentData.ClearData(); pp.PersistentData.Append(new GH_Point(new Point3d(0, 0, 3))); //add the circle radius (input 2) var pn = cs.Params.Input[2] as Grasshopper.Kernel.GH_PersistentParam<Grasshopper.Kernel.Types.GH_Number>; pn.PersistentData.ClearData(); pn.PersistentData.Append(new GH_Number(y)); //y is another variable //run calculations cs.ExpireSolution(true); //add to a dummy document so we can read outputs var doc = new Grasshopper.Kernel.GH_Document(); doc.AddObject(cs, false); //read output circle cs.Params.Output[0].CollectData(); A = cs.Params.Output[0].VolatileData.get_Branch(0)[0]; //remove that component doc.RemoveObject(cs.Attributes, false); Final notes For a great many of the simple components, there are in fact methods in RhinoCommon that accomplish exactly the same thing. Note the complexity of the above code, and then look at the equivalent code using RhinoCommon methods: Circle circle = new Circle(new Plane(origin, normal), radius); In my experience it is preferable to just call or construct the methods you need using RhinoCommon rather than relying on trying to call components from inside your code. Lastly, It is my understanding that this concept is central to David's thinking around GH2 - so that it in the next version it will be significantly more streamlined to switch between components and code representations. (I have no special knowledge of GH2 development - this is just what I have seen David say on the forums, and as usual any statements about future features are subject to change.) Hope this is helpful! …; Added by Andrew Heumann at 11:25am on December 9, 2015