he "return" is comment out as shown below?
After restarting Rhino and Grasshopper, I opened the outdoors_airflow demo file, and the first step of creating the case file is ok:
Then the blockMesh component gives the following error: seems I have to manually start OF first..
so, as the error message suggested, I open OF by Start_OF.bat:
Then come back to the blockMesh component, now it can be executed while the OF command line window is also openning:
... and the blockMesh finished successfully:
... so I proceeded to run snappyHexMesh, checkMesh and update fvScheme:
... up to the simpleFoam component, I got the error again:
The warning message is:
1. Solution exception: --> OpenFOAM command Failed!#0 Foam::error::printStack(Foam::Ostream&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #1 Foam::sigFpe::sigHandler(int) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #2 ? in "/lib64/libc.so.6" #3 double Foam::sumProd<double>(Foam::UList<double> const&, Foam::UList<double> const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #4 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #5 Foam::GAMGSolver::solveCoarsestLevel(Foam::Field<double>&, Foam::Field<double> const&) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #6 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #7 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #8 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so" #9 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #10 Foam::fvMatrix<double>::solve() in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #11 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #12 __libc_start_main in "/lib64/libc.so.6" #13 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam"
... and the command lines in the readMe! output are pretty long and it is saved in the text file attached here.
So, my questions are:
1. why I have to manually start OF first before I can use the blockMesh component? Should butterfly automatically start OF?
2. what might be the cause of the unsuccessful run of simpleFoam in the end?
Hope you can kindly advise! Thank you!
- Ji
…
a modélisation paramétrique avec Grasshopper pour Rhinoceros3D ainsi que démontrer plusieurs façons de l’appliquer à votre travail architectural.
Cette formation est conçue comme une expérience augmentée autour de l’architecture paramétrique et elle comprend aussi :
+ Une introduction au design paramétrique par Francesco Cingolani+ Une étude de cas d’un projet de l’agence de l’agence HDA Hugh Dutton Associés+ Acces gratuit 3 journées à l’espace de coworking SUPERBELLEVILLE
INSTRUCTEURS
FRANCESCO CINGOLANI . designer, enseignant en architecture paramétrique, co-fondateur deSUPERBELLEVILLE coworking, collaborateur de l’agence Hugh Dutton Associés. – voir le profil Linked-in
ŞULE ERTÜRK . Architecte diplômée de l’Université Yildiz Teknik à Istanbul, Master en architecture paramétrique, travaille actuellement aux Ateliers Jean Nouvel dans le département 3D. - voir le profil Linked-in
QUENTIN GAUCHER . Architecte DE-HMONP, diplômé de l’ENSA Paris La Villette, intervenant en architecture paramétrique sur divers projets - voir le profil Linked-in
DATES 25 mars 2013 . Annonce de la formation / Début des inscriptions5 avril 2013 . Fin des inscriptions13 – 14 avril 2013 . Formation
HORAIRES Samedi et Dimanche 13 et 14 avril . 10:00 > 13:00 – 14:00 > 19:00Total : 16 heures
TARIF700 € professionnels400 € étudiants
RÈGLEMENT50% est à régler lors de l’inscription (au plus tard le 5 avril)50% au début de la formation.Les règlements s’effectuent par carte bancaire via Paypal ou par virement bancaire.
NOMBRE DE PARTICIPANTSMinimum pour l’activation de la formation : 5Maximum : 7
CONTACTInscriptions et réglements : fr.cingolani@gmail.com . SUPERBELLEVILLE coworkingInformations : quentin.gaucher@gmail.comimmaginoteca.com/grasshopper
EN BONUSLe café italien et les plats faits maison de Claudia offerts aux participants :)…
ll-Facade using Rhino and Grasshopper Participants will learn; Rhinoceros Grasshopper Advanced Parametric Design Brick Formations and Explorations Shadow-Design Relationship
Session 2: Advanced Digital Modeling for Additive Manufacturing (3D Printing) Participants will learn; How to prepare a 3D design to 3D Printing process in Rhinoceros Advanced Methods for 3D Print optimisation for time and cost effective production 3D Printing software education Cura
INFO
Date Saturday, 28 September 2019 Schedule 9:30am – 2:30pm (Session 1) | 2:45pm – 7:00pm (Session2) Venue (TBC) Pada Labs, Istanbul Language English/Turkish Softwares Rhinoceros Grasshopper 3D Cura Participants will need to bring their own laptops with software installed; other plugins will be distributed at the workshop. Prerequisites All tutorials are open to beginner level. No previous knowledge of Cura and Grasshopper needed. Basic knowledge of Rhinoceros recommended. Participation The workshop is limited to the first 20 applicants. Each student will receive a certificate of participation. Prices for each session: (You can pick one and attend one) Special Early registration (Deadline 1 August ) Students 310 TL Professionals 400 TL Regular registration Students 390 TL Professionals 480 TL Prices for Session 1&2 Combined: (Full Day) Special Early registration (Deadline 1 August ) Students 540 TL Professionals 690 TL Regular registration Students 620 TL Professionals 790 TL DISCOUNTS Group registration of 3 or more people will get a 15% discount. * Previous Pada workshop students will get a 10% discount. DIRECTOR Begum Aydinoglu, M.Arch AA DRL will be instructing and directing the following workshops. REGISTRATION: Email to pada.workshops@gmail.com for registration instructions. Please note that we have limited seats and there won't be any exceptions. …
value=WINTERDESIGNDAY, in SIZINGPERIOD:DESIGNDAY=SINGAPORE ANN HTG 99.6% CONDNS DB ************* IDF Context for following error/warning message: ************* Note -- lines truncated at 300 characters, if necessary... ************* 53 SizingPeriod:DesignDay, ************* indicated Name=SINGAPORE Ann Htg 99% Condns DB ************* Only last 10 lines before error line shown..... ************* 57 23.5, !- Humidity Indicating Conditions at Maximum Dry-Bulb ************* 58 101133., !- Barometric Pressure {Pa} ************* 59 2, !- Wind Speed {m/s} design conditions vs. traditional 6.71 m/s (15 mph) ************* 60 320, !- Wind Direction {Degrees; N=0, S=180} ************* 61 0.00, !- Clearness {0.0 to 1.1} ************* 62 0, !- Rain {0-no,1-yes} ************* 63 0, !- Snow on ground {0-no,1-yes} ************* 64 21, !- Day of Month ************* 65 12, !- Month ************* 66 WinterDesignDay,!- Day Type
The relevant lines in the IDF file is shown below:
SizingPeriod:DesignDay, SINGAPORE Ann Htg 99.6% Condns DB, !- Name 23, !- Maximum Dry-Bulb Temperature {C} 0.0, !- Daily Temp Range {C} 23, !- Humidity Indicating Conditions at Maximum Dry-Bulb 101133., !- Barometric Pressure {Pa} 2, !- Wind Speed {m/s} design conditions vs. traditional 6.71 m/s (15 mph) 320, !- Wind Direction {Degrees; N=0, S=180} 0.00, !- Clearness {0.0 to 1.1} 0, !- Rain {0-no,1-yes} 0, !- Snow on ground {0-no,1-yes} 21, !- Day of Month 12, !- Month WinterDesignDay,!- Day Type 0, !- Daylight Savings Time Indicator WetBulb; !- Humidity Indicating Type ! SINGAPORE_SGP Annual Heating 99%, MaxDB=23.5°C SizingPeriod:DesignDay, SINGAPORE Ann Htg 99% Condns DB, !- Name 23.5, !- Maximum Dry-Bulb Temperature {C} 0.0, !- Daily Temp Range {C} 23.5, !- Humidity Indicating Conditions at Maximum Dry-Bulb 101133., !- Barometric Pressure {Pa} 2, !- Wind Speed {m/s} design conditions vs. traditional 6.71 m/s (15 mph) 320, !- Wind Direction {Degrees; N=0, S=180} 0.00, !- Clearness {0.0 to 1.1} 0, !- Rain {0-no,1-yes} 0, !- Snow on ground {0-no,1-yes} 21, !- Day of Month 12, !- Month WinterDesignDay,!- Day Type 0, !- Daylight Savings Time Indicator WetBulb; !- Humidity Indicating Type
It seems that there is an empty line after the line for "!- Humidity Indicating Type" field, and nothing is specified for "! SINGAPORE_SGP Annual Heating 99%, MaxDB=23.5°C" field.
May I ask why this happens and how to correct the error?
Thank you very much!…
nd improvements. Many of the new features and components announced in the last release have become stable and have emerged from their WIP section. Additionally, after two years of work, we are happy to announce that we finally have full support of an OpenStudio connection within Honeybee, which has ushered in a whole host of new features, notably the modelling of detailed HVAC systems. As always you can download the new release from Food4Rhino. Make sure to remove the older version of Ladybug and Honeybee and update your scripts.
LADYBUG
1 - Solar Hot Water Components Out of WIP
After much beta-testing, bug-fixing, and general development, all of the Photovoltaic and Solar Hot Water components are now fully out of WIP! The main component is based on a Chengchu Yan's publication. Components have been added to Ladybug thanks to the efforts of Chengchu Yan and Djordje Spasic.. See Djorje’s original release post of the solar hot water components for more information on the components that just made it out of WIP.
2 - New Terrain Shading Mask Released in WIP
In addition to Djordje’s prolific addition of renewable energy components, he has also contributed a widely-useful component to generate terrain shading masks, which account for the shading of surrounding mountains/terrain in simulations. While initially added to assist the solar radiation radiation and renewable energy components, the component will undergo development to optimize it for energy and daylight simulations over the next few months. Another new component called Horizon Angles can be used to visualize and export horizon angles. You can test them out now by accessing them in the WIP section. For more information, see Djordje’s release post on the GH forum here.
3 - New Mesh Selector Component
After realizing that the Optimal Shade Creator component has applications to a whole range of analyses, it has now been re-branded as the Mesh Selector and has been optimized to work easily with these many analyses. Specifically, the component selects out the portion of a mesh that meets a given threshold. This can be the portion of a shade benefit analysis meeting a certain level of shade desirability, the portion of a radiation study meeting a certain level of fulx, the portion of a daylight analysis meeting a certain lux threshold, and much more!
4 - Solar Adjusted Temperature Now Includes Long Wave Radiation
Thanks to a question asked by Aymeric and a number of clarifications made by Djordje Spasic, the Solar Adjusted Temperature component now includes the ability to account for long-wave radiative loss to the sky in addition to it original capability to account for short wave radiation from the sun. As such, the component now includes all capabilities of similar outdoor comfort tools such as RayMan. The addition of this capability is also paralleled by the addition of a new horizontalInfraredRadiation output on the ImportEPW component. See the updated solar adjusted example file hereto see how to use the component properly.
5 - Support for both Log and Power Law Wind Profiles
In preparation for the future release of the Butterfly CFD-modelling insect, the Ladybug Wind Profile component now includes the option of either power law or log law wind profiles, which are both used extensively in CFD studies. Thanks goes to Theodoros Galanos for providing the formulas!
6 - New Radiant Asymmetry Comfort Components
Prompted by a suggestion from Christian Kongsgaard, Ladybug now includes components to calculate radiant asymmetry discomfort! For examples of how to use the components see this example file for spatial analysis of radiant asymmetry discomfort and this example for temporal analysis.
7 - Pedestrian Wind Comfort Component Released in WIP
In preparation for the impending release of the butterfly CFD-modelling insect, Djordje Spasic with assistance from Liam Harrington has contributed a component to evaluate outdoor discomfort and pedestrian safety. The component identifies if certain areas around the building are suitable for sitting, building entrances-exits, window shopping... based on its wind microclimate. Dangerous areas due to high wind speeds are also identified.You can check it out now in the WIP section.
HONEYBEE
1 - New HVAC Systems and Full OpenStudio Support
After a significant amount of development on the part of the OpenStudio team and two years of effort on the part of LB+HB developers, we (finally!) have full support for an OpenStudio connection within Honeybee. By this, we mean that any energy simulation property that can be assigned to a HBZone will be taken into account in the simulation run by the OpenStudio component. The connection to OpenStudio has brought with it several new capabilities. Most notably, you can now assign full HVAC systems and receive energy results in units of electricity and fuel instead of simple heating and cooling loads. This Honeybee release includes 14 built-in HVAC template systems that can be assigned to the zones, each of which can be customized:
0. Ideal Air Loads 1. PTAC | Residential 2. PTHP | Residential 3. Packaged Single Zone - AC 4. Packaged Single Zone - HP 5. Packaged VAV w/ Reheat 6. Packaged VAV w/ PFP Boxes 7. VAV w/ Reheat 8. VAV w/ PFP Boxes 9. Warm Air Furnace - Gas Fired 10.Warm Air Furnace - Electric 11.Fan Coil Units + DOAS 12.Active Chilled Beams + DOAS 13.Radiant Floors + DOAS 14.VRF + DOAS
Systems 1-10 are ASHRAE Baseline systems that represent much of what has been added to building stock over the last few decades while systems 11-14 are systems that are commonly being installed today to reduce energy use. Here is an example file showing how to assign these systems in Honeybee and interpret the results and here is an example showing how to customize the HVAC system specifications to a wide variety of cases. To run the file, you will need to have OpenStudio installed and you can download and install OpenStudio from here.
In addition to these template systems within Honeybee, the OpenStudio interface includes hundreds of HVAC components to build your own custom HVAC systems. OpenStudio also has a growing number of user-contributed HVAC system templates that have been integrated into a set of scripts called "Measures" that you can apply to your OpenStudio model within the OpenStudio interface. You can find these system templates by searching for them in the building components library. Here is a good tutorial video on how to apply measures to your model within the OpenStudio interface. Honeybee includes a component that runs these measures from Grasshopper (without having to use the OpenStudio interface), which you can see a demo video of here. However, this component is currently in WIP as OpenStudio team is still tweaking the file structure of measures and it is fairly safe to estimate that, by the next stable release of Honeybee, we will have full support of OpenStudio measures within GH.
2 - Phasing Out IDF Exporter
With the connection to OpenStudio now fully established, this release marks the start of a transition away from exporting directly to EnergyPlus and the beginning of Honeybee development that capitalizes on OpenStudio’s development. As such THIS WILL BE THE LAST STABLE RELEASE THAT INCLUDES THE HONEYBEE_RUN ENERGY SIMULATION COMPONENT.
The Export to OpenStudio component currently does everything that the Run Energy Simulation component does and, as such, it is intended that all GH definitions using the Run Energy Simulation component should replace it with the OpenStudio component. You can use the same Read EP Result components to import the results from the OpenStudio component and you can also use the same Energy Sim Par/Generate EP Output components to customize the parameters of the simulation. The only effective difference between the two components is that the OpenStudio component enables the modeling of HVAC and exports the HBZones to an .osm file before converting it to an EnergyPlus .idf.
For the sake of complete clarity, we should state that OpenStudio is simply an interface for EnergyPlus and, as such, the same calculation engine is under the hood of both the Export to OpenStudio component and the Run Energy Simulation component. At present, you should get matching energy simulation results between the Run Energy Simulation component and a run of the same zones with the OpenStudio component (using an ideal air system HVAC).
All of this is to say that you should convert your GH definitions that use the Run Energy Simulation component to have the OpenStudio component and this release is the best time to do it (while the two components are supported equally). Additionally, with this version of Honeybee you will no longer need to install EnergyPlus before using Honeybee and you will only need to install OpenStudio (which includes EnergyPlus in the install).
3 - New Schedule Generation Components
Thanks to the efforts of Antonello Di Nunzio, we now have 2 new components that ease the creation of schedule-generation in Honeybee. The new components make use of the native Grasshopper “Gener Pool” component to give a set of sliders for each hour of the day. Additionally, Antonello has included an annual schedule component that contains a dictionary of all holidays of every nearly every nation (phew!). Finally, this annual schedule component can output schedules in the text format recognized by EnergyPlus, which allows them to be written directly into the IDF instead of a separate CSV file. This will significantly reduce the size of files needed to run simulations and can even reduce the number of components on your canvas that are needed to add custom schedules. For more information, see Antonello’s explanatory images here and Antonello's example file here. You can also see a full example file of how to apply the schedules to energy simulations here.
4 - EnergyPlus Lookup Folder, Re-run OSM/IDF, and Read Result Dictionary
With the new capabilities of OpenStudio, we have also added a number of components to assist with managing all of the files that you get from the simulation. In particular, Abraham Yezioro has added a Lookup EnergyPlus Folder component that functions very similarly to the Lookup Daylight Folder component. This way, you can run an Energy simulation once and explore the results separately. Furthermore, we have added components to Re-Run OpenStudio .osm files or EnergyPlus .idf files within Grasshopper. These components are particularly useful if you edit these .osm or .idf files outside of Honeybee and want to re-run them to analyze their results in Grasshopper. Lastly, a component has been added to parse the .rdd (or Result Data Dictionary) file that EnergyPlus produces, enabling you to see all of the possible outputs that you can request from a given simulation.
5 - Electric Lighting Components Out of WIP
After Sarith Subramaniam’s initial components to model electric lights with Radiance in the last release, we are happy to report that they have been fully tested and are out of WIP. Improvements include support for all types of light fixture geometries and the ability to use the components in a more “Grasshoppery” list-like fashion. See Sarith’s original release post for more information and several example files showing how to use the components can be found here. 1 , 2 , 3 .
6 - Improvements to THERM Components
A number of bug fixes and improvements have been made to the THERM components in order to make their application more flexible and smooth. Special thanks is due to Derin Yilmaz , Mel King , Farnaz , Ben (@benmo1) , and Abraham Yezioro for all of the great feedback in the process of improving these components.
7 - HBObject Transform Components
After some demand for components that can ease the generation of buildings with modular zone types, two components to transform HBObjects with all of their properties have been added to the 00 | Honeybee section. The components allow you to produce copies of zones that are translated or rotated from the original position.
8 - Comfort Maps Supports PET and Integration of CFD Results
Thanks to the addition of the ‘Physiological Equivalent Temperature’ (PET) component by Djordje Spasic in the last stable release, it is now possible to make comfort maps of PET with Honeybee. PET is particularly helpful for evaluating OUTDOOR comfort with detailed wind fields at a high spatial resolution. As such, the new PET recipe has also been optimized for integration with CFD results. The windSpeed_ input can now accept the file path to a .csv file that is organized with 8760 values in each column and a number of columns that correspond to the number of test points. Components to generate this csv from Butterfly CFD results will be coming in later releases. Stay tuned!
As always let us know your comments and suggestions.
Enjoy!Ladybug Analysis Tools Development Team
…
t file** - ply file with just x,y,z locations. I got it from a 3d scanner. Here is how first few lines of file looks like - ply format ascii 1.0 comment VCGLIB generated element vertex 6183 property float x property float y property float z end_header -32.3271 -43.9859 11.5124 -32.0631 -43.983 11.4945 12.9266 -44.4913 28.2031 13.1701 -44.4918 28.2568 13.4138 -44.4892 28.2531 13.6581 -44.4834 28.1941 13.9012 -44.4851 28.2684 ... ... ... In case you need the data - please email me on **nisha.m234@gmail.com**. **Algorithm:** I am trying to find principal curvatures for extracting the ridges and valleys. The steps I am following is: 1. Take a point x 2. Find its k nearest neighbors. I used k from 3 to 20. 3. average the k nearest neighbors => gives (_x, _y, _z) 4. compute covariance matrix 5. Now I take eigen values and eigen vectors of this covariance matrix 6. I get u, v and n here from eigen vectors. u is a vector corresponding to largest eigen value v corresponding to 2nd largest n is 3rd smallest vector corresponding to smallest eigen value 7. Then for transforming the point(x,y,z) I compute matrix T T = [ui ] [u ] [x - _x] [vi ] = [v ] x [y - _y] [ni ] [n ] [z - _z] 8. for each i of the k nearest neighbors:<br> [ n1 ] [u1*u1 u1*v1 v1*v1] [ a ]<br> [ n2 ] = [u2*u2 u2*v2 v2*v2] [ b ] <br> [... ] [ ... ... ... ] [ c ] <br> [ nk ] [uk*uk uk*vk vk*vk]<br> Solve this for a, b and c with least squares 9. this equations will give me a,b,c 10. now I compute eigen values of matrix [a b b a ] 11. This will give me 2 eigen values. one is Kmin and another Kmax. **My Problem:** The output is no where close to finding the correct Ridges and Valleys. I am totally Stuck and frustrated. I am not sure where exactly I am getting it wrong. I think the normal's are not computed correctly. But I am not sure. I am very new to graphics programming and so this maths, normals, shaders go way above my head. Any help will be appreciated. **PLEASE PLEASE HELP!!** **Resources:** I am using Visual Studio 2010 + Eigen Library + ANN Library. **Other Options used** I tried using MeshLab. I used ball pivoting triangles remeshing in MeshLab and then applied the polkadot3d shader. If correctly identifies the ridges and valleys. But I am not able to code it. **My Function:** //the function outputs to ply file void getEigen() { int nPts; // actual number of data points ANNpointArray dataPts; // data points ANNpoint queryPt; // query point ANNidxArray nnIdx;// near neighbor indices ANNdistArray dists; // near neighbor distances ANNkd_tree* kdTree; // search structure //for k = 25 and esp = 2, seems to got few ridges queryPt = annAllocPt(dim); // allocate query point dataPts = annAllocPts(maxPts, dim); // allocate data points nnIdx = new ANNidx[k]; // allocate near neigh indices dists = new ANNdist[k]; // allocate near neighbor dists nPts = 0; // read data points ifstream dataStream; dataStream.open(inputFile, ios::in);// open data file dataIn = &dataStream; ifstream queryStream; queryStream.open("input/query.
pts", ios::in);// open data file queryIn = &queryStream; while (nPts < maxPts && readPt(*dataIn, dataPts[nPts])) nPts++; kdTree = new ANNkd_tree( // build search structure dataPts, // the data points nPts, // number of points dim); // dimension of space while (readPt(*queryIn, queryPt)) // read query points { kdTree->annkSearch( // search queryPt, // query point k, // number of near neighbors nnIdx, // nearest neighbors (returned) dists, // distance (returned) eps); // error bound double x = queryPt[0]; double y = queryPt[1]; double z = queryPt[2]; double _x = 0.0; double _y = 0.0; double _z = 0.0; #pragma region Compute covariance matrix for (int i = 0; i < k; i++) { _x += dataPts[nnIdx[i]][0]; _y += dataPts[nnIdx[i]][1]; _z += dataPts[nnIdx[i]][2]; } _x = _x/k; _y = _y/k; _z = _z/k; double A[3][3] = {0,0,0,0,0,0,0,0,0}; for (int i = 0; i < k; i++) { double X = dataPts[nnIdx[i]][0]; double Y = dataPts[nnIdx[i]][1]; double Z = dataPts[nnIdx[i]][2]; A[0][0] += (X-_x) * (X-_x); A[0][1] += (X-_x) * (Y-_y); A[0][2] += (X-_x) * (Z-_z); A[1][0] += (Y-_y) * (X-_x); A[1][1] += (Y-_y) * (Y-_y); A[1][2] += (Y-_y) * (Z-_z); A[2][0] += (Z-_z) * (X-_x); A[2][1] += (Z-_z) * (Y-_y); A[2][2] += (Z-_z) * (Z-_z); } MatrixXd C(3,3); C <<A[0][0]/k, A[0][1]/k, A[0][2]/k, A[1][0]/k, A[1][1]/k, A[1][2]/k, A[2][0]/k, A[2][1]/k, A[2][2]/k; #pragma endregion EigenSolver<MatrixXd> es(C); MatrixXd Eval = es.eigenvalues().real().asDiagonal(); MatrixXd Evec = es.eigenvectors().real(); MatrixXd u,v,n; double a = Eval.row(0).col(0).value(); double b = Eval.row(1).col(1).value(); double c = Eval.row(2).col(2).value(); #pragma region SET U V N if(a>b && a>c) { u = Evec.row(0); if(b>c) { v = Eval.row(1); n = Eval.row(2);} else { v = Eval.row(2); n = Eval.row(1);} } else if(b>a && b>c) { u = Evec.row(1); if(a>c) { v = Eval.row(0); n = Eval.row(2);} else { v = Eval.row(2); n = Eval.row(0);} } else { u = Eval.row(2); if(a>b) { v = Eval.row(0); n = Eval.row(1);} else { v = Eval.row(1); n = Eval.row(0);} } #pragma endregion MatrixXd O(3,3); O <<u, v, n; MatrixXd UV(k,3); VectorXd N(k,1); for( int i=0; i<k; i++) { double x = dataPts[nnIdx[i]][0];; double y = dataPts[nnIdx[i]][1];; double z = dataPts[nnIdx[i]][2];; MatrixXd X(3,1); X << x-_x, y-_y, z-_z; MatrixXd T = O * X; double ui = T.row(0).col(0).value(); double vi = T.row(1).col(0).value(); double ni = T.row(2).col(0).value(); UV.row(i) << ui * ui, ui * vi, vi * vi; N.row(i) << ni; } Vector3d S = UV.colPivHouseholderQr().solve(N); MatrixXd II(2,2); II << S.row(0).value(), S.row(1).value(), S.row(1).value(), S.row(2).value(); EigenSolver<MatrixXd> es2(II); MatrixXd Eval2 = es2.eigenvalues().real().asDiagonal(); MatrixXd Evec2 = es2.eigenvectors().real(); double kmin, kmax; if(Eval2.row(0).col(0).value() < Eval2.row(1).col(1).value()) { kmin = Eval2.row(0).col(0).value(); kmax = Eval2.row(1).col(1).value(); } else { kmax = Eval2.row(0).col(0).value(); kmin = Eval2.row(1).col(1).value(); } double thresh = 0.0020078; if (kmin < thresh && kmax > thresh ) cout << x << " " << y << " " << z << " " << 255 << " " << 0 << " " << 0 << endl; else cout << x << " " << y << " " << z << " " << 255 << " " << 255 << " " << 255 << endl; } delete [] nnIdx; delete [] dists; delete kdTree; annClose(); } Thanks, NISHA…
t defined from the discussion of radiation exchange between urban surfaces and the sky in urban heat island research (See Oke's literature list below). It will be affected by the proportion of sky visible from a given calculation point on a surface (vertical or horizontal) as a result of the obstruction of urban geometry, but it is not entirely associated with the solid angle subtended by the visible sky patch/patches.
So, I think using "geometry way" to approximate Sky View Factor is not correct. Sky View Factor calculation shall be based on the first principle defining the concept: radiation exchange between urban surface and sky hemisphere:
(image extracted from Johnson, G. T., & Watson, 1984)
Therefore, I always refer to the following "theoretical" Sky View Factors calculated at the centre of an infinitely long street canyon with different Height-to-width ratios in Oke's original paper (1981) as the ultimate benchmark to validate different methods to calculate SVF:
So, I agree with Compagnon (2004) on the method he used to calculate SVF: a simple radiation (or illuminance) simulation using a uniform sky.
The following images are the results of the workflow I built in the procedural modeling software Houdini (using its python library) according to this principle by calling Radiance to do the simulation and calculation, and the SVF values calculated for different canyon H/W ratios (shown at the bottom of each image) are very close to the values shown in Oke's paper.
H/W=0.25, SVF=0.895
H/W=1, SVF=0.447
H/W=2, SVF=0.246
It seems that the Sky View Factor calculated from the viewAnalysis component in Ladybug is not aligned with Oke's result for a given H/W ration: (GH file attached)
According to the definition shown in this component, I assume the value calculated is the percentage of visible sky which is a geometric calculation (shooting evenly distributed rays from sensor point to the sky and calculate the ratio of rays not blocked by urban geometry?), i.e solid angle subtended by visible sky patches, and it is not aligned with the original radiation exchange definition of Sky View Factor.
I'd suggest to call this geometrically calculated ratio of visible sky "Sky Exposure Factor" which is "true" to its definition and way of calculation (see the paper on Sky Exposure Factor below) so as to avoid confusion with "The Sky View Factor based on radiation exchange" as discussed in urban climate literature.
Appreciate your comments and advice!
References:
SVF: definition based on first principle
Oke, T. R. (1981). Canyon geometry and the nocturnal urban heat island: comparison of scale model and field observations. Journal of Climatology, 1(3), 237-254.
Oke, T. R. (1987). Boundary layer climates (2nd ed.). London ; New York: Methuen.
Johnson, G. T., & Watson, I. D. (1984). The Determination of View-Factors in Urban Canyons. Journal of American Meteorological Society, 23, 329-335.
Watson, I. D., & Johnson, G. T. (1987). Graphical estimation of sky view-factors in urban environments. INTERNATIONAL JOURNAL OF CLIMATOLOGY, 7(2), 193-197. doi: 10.1002/joc.3370070210
Papers on SVF calculation:
Brown, M. J., Grimmond, S., & Ratti, C. (2001). Comparison of Methodologies for Computing Sky View Factor in Urban Environments. Los Alamos, New Mexico, USA: Los Alamos National Laboratory.
SVF calculation based on first principle:
Compagnon, R. (2004). Solar and daylight availability in the urban fabric. Energy and Buildings, 36(4), 321-328.
paper on Sky Exposure Factor:
Zhang, J., Heng, C. K., Malone-Lee, L. C., Hii, D. J. C., Janssen, P., Leung, K. S., & Tan, B. K. (2012). Evaluating environmental implications of density: A comparative case study on the relationship between density, urban block typology and sky exposure. Automation in Construction, 22, 90-101. doi: 10.1016/j.autcon.2011.06.011
…
curve or locus] of a segment AB, in English. The set of all the points from which a segment, AB, is seen under a fixed given angle.
When you construct l'arc capable —by using compass— you obviously need to find the centre of this arc. This can be easily done in GH in many ways by using some trigonometry (e.g. see previous —great— solutions). Whole circles instead of arcs provide supplementary isoptics —β-isoptic and (180º-β)-isoptic—. Coherent normals let you work in any plane.
Or you could just construct β-isoptics of AB by using tangent at A (or B). I mean [Arc SED] component.
If you want the true β-isoptic —the set of all the points— you should use {+β, -β} degrees (2 sides; 2 solutions; 2 arcs), but slider in [-180, +180] degrees provides full range of signed solutions. Orthoptic is provided by ±90º. Notice that ±180º isoptic is just AB segment itself, and 0º isoptic should be the segment outside AB —(-∞, A] U [B, +∞)—. [Radians] component is avoidable.
More compact versions can be achieved by using [F3] component. You can choose among different expressions the one you like the most as long as performs counter clockwise rotation of vector AB, by 180-β degrees, around A; or equivalent. [Panel] is totally avoidable.
Solutions in XY plane —projection; z = 0—, no matter A or B, are easy too. Just be sure about the curve you want to find the intersection with —Curve; your wall— being contained in XY plane.
A few self-explanatory examples showing features.
1 & 5 1st ver. (Supplementary isoptics) (ArcCapableTrigNormals_def_Bel.png)
2 & 6 2nd ver. (SED) (ArcCapableSED_def_Bel.png)
3 & 7 3rd ver. (SED + F3) (ArcCapableSEDF3_def_Bel.png)
4 & 8 4th ver. (SED + F3, Projection) (ArcCapableSEDProjInt_def_Bel.png)
If you want to be compact, 7 could be your best choice. If you prefer orientation robustness, 5. Etcetera.
I hope these versions will help you to compact/visualize; let me know any feedback.
Calculate where 2 points [A & B] meet at a specific angle is just find the geometrical locus called arco capaz in Spanish, arc capable in French (l'isoptique d'un segment de droite) or isoptic [curve or locus]
of a segment AB, in English. The set of all the points from which a segment,
AB, is seen under a fixed given angle.…
as one element.
Thank you
Comment by karamba on October 7, 2014 at 11:27pm
Hello Patricio, divide the beams in such a way that each boundary vertex of the shell becomes an endpoint of a beam segment.
Best, Clemens
Comment by Llordella Patricio on October 8, 2014 at 8:30amDelete Comment
Hi Clemens,
I did what you suggested but now assemble element doesn´t work properly. Could you please tell me how to fix it? Thanks in advance, Patricio
8-10-14losa%20cadena.gh
Comment by karamba on October 8, 2014 at 11:59am
Hi Patricio, if you flatten the 'Elem'-input at the 'Assemble'-component the definition works. The triangular shell elements have linear displacement interpolations whereas the beam deflections are exact. In order to get correct results you should refine the shell mesh.
Best, Clemens
Comment by Llordella Patricio on October 9, 2014 at 8:35amDelete Comment
Hello, succeeds in creating the mesh to the slab, and built the beam segment, but when I see the deformations are not expected because the beam is deformed as the slab.
Thanks for the help
PS: maybe I'm using the program for a type of structure that is not the most appropriate, as I saw in the examples of other structures. But this type of structure is that students taught
best regards
Patricio
9-10-14%20Example%201.gh
Comment by karamba on October 9, 2014 at 10:46am
You could use the 'Mesh Edges'-component to retrieve the naked edges and turn them into beams - see attached file:91014Example1_cp.gh
Best regards,
Clemens
Comment by Llordella Patricio on October 15, 2014 at 3:41pmDelete Comment
Dear clemens
I was doing a rough estimate of the deformation, and I can not achieve the same result with Karamba. When I make a rough estimate of the result with Karamba beams and mine are very similar, I think the problem is when I connect the shell, because there are no similar results.
I sent the GH file, and an image of the calculation
The structure is concrete The result I get is 0.58cm
thank youPatricio
15-10-14%20Example.gh
Comment by karamba yesterday
Dear Patricio,
try to increase the number of shell elements. As mentioned in the manual they are linear elements. A mesh that is too coarse leads to a response which is stiffer than the real structure.
Best,
Clemens
…