ed when membrane cones are invited to the party (then mesh (via Starling is the best way) the brep and send data to Kangaroo : the easiest thing to do). But patch doesn't trim the inner Loops and ... well initially I thought to find this in SDK and do the job:
Well... I confess that I can't get the gist of the Brep.Trim (as explained in SDK).
Thus go to plan B: having already the closed breps (the "cones") as cutters ... attempt a Boolean difference
but this does that (this looks to me a bit paranoid, but some reason must exist):
What I want is this:
the code that mess things is (open the script inside definition attached):
BTW: where in SDK is that DeBrep thing?
BTW: Delaunay GH syntax is still cryptic to me (but this is not an issue anymore)
I would greatly appreciate any help on that final step (to greatness).
The full working definition soon (v5: with 90% of components replaced by C# stuff).
best, Peter
…
bout angle since the exact same wires can suddenly start working fine later! Just adding new items to Rhino and then using undo to get back to your failing geometry will fix it sometimes?! Flipping the pair of curves' directions, either one or both, fixes it. It's just black box broken. It happens for really boring angles near 90 degrees.
Rotating the entire pair in space has no effect.
Rescaling the lines from their joint point has no effect.
Simply cutting and pasting the lines out of Rhino back in *sometimes* fixes it, so it's angle and something else that makes certain lines "toxic."
Duplicating the pair of failed lines via alt-dragging the Rhino gumball fails to fix it.
Running the "line-like curves" through a Line component to give "lines" doesn't fix it.
Re-creating the lines by extracting endpoints fails to fix it.
Each line, if separated from each other works fine.
Grafting makes each line into its own little cylinder minus a hub.
The error is the boilerplate "Object reference not set to an instance of an object."
Once the pair spontaneously starts working I cannot reproduce the error with that pair again, though sometimes Rhino undo will get me back to failing.
CAN ANYBODY REPRODUCE THIS WITH MY FILE? If so I can submit a bug report.
Exoskeleton is here: http://www.grasshopper3d.com/group/exoskeleton
Source code is here but it's for compiling, not something I can just test in a C# component out of the box:
https://github.com/davestasiuk/Exoskeleton2/commit/f63c4aa691a7f26b...
…
s is like flattening your data PARTIALLY - chopping an index off the end of the branch paths without obliterating the tree entirely. When working with one "set" of input data, a flatten works to get these lists to match up - but when working with multiple sets, we need to be careful to preserve the original branch indices that keep all four of your original regions separate. As a rule, whenever you're feeding two data trees into any component, they should have the same number of branches. (or one should have branches and the other should be a flat list, in other cases).
The rule of thumb I tend to teach is this:
In 90% of cases...
For lists, all your inputs should either have 1 item or N items. That is to say, if you're feeding 4 items into one input and 9 items into another, something is probably wrong.
For trees, all your inputs should have either 1 branch or M branches. That is to say, if you're feeding a tree w/ branches {0;0} to {0;3} into one input, and a tree w branches {0;0;0} to {0;3;8} into the other input, something is probably wrong.
Grasshopper essentially matches up branches first, then lists second. By "matching" I mean it processes them together. Simple example of the Line component - it will match the first branch of points in the A input to the first branch of points in the B input, creating lines between those points, then match the second branches, the third branches, etc. THEN, it applies the same logic to the level of the list (with a pair of matched branches {0;2}, match all the items in those branches to each other - first item in one branch to the first item in the other branch, etc.)
This is a tricky concept but it seems like you're already well on your way to understanding it from your definition - "PShift" is a critical tool in your path management arsenal. I hope this (overly long) response helps clear things up for you!
…
he TOF and TSRF indices. They show, how "distant" is your _PV_SWHsurface from the optimal _PV_SWHsurface surface in terms of tilt and azimuth angles.However, in your case we are not interested in TOF and TSRF indices. We would just like to know what are the _PV_SWHsurface optimal tilt and azimuth angles, regardless of the supplied _PV_SWHsurface.
So the circular surface supplied to the "TOF" component's _PV_SWHsurface input is irrelevant. It can be of any area, and any tilt/azimuth angle.The PV_SWHsurfacesArea output of the "PV SWH system size" component depends on a couple of factors:moduleActiveAreaPercent_ (leave it at 90%).
moduleEfficiency_,
systemSize_.Calculation of systemSize_ depends on your electricity demand, cost of the PV system, type of the object, country, local regulations etc. This is something that an engineer needs to determine.For example, in USA for a residential house in the Sunbelt, depending on finances, a household would try to cover 100% of its annual electricity needs with their PV system. Which means that the systemSize_ you chose needs to cover the annual electricity consumption. You can perform EnergyPlus simulation or use any other way to get the annual electricity consumption.
Ladybug "Photovoltaics Performance" component can calculate the optimal systemSize_ by given the annual electricity consumption.However the component is made to address fixed tilt and azimuth PV systems only.An approximate way to overcome this is to calculate the optimal systemSize_ for fixed tilt and azimuth PV system, and then multiply it with the "difference in %s" panel at the very right of the fixed_vs_tracker_PV2.gh file. Again, this is not what Ladybug "Photovoltaics Performance" component is made to do, but it will probably get you in a ball park.
Inputted 32 degrees for north_ direction is actually 328 degrees.This is due to Ladybug Photovoltaics being based on NREL model which uses clockwise angles convention. This convention is also most commonly used in solar radiation analysis.
Dubai weather data files are uploaded in here.
…
s, each made from two Nurbs curves, each with different surface properties.
Curves A1 and A2 have 2 control points:
startpoint and endpoint
Curves B1 and B2 on the other hand were drawn with 6 control points each.
What's more, those point's aren't equally distanced from one another.
The lofts inherit the position of control points of the profile curves.
The distribution of control points in the loft direction is uniform.
So no suprise here:
You can think of Nurbs curves as rubber bands and of Nurbs surfaces as rubber sheets. The areas with less control points would correspond to streched rubber.
Now lets imagine you take an A4 piece of rubber, lay in on a table and draw equally distanced lines on it. When you strech it ununiformally - the distances won't stay equal anymore.
Returning to your first post:
The Divide Surface component operates on u,v values which you can imagine as dimensions of the rubber sheet in relaxed state.
So the result you got was indeed an equaly divided surface, only in the so called "parameter space" of the surface, which doesn't always correspond to the xyz space.
There are methods to divide curves and surfaces in equal distances in the way you want it. For starters check out the Evaluate Lenght component.
I think that's enough teory for today. Have fun!
JJ…
e BIOS as i noticed that i was required to do so. This is the progress i made. Now the file "do something". It takes about 4 minutes in the blockMesh component, so something is happening. But at the end of the 4 minutes i get the same error as before. Tried to run the start_OF.bat externally, but no use either.
Those are the snapshots of both of them:
Be patient ... and bear with me. Sorry for bothering with this ... and thanks,
-A.
P.S. There is a chance it is related to the firewall of my university, or some other security issue for those trying to apply virtual machines/hosting.
I'll try at home in the evening.
A more detailed image of the shell running the batch file manually:
…
ce condition I believe, which yes usually this is 0. Bare in mind that OF divides pressure by density, so if you want the 'real' pressure you would need to multiply the results by 1.205 (perhaps we add this in BF at some point but it's easy in native GH).
Vector based velocity is a very good idea, and a nice and easy way to model these kind of flows!
If you wish to experiment even further with the custom boundary condition components you can try implementing a flowRateInletVelocity boundary condition (see https://github.com/OpenFOAM/OpenFOAM-3.0.x/blob/master/src/finiteVolume/fields/fvPatchFields/derived/flowRateInletVelocity/flowRateInletVelocityFvPatchVectorField.H)
It will allow you set the flows in m3/s, which is handy for usual HVAC specs. The direction of the patch follows the normal of the surface. Setting a minus in the volumetric flow rate assigns an opposite direction.
Thanks for using and sharing! Keep them coming!
Kind regards,
Theodore.
P.S.: Try this as an expirement. Increase the refinement of your mesh, factor of 4 should be nice. You can simply reduce the the blockMesh cell size by 4 to accomplish that. Try running the case and see the impact on the residual graph.
…
ters thesis on exactly stratification in atria and big semi-outdoor rooms.I am testing a bunch of variables and I was thus looking into utilizing Butterfly. However, this new update came too late in the process for me to fully test out.
I am very interested in your findings, as I had to go to the old fashion (and correct but yet very slow) way of using Ansys Fluent for my investigations.
I would however very much like to compare my results with the ways of the parametric tools, i.e. Butterfly: How valid are the results of BF so far? What could be optimized? When is the parametric tool favourable over the hardcore tools when considering these factors? What are the future objectives?
Could I therefore borrow your script later on at some point to use for my own to generate some analyses?Or would it maybe be possible for you to (in a month or so?) to create a very basic template script that is prepared for temperature analyses in an very simple atrium-like room maybe with an inlet and outlet as you are (or seem to be) making them? I am willing to go with NDA or give full credit to you and your work.
Very interesting what you are doing!!
Regards
Lasse Hamborg…
you working on a PV system which will power a domestic hot water boiler?
To answer your questions:1) Each grasshopper component (ghpython being one of those too) is using grasshopper's data matching algorithm. This algorithm takes care of complex issues which may arise from combining lists with single items, data trees with different number of items per branch and so on.I think there is a way of introducing a call to other processor's threads per each inputted surface, but this will be a very difficult job, as it will require writing a custom data matching algorithm. I do not think I am up to that task.Instead I tried to introduce the multithread only to the final part of the PVsurface component and one of its time consuming parts: calculation of sun angles, solar radiation and ac/dc power output.I attached the test file below, but sadly it didn't go well: the multithreaded version mostly runs at the same time as the regular version.I do not think I am qualified enough to answer why is that so, but I think that it may have something to do with the type of the function that the multithreading is applied to: the code is suppose to run few separate functions a couple of thousand times, and work with a couple of lists. From my experience, the multithreading works the best when a single list or two are supplied to a single function. I may be wrong on this.I am very sorry to say that I can not implement this feature.2) I am not familiar if open source PV modules database has been released.But one can always download the data for specific modules from producers websites. It can then easily be transferred to a .csv file or other text file.Ladybug Photovoltaics are based on NREL's PVWatts model.In comparison with other commercial software applications, PVWatts offers a more generalized system model, with some of the values and characteristics being assumed or embedded.The Fuentes empirical thermal model we are currently using follows the same logic: it generalizes the Module characteristics. The following characteristics are only editable: module efficiency, temperature coefficient and module mount type.It may be possible to replace Fuentes with some other, less generalized 5 parameter thermal model. But as an architect, I would definitively need help on this.
Sorry if my reply did not fulfill your expectations, and thank you for the kind words!…