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…
: ----------------------------------------------------------------------------------------------
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
----------------------------------------------------------------------------------------------…
the data structure of the input.
I'll create a component that aims to write all the GH_Paths inside the input data structure into separate output parameters. I'll add a menu item to the component that allows users to synch the number of outputs with the current data.
Note that there are some bugs I found related to Undo here, but I'll attempt to fix those asap. The mechanisms employed in this example are correct.
Let's start with the Component class definition and the constructor:
Public Class GH_ExampleComponent_VarOutput
Inherits GH_Component
Public Sub New()
MyBase.New("Extract Paths", "ExPath", "Extract all the paths from a tree", "Sets", "Tree")
End Sub
End Class
Now, the RegisterXXXXParams methods:
Protected Overrides Sub RegisterInputParams(ByVal pManager As GH_Component.GH_InputParamManager)
pManager.Register_GenericParam("Tree", "T", "Data tree to examine", GH_ParamAccess.tree)
End Sub
Protected Overrides Sub RegisterOutputParams(ByVal pManager As GH_Component.GH_OutputParamManager)
'We'll add one output parameter, just to not have a jagged output.
pManager.Register_PathParam("Path 1", "1", "1st path in tree")
End Sub
SolveInstance() is somewhat special, but not very complicated:
Protected Overrides Sub SolveInstance(ByVal DA As IGH_DataAccess)
'We have only one input parameter and it is set to Tree,
'so SolveInstance will only be called once for every solution.
'We don't actually need the data inside the input, we're only interested in the paths.
'So we don't actually need to call DA.GetDataTree, we can just go in and extract the
'paths directly:
Dim paths As IList(Of GH_Path) = Params.Input(0).VolatileData.Paths
'Abort if there is no tree.
If (paths.Count = 0) Then Return
'Post a warning if the number of output parameters does not
'equal the number of paths in the tree.
If (paths.Count < Params.Output.Count) Then
AddRuntimeMessage(GH_RuntimeMessageLevel.Warning, "There are more outputs than paths in the tree.")
ElseIf (paths.Count > Params.Output.Count) Then
AddRuntimeMessage(GH_RuntimeMessageLevel.Warning, "There are fewer outputs than paths in the tree.")
End If
'Iterate over all paths and assign to output parameters.
For i As Int32 = 0 To Math.Min(Params.Output.Count, paths.Count) - 1
DA.SetData(i, paths(i))
Next
End Sub
Adding a menu item to the component menu is relatively straightforward, however handling the menu command requires a fair bit of logic:
Protected Overrides Sub Menu_AppendCustomComponentItems(ByVal iMenu As System.Windows.Forms.ToolStripDropDown)
'Add a single item to the component menu.
Menu_AppendGenericMenuItem(iMenu, "Synch outputs", AddressOf Menu_SynchOutputClicked)
End Sub
Private Sub Menu_SynchOutputClicked(ByVal sender As Object, ByVal e As EventArgs)
'Here we have to synch the number of output parameters with the number
'of paths in the volatile data tree in the input parameter.
'This requires a few steps:
'1. Determine whether something needs to happen at all.
'2. Record an undo event.
'3. Remove excess outputs or add missing outputs.
Dim paths As IList(Of GH_Path) = Params.Input(0).VolatileData.Paths
If (paths.Count = Params.Output.Count) Then Return 'yay, nothing needs to be done.
'Something needs to be done, record an undo state.
RecordUndoEvent("Synch output")
'We either have too few or too many outputs, determine which is the case.
If (paths.Count > Params.Output.Count) Then
'Add the missing outputs
For i As Int32 = Params.Output.Count + 1 To paths.Count
Dim param As New Grasshopper.Kernel.Parameters.Param_GenericObject()
param.Name = "Path " & i.ToString()
param.NickName = i.ToString()
If (i.ToString.EndsWith("1")) Then
param.Description = i.ToString() & "st path in tree"
ElseIf (i.ToString.EndsWith("2")) Then
param.Description = i.ToString() & "nd path in tree"
ElseIf (i.ToString.EndsWith("3")) Then
param.Description = i.ToString() & "rd path in tree"
Else
param.Description = i.ToString() & "th path in tree"
End If
Params.RegisterOutputParam(param)
Next
Else
'Remove excessive outputs
Do
If (Params.Output.Count <= paths.Count) Then Exit Do
Dim param As IGH_Param = Params.Output(Params.Output.Count - 1)
Params.UnregisterOutputParameter(param)
Loop
End If
Params.OnParametersChanged()
ExpireSolution(True)
End Sub
Finally, we must make sure that the component properly (de)serializes. This means we have to override the Write and Read methods and add additional information to the GHX archive:
Public Overrides Function Write(ByVal writer As GH_IO.Serialization.GH_IWriter) As Boolean
'We must make sure that the number of output parameters is correctly stored.
'We'll use a special function on the GH_ComponentParamServer to accompish this
'without too much sweat.
Params.WriteParameterTypeData(writer)
Return MyBase.Write(writer)
End Function
Public Overrides Function Read(ByVal reader As GH_IO.Serialization.GH_IReader) As Boolean
'Very important, we must make sure all parameters exist before we
'start with the main deserialization.
Params.Clear()
Params.ReadParameterTypeData(reader)
Return MyBase.Read(reader)
End Function
I attached a VB file that contains the code outlined above.
--
David Rutten
david@mcneel.com
Seattle, WA…
Added by David Rutten at 11:43pm on October 27, 2010
eventually found out about genetic algorithms on which I found extensive researches, projects,... ! I looked into it and ended up on a few papers which I believe are the jumpstart for my master thesis.
"Galapagos; on the logic and limitations of generic solvers" by David RuttenArticle in Architectural Design 83(2) March 2013
"Black-box optimisation methods for architectural design" by Thomas Wortmann and Giacomo NanniciniConference Paper: CAADRIA 2016, At Melbourne, AU, Volume: 177-186
So I started looking into alternatives to genetic algorithms in architectural design.So far, I've ended up on :
Thomas Wortmann's work with the surrogate(or model) based optimization approach!You can check out the tool he developped for GH (Opossum):http://www.food4rhino.com/app/opossum-optimization-solver-surrogate-models
Judyta Cichocka's work, specially with the Swarm approachYou can check out the tool she developped for GH (Silvereye):http://www.food4rhino.com/app/silvereye-pso-based-solver
And that's it !!! I've been researching through article references (mainly on "researchgate") but I'm now stuck in a loop of references I already visited!That probably means the litterature on the subject is not (yet) extended but I might probably be missing something.The keywords make it difficult to search : "optimisation", "algorithms", "architecture", send me most of the time to computational engineering and deep mathematics papers I unfortunately do not have the background knowledge to comprehend ! So there it is ! If you have any clue of where (or how ! ) I should be looking, please tell me :)I know Mr Rutten is pretty active on the forum so hopefully... (fingers crossed :p) !Also if you have any good tips for getting into algorithms in general (you think could help), I'd be glad to hear(read) it ! A book, tutorials maybe ?!So, autors, architects, projects books, articles, conferences I should go to,specialized architecture offices/studios (I'm also looking for an internship so ...).If you know about a more appropriate forum please let me know !If you want to get deeper into this, you can contact me at :
e1635331@student.tuwien.ac.at
tdissaux@student.ulg.ac.be
My master thesis is due for may 2018 but I have a paper to write for January 2018 in order to be elligible for a PHD program afterwards.What I mean by that is that if you read this message in 6 month, I'll still be open to discussion !
I am right now an erasmus student at TUWien (Vienna) but my main university is The university of Liège in Belgium.I can handle French, English, Italian litterature and eventually Dutch if really you think it's worth it ! I have access to most online libraries via my university's portals so access shouldn't be an issue !I'm very excited to hear from you I wish you all a great day,Cheers,Thomas
…
via MIDI controllers.
my idea is to link PureData to GH via UDP. why pure data? cause' i can relate data like GH to generate numeric relations (and link it to audio generation)
so far i got PD and Processing to talk, but i can't get to grasshopper.
i use this definitions to make pd and processing to talk http://ubaa.net/shared/processing/udp/ and this GHX to get the data to GH http://www.grasshopper3d.com/forum/attachment/download?id=2985220%3...
i got this data from this post but the GH definition doesn't work for me. i have tried LAN definitions and "the engine" as well but they both freeze, even if i send data thru processing or PD.
i have a lot of questions at this time
1.- why processing tells me that i am getting the data from diferent ports, while i'm using 6000?
2.- why in the UDP definition i get no data out, even if it should say something like "waiting fordata/port/etc.." that's defined in the C# capsule
3.- is there a direct way to get midi data (key and CC) to GH
i also tried to use firefly to get the data via COM port. i know you can do this trick in processing but i just don't know how.
well. if anyone could help me i would share the results here (since it's a magister, results shoud be very interesting)
UDP has allways been a unsolved issue on other posts. maybe we could work it out ;)
Thanks…
Added by jota aldunce at 8:43am on September 28, 2010
mplex the models are. If we are running multi-room E+ studies, that will take far longer to calculate.
Rhino/Grasshopper = <1%
Generating Radiance .ill files = 88%
Processing .ill files into DA, etc. = ~2%
E+ = 10%
Parallelizing Grasshopper:
My first instinct is to avoid this problem by running GH on one computer only. Creating the batch files is very fast. The trick will be sending the radiance and E+ batch files to multiple computers. Perhaps a “round-robin” approach could send each iteration to another node on the network until all iterations are assigned. I have no idea how to do that but hope that it is something that can be executed within grasshopper, perhaps a custom code module. I think GH can set a directory for Radiance and E+ to save all final files to. We can set this to a local server location so all runs output to the same location. It will likely run slower than it would on the C:drive, but those losses are acceptable if we can get parallelization to work.
I’m concerned about post-processing of the Radiance/E+ runs. For starters, Honeybee calculates DA after it runs the .ill files. This doesn’t take very long, but it is a separate process that is not included in the original Radiance batch file. Any other data manipulation we intend to automatically run in GH will be left out of the batch file as well. Consolidating the results into a format that Design Explorer or Pollination can read also takes a bit of post-processing. So, it seems to me that we may want to split up the GH automation as follows:
Initiate
Parametrically generate geometry
Assign input values, material, etc.
Generate radiance/ E+ batch files for all iterations
Calculate
Calc separate runs of Radiance/E+ in parallel via network clusters. Each run will be a unique iteration.
Save all temp files to single server location on server
Post Processing
Run a GH script from a single computer. Translate .ill files or .idf files into custom metrics or graphics (DA, ASE, %shade down, net solar gain, etc.)
Collect final data in single location (excel document) to be read by Design Explorer or Pollination.
The above workflow avoids having to parallelize GH. The consequence is that we can’t parallelize any post-processing routines. This may be easier to implement in the short term, but long term we should try to parallelize everything.
Parallelizing EnergyPlus/Radiance:
I agree that the best way to enable large numbers of iterations is to set up multiple unique runs of radiance and E+ on separate computers. I don’t see the incentive to split individual runs between multiple processors because the modular nature of the iterative parametric models does this for us. Multiple unique runs will simplify the post-processing as well.
It seems that the advantages of optimizing matrix based calculations (3-5 phase methods) are most beneficial when iterations are run in series. Is it possible for multiple iterations running on different CPUs to reference the same matrices stored in a common location? Will that enable parallel computation to also benefit from reusing pre-calculated information?
Clustering computers and GPU based calculations:
Clustering unused computers seems like a natural next step for us. Our IT guru told me that we need come kind of software to make this happen, but that he didn’t know what that would be. Do you know what Penn State uses? You mentioned it is a text-only Linux based system. Can you please elaborate so I can explain to our IT department?
Accelerad is a very exciting development, especially for rpict and annual glare analysis. I’m concerned that the high quality GPU’s required might limit our ability to implement it on a large scale within our office. Does it still work well on standard GPU’s? The computer cluster method can tap into resources we already have, which is a big advantage. Our current workflow uses image-based calcs sparingly, because grid-based simulations gather the critical information much faster. The major exception is glare. Accelerad would enable luminance-based glare metrics, especially annual glare metrics, to be more feasible within fast-paced projects. All of that is a good thing.
So, both clusters and GPU-based calcs are great steps forward. Combining both methods would be amazing, especially if it is further optimized by the computational methods you are working on.
Moving forward, I think I need to explore if/how GH can send iterations across a cluster network of some kind and see what it will take to implement Accelerad. I assume some custom scripting will be necessary.…
re are major changes and enhancements.
HONEYBEE
More Flexible Workflow - Many small modifications were made to support a more flexible workflow, such as the ability to separate a zone created with masses2Zones into editable HBSrfs that can be recombined. For the energy components, it is now possible to plug custom constructions directly into the components that set the zone constructions without writing them first into the library. For the daylighting components it is now possible to change all of the materials of specific surface types at once.
Support for Complex Geometry - Many small bugs for complex geometry have been fixed including the ability to import energy results correctly for curved NURBS surfaces as well as unconventional window configurations. Also, the intersectMasses component now almost always succeeds in splitting all of the surfaces of adjacent zones, no matter how complex the intersection is.
Automatic Download Issues Fixed - Many users who faced issues with not having “gendaymtx.exe” or who had trouble syncing with our github know that we faced an issue with automatic background downloads.
Air Walls - Honeybee EnergyPlus models now officially support air walls (or virtual partitions) in a basic implementation. Now, any time that you use the air wall construction or set a surface type to “air wall,” the air between adjacent zones will be automatically mixed. At present, this mixing is just a constant flow based on the surface area between zones connected by air walls multiplied by an adjustable “flow factor.” It is important to stress that this basic air mixing is not with the EnergyPlus Airflow Network, although the groundwork laid in this release will eventually allow for the implementation of the Airflow Network in future releases. As such, this present air mixing is only suitable for multi-zone conditions where there is not significant buoyancy-driven flow between zones.
Natural Ventilation - To go along with the new potential introduced by air walls, there has been a basic implementation of EnergyPlus’s natural ventilation objects in a new component called “Set EP Airflow”. The current setup allows for three possible types of natural ventilation: 1) natural ventilation through windows (with auto-calculated flow based on window area, outdoor wind speed/direction, and stack effects), 2) custom wind and stack objects that can be used to model things such as chimneys off of single zones, and 3) constant, fan-driven natural ventilation.
Additional Thermal Mass - The capability to add additional thermal mass to zones has been added. This is useful for factoring in the mass of indoor furniture or heavy interior objects such as chimneys.
New Utility Components - Abraham has added a couple of useful components to help calculate lighting loads based on bulb types and target lighting levels as well as a converter from ACH to the m3/s-m2 that the other HB components accept. Along this vein, there is also a component for adding in the resistance of Air Films to HB constructions.
Improved and Editable Ideal Air Loads System - The EnergyPlus Ideal Air System now goes through an automatic sizing period at the start of the simulation based on the extreme weeks of the weather file. Furthermore, the ability to adjust many of the parameters of the ideal air loads system have been added with a new “Set Ideal Air Loads Parameters” component. The component allows you to add in heat recovery, air side economizers and demand-controlled ventilation.
OpenStudio Export Update - The OpenStudio workflow is still largely under development but this release includes a version with a working VAV and PTHP system template for those curious with experimenting. Note that not all of the new features available for the basic “Run Energy Simulation” component are available for the OpenStudio component (such as air walls, natural ventilation, or additional thermal mass).
Microclimate/Indoor Comfort Maps - Blossoming from initial experiments with the radiant temperature map, a workflow for looking into sub-zone microclimate and indoor comfort has been initiated. All components for this are presently under the Honeybee WIP tab but, over the next month, they will be completing their development phase and moving into the rest of the tabs. If you are interested in testing when they are ready, please let Chris know. For a teaser video of the intended capabilities, see this video: (https://www.youtube.com/watch?v=fNylb42FPIc&list=UUc6HWbF4UtdKdjbZ2tvwiCQ)
LADYBUG
Monthly Bar Chart - After much demand from multiple parties, a new component to create monthly bar and line charts has been added. The component is particularly useful for plotting the outputs of the “Average Data” component like monthly EPW data or averaged monthly-per hour data. It also supports daily data and any type of Energy simulation results.
Wind Profile - To go along with the new capabilities of natural ventilation in Honeybee, Ladybug now has a fully fleshed-out Wind Profile component that allows you to visualize how wind speed changes with height in relation to your building geometry. The component is geared to understanding the conditions of prevailing wind and will be useful in the future for setting up CFD models. Credit goes to Djordje Spasic for adding in all of the new capabilities. In a similar vein, the appearance of the wind rose has also been improved thanks to suggestions from Alejandra Menchaca.
Faster Solar Adjusted Temperature - Thanks to the SolarCal method from the Center for the Built Environment at UC Berkeley (http://escholarship.org/uc/item/89m1h2dg), the solar adjusted temperature component now includes an option for a much faster calculation that produces results that are very close to those originally obtained with the genCumSky component. Instead of using the cumulative sky, the component can now accept the direct and diffuse radiation from the ImportEPW component. Over a whole year, this essentially takes a calculation that used to be a half-hour and shrinks it down to 10 seconds. Thanks again to those at UC Berkeley for keeping their work open source!
Instructions - Last but not the least, [It took me almost two years to understand this but finally] we have a text file that describes the installation step by step and is way easier to modify than a video. You can find it in the zip file. Credit goes to Chris!
We also want to welcome Anton, Patrick and Sandeep to the team. Anton has kicked off his development by working on a component to import and visualize epw ground temperature data and he will be continuing to develop components to bring in reliable precipitation data to Ladybug. With this basis, he will continue to implement Honeybee components for ground heat storage, earth tubes, rain collection and hot water systems. Patrick and Sandeep are working on integration of Honeybee to Energy Performance Calculator.
As always let us know your comments and suggestions.
Enjoy!…
but rather than keep everyone waiting, I've decided to share some as they become ready.
This also has the advantage that questions about components can be more easily grouped under the relevant post - so please do add any questions / comments / bugs / suggestions about these examples below.
So today I am posting some examples of the mesh utilities that come with the new release.
While these are not directly physics based, many of the forces and types of relaxation in Kangaroo are designed to work with meshes, and in the process of development I've ended up adding a number of simple utilities to make working with them a little easier.
I recommend also installing Weaverbird which has many more subdivision functions and other useful tools for working with meshes in Grasshopper. Also Plankton, Turtle, MeshEdit and Starling extend these possibilities still further.
Diagonalize
This component replaces every edge of a mesh with a new face. The new faces will always be quads, except for along the boundaries, where they will be triangles. It can be used to easily create diagrids. The input mesh can contain any mix of triangles and quads.
When treating the edges of a quad mesh as springs, diagonalizing it will often significantly change its physical behaviour. If you are trying to planarize a quad mesh, diagonalizing may sometimes allow you to stay closer to a target shape if it matches the curvature directions better.
diagonalize.gh
Checkerboard
This component assigns the faces of a mesh into a checkerboard pattern. The output is a list of 1s and 0s (which could represent black/white or true/false) which can be used to dispatch the faces into 2 lists, where no pair of adjacent faces have the same colour.
One nice application I found for this is applying alternating clockwise and counter-clockwise rotations as shown below. Also, on occasion you may want to planarize a quad mesh, but have some constraints on the shape and grid that prevent this, and triangulating only alternating quads to give a hybrid quad/tri mesh can sometimes be a good compromise, allowing a bit more freedom.
Note - Not all meshes can be assigned a checkerboard pattern!
As a simple example, take a mesh with 3 quads around one vertex - If we assign one black face, then both the neighbouring faces should be white, but then we have 2 white faces adjacent to one another, which violates the checkerboard condition.
Generally, we can say that if a mesh has any internal vertex with an odd number of faces around it, then we cannot apply a consistent checkerboard pattern to it (although not having any odd valence vertices is not in itself an absolute guarantee that a mesh is 'checkerboardable').
checkerboard.gh
WarpWeft
This sorts the edges of a quad mesh into 2 lists of line segments, which are like the warp and weft directions of a fabric. They can also be seen as a sort of mesh equivalent to the u and v isocurves on a NURBS surface.
This can be useful if you want to control the shape of a tension structure, because it allows you to assign different stiffnesses in the 2 directions.
As with the checkerboard component, not all meshes can be consistently assigned warp/weft directions. It follows a similar rule - all internal vertices should have an even number of adjacent faces. With a bit of care, it is usually possible to model the initial mesh in such a way as to allow this.
This component also has an output telling us whether or not each line is on a boundary of the mesh, as we will often want to treat these differently.
Same mesh relaxed with different warp/weft stiffness:
warpweft.gh
MeshCorners
This one is hopefully fairly self explanatory. In many simulations we want to anchor the corner points of a mesh. This saves us having to pick them manually in Rhino.
It works on quad meshes, and looks around the boundary vertices for any which do not have exactly 3 connected edges.
corners.gh
That's all for now. Coming soon - a "mesh tools 2" post explaining more of the components.…
URBS cup surface, and boy oh boy did it ever work more uniformly than using 3D orb cutters on a 3D cup. Different sized spheres return the *same* hex grid only less and less raised up as the spheres get very large.
My first question is whether these are different in character or just in Z scaling, so if I rescale them all to the same Z thickness, after extracting only the relief structure via Boolean union and splitting...and they are only *slightly* different in character, which means mere Z re-scaling of a single moderate ball size relief is an appropriate cheat to avoid slow Boolean union re-making each relief Z scale with different sized balls.
The one on the right is a very shallow relief scaled up to the same Z thickness as the pure sphere one on the left. And really, we will be mostly scaling *down* from a thicker master surface so that will attenuate any weirdness in the curvature. Indeed, I see no difference, so it makes sense to only archive the thickest one so we can control the full range of thicknesses, all the way to nearly flat bulbs. Here is the thickest one, just before the balls lose holes between them, scaled down compared to a shallow one made with huge balls to start with:
Now we just use Rhino Flow Along Surface or the Grasshopper Jackalope plug-in Sporf to morph this flat system onto our lathe form.
With Rhino history for the Flow Along Surface step I can rescale the original in Z and wait twenty seconds to see the update:
There are sad edge artifacts that will require some strategy to retain or later delete a whole row:
Maybe add more geometry to later delete or make a solid to hold stuff together?
So vastly decreasing the cell count and changing grid direction to match your cup:
The edges came out fine on this one, happily. The isocurve count has been increased by the Flow Along Surface command:
It can't be filleted yet since the joint where the cup NURBS surface has a joint now leaves feathery edges, so I went back and duplicated the border of the flat array, offset and lofted to make a protecting surface:
But that gave crazy artifacts:
I'm just going to use symmetry to fill in the joint with good faces that are not having to be joined as two halves. I had to turn my Rhino units tolerance down from a silly 0.0001 to 0.01 units to get a good re-join, but it still won't fillet without leaving holes.
SO LET'S FILLET THE FLAT THING. Same problem but a bit faster, and actually repairable manually. Rhino 5 is buggy as hell with core commands, damn it. This is not world class behavior.
Let's try it in Rhino 6 WIP, our great hope of the future: nope, the same. I had to simply manually copy the missing pieces from where it did work, which at least is easy to do in flatland. Now I get a cup:
This can *all* be done quickly in Rhino without Grasshopper, and Rhino affords you fast cage editing of the original flat array that Grasshopper cannot yet do. You just need to use Analyze Direction to be able to swap UV directions of the source or target and flip the source surface to achieve concave vs. convex patterns.
Grasshopper doesn't even have a fillet (multiple) edges component so there's not a lot of advantage to having some super slow parametric system via Grasshopper. It's not like you'll be able to see the changes fast enough to tweak a design.…