nal vector.(see pic 1)
Second: Holding an abstract mesh or surface with a 3D grid structure. Basically creating 90 degree vectors on an uneven surface coming out of the object, sort of like a cactus with a grid pattern. (see Pic 2)
Third: I think #1 answers this issue: when the lines hitting the rough surface go in two different grid directions, their intersecting points are too close together. Structurally these points can be united and the vectors would be reduced. Manually deleting these lines after being baked is currently the only option. It would be so cool if there was a mathematical arrangement that would connect points that are within a certain distance to one another. (see pic 3)
…
. since there are going to be multiple units facing different directions, each unit will be calculated differently based of their respective plane.
The following screenshots can explain the situation a little better
So Lets say the vector is pointing from the operating unit to the position of the sun, an the plane underneath is where I would like to measure the angle from
this second picture shows how each unit should function, so the measured angle doesn't exceed 90 degrees. what I did is zeroed the z value for the sun position to get a project vector. The problem with this solution is that it only works for XY planes, where I need to have a lot of planes that are specific for each unit and its orientation.
Help would be much appreciated…
problem is that the values of the isocurves are plotted not always in the same way: sometime parallel to the curves, sometime perpendicular.
In the following case, for example, i would like to turn the values of 90°(to get them parallel to the curves).
in order to have something like this:
How can i do that (without baking them)??
Thanks in advance
Claudia…
izes like 0.6m, 0.8m, 0.9m and 1.2m are the most "common": In cases where mechanical floors are a must (hospitals for instance) a 2.4/2.4 is quite handy (habitable/mechanical per floor). You can try 1.8/2.7 as well (floor/habitable) since 1.8 floor thickness can host HVAC and some decent W truss size. Also 1.6/2.4 (floor/habitable) is used in small buildings. NOTE: see next.
3. Don't forget to include corrugated metal height + concrete screed height + raised floors height: for the latter, say, something like 0.3m (modules + adjustable mounts + free space for electric stuff [boxes etc]).
4. As regards exteriors, Laurent Buzon is a close friend of mine. Contact him directly on my behalf:
http://www.buzonuk.com/
http://www.google.gr/url?sa=t&rct=j&q=&esrc=s&sourc...
5. LBS Structural ability and "monolithic" floor behavior (humans don't like vibrating habitable spaces) ARE not the same animal.…
ybee_EnergyPlus Window Shade Generator" component.
3. SolveAdj component has the input to set BC for interior surfaces.
If you want to set them to adiabatic then you can use setToAdiabatic components.
4. For natural ventilation Chris has provided extensive answers including this one.
If the component doesn't work then you need to download the files manually from github and replace the userObjects with the old ones. You have to do it separately for Ladybug and Honeybee which can be painful. Is there anyway to change the firewall settings?
…
i have to rely completely in passive means.
To speed things i'm calculating comfort for Extreme hot/cold week, thinking maybe on typical weeks instead.
The cool week is kind of "right", but the hot (extreme) is giving all night hours 100% comfort. Knowing the climate, there is no way this can be the case. Some of the settings with the european standards give sometimes the right tendency, but still, compared to ASHRAE's the average of % percentage is too high.
Also my assumptions for flexibility of use/clothing/etc is the maximal. I mean, no constrains on this respect ("let's be passive as much as we can").
So right now i have no specific questions, but rather your advice, if any: "What you would do ...?? (I don't like these kind of questions, sorry).
A request, yes, if it is possible to output the set temperature for each hour. For instance, when you give the degFromTargetMtx i'll like to know this target. This is for control, and i think this is important for better understanding this black box.
Any other insights you may have, just shoot.
Not related to the discussion, but if you happened to check the model, we are simulating 2 apartments in the building. The northern one is only one thermal zone. The southern is divided in rooms. I wanted to see how much difference e get between both ways. And there is. No doubt the more detailed modeling looks more reliable. Also if you have some points here, shoot again.
BTW humidity, look at page 32-33 in the AC book. Nicol is clear on the "real" influence of the humidity, arguing it is mostly psychological than real.
Thanks again, and to you too Mauricio.
-A.…
till quite rough.
I went through your attached log but it seems to be a successful run, perhaps the error log wasn't attached. In any case, I believe we have identified this issue. The goal of the update fvSchemes component was to apply schemes to finalized meshes in an automatic way. While this is useful for new users it is also a dangerous thing to do in CFD studies.
The component works by relating mesh quality to the mesh non-orthogonality, which the checkMesh component reports. While non-orthogonality is one of the important criteria of mesh quality it does present difficulties on some kind of meshes, especially like the simple cases that BF has been meshing so far.
The example case of simple box buildings in a wind tunnel above for instance will appear as a good quality case for even the lowest of cell-count meshes, simply because it is an orthogonal geometry. That means that checkMesh will probably report low values (imagine an empty blockMesh of 10m blocks has a non-orthogonality of 0) which in turn means that higher order schemes might be paired with actually low quality meshes. This I believe is causing problems.
I posted a possible solution to this here https://github.com/mostaphaRoudsari/Butterfly/issues/57. The idea is that Buttefly provides additional options to the users, enabling them to choose between first-order (faster, more robust, but lower quality schemes) and second-order (slower, less robust, but more accurate) schemes depending on mesh quality, stage of assessment, etc. In cases like the above mesh quality a first-order scheme might provide a better option. To test this I am attaching an fvSchemes file you can use by replacing yours in the /system folder of the case.
As a note however, I would like to stress there is so much that a tool like Butterfly can provide in this area. Meshing is a quite complicated and demanding part of the process, involving a lot of trial and error. Sometimes the problem is just the mesh and not the solution options (GIGO stands true in CFD as well). It does however get easier with experience. The safe advice is the simplest one: when changing solution options doesn't help, refine mesh and run again.
Kind regards,
Theodore.…
rasshopper (only compatible with IRC5 controllers). I made some tests with kinect and phones and tablets and it works (so if you have a good position for your kinect you can already know when a user is too close to the robot and stop the execution or slow it), but due to controller limitations I am now working on a different way of sending and managing data to the robot to minimise the latency of the system.
Galapagos will not allow you to switch between configurations and toolpaths, since configurations are computed by the IK solver and managed by several informations in the code, that can only be overrided or changed depending on the interpolation you use (MoveJ/MoveL/MoveAbsJ etc.). And once again, some configurations are not reachable depending on the rotation domains of certain joints (4th one for example) or also because linear interpolations cannot work for targets necessiting more than 90° of rotation. HAL computes by default the most "accessible" configurations in order to minimize 4th axis flip (which is a pain), and the next update will have a fix to allow to count the laps you do with the joints allowing more than 360° of rotation in order to prevent to reach the max values (otherwise the robot is locked and the application is stopped), there is a little bug on the 6th axis on the current version. IMHO these questions are much more important to solve for the design of your application than the approximaton of the workspace (it is very easy to measure the max radius of rotation, and singularities can always been reached using moveAbsJ).
By the way, all those things are not exactly trivial to solve (some are with the new verson of HAL, but not all of them), so depending on how far you need to go, I hope you don't have a deadline soon...…
eople use different methods and components was the way that I learnt most of what I know (and it might solve parts of other's problems)! It's always apparent from forum posts that everything is work in progress.
The "divide curve" components gives you tangents (T) to the curve at the points you've made. You want the perpendicular (right angle) to the curve, so need to rotate this vector around point on the curve (P) by 90 degrees or Pi/2 Radians .
It seems you're finding your lengths as required, but then passing them through a unit Y vector - so they are only ever going to move in the Y direction. You need to use an "Amplitude" component with the perpendicular vectors from above and the lengths you've calculated.
Before sweeping you'll need to properly align the rectangles such that they are also perpendicular to the curve.
…
Added by Joe Allberry at 10:33am on August 4, 2015