Giter Site home page Giter Site logo

sandialabs / cactus Goto Github PK

View Code? Open in Web Editor NEW
18.0 14.0 12.0 13.42 MB

CACTUS (Code for Axial and Cross-flow TUrbine Simulation) is a turbine performance simulation code, based on a free wake vortex method, to study wind turbines and marine hydrokinetic (MHK) devices.

License: BSD 3-Clause "New" or "Revised" License

MATLAB 1.14% Python 11.56% Fortran 83.44% GLSL 3.03% CMake 0.84%
scr-1551

cactus's Introduction

CACTUS (Code for Axial and Cross-flow TUrbine Simulation)

CACTUS (Code for Axial and Cross-flow TUrbine Simulations), developed at Sandia National Laboratories, is a turbine simulation code based on a free wake vortex method.

Compiling

CACTUS can be compiled via CMake. For details, see doc/compile.md

Tests

Simple regression tests are included. After compiling, navigate to test/RegTest/ and run:

PATH=$PATH:../../bin pytest runreg.py

Directory Structure

  • bin: Default target for compiled executables
  • DAKOTA: DAKOTA drivers (by Jon Murray) and examples
  • doc: Documentation -- user's manual, install instructions, DAKOTA drivers manual, relevant publications
  • make: Makefiles for various compilers and platforms
  • src: Source code
  • test: Test cases (regression tests, example HAWT/VAWT input files, airfoil files)

Post-processing

Tools for post-processing data from CACTUS simulations are available in the CACTUS-tools repository.

References

For details about the development of CACTUS, please see

  • Murray, J., and Barone, M., “The Development of CACTUS, a Wind and Marine Turbine Performance Simulation Code,” 49th AIAA Aerospace Sciences Meeting including the New Horizons Forum and Aerospace Exposition, Reston, Virginia: American Institute of Aeronautics and Astronautics, 2011, pp. 1–21.

Disclaimer

A CACTUS model V&V studies (Michelen et al. 2014, Wosnik et al. 2016) for cross-flow hydrokinetic turbines demonstrated it accurately predicts performance characteristics for axial-flow turbines, but it should not be used for cross-flow geometries.

  • Michelen, C., V.S. Neary, J. Murray, and M. Barone, M. (2014). CACTUS open-source code for hydrokinetic turbine design and analysis: Model performance evaluation and public dissemination as open-source tool. Proceedings of 2nd Marine Energy Technology Symposium 2014 (METS2014), at the 7th Annual Global Marine Renewable Energy Conference (GMREC 2014), Seattle, WA, April 15-18.

  • Wosnik M., Bachant P., Neary V.S., and A.W. Murphy (2016). Evaluation of Design & Analysis Code, CACTUS, for Predicting Cross-flow Hydrokinetic Turbine Performance. SAND2016-9787, September 2016. 34 pages.

cactus's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cactus's Issues

Open-source this repo

We (@whophil @kmruehl @wosnik @nearyvs @awilmurph) were discussing this a bit via email. If export control regulations will allow, it would be helpful to make this repo public. Some advantages include:

  • Can use free continuous integration (CI) tools for testing, e.g., Travis CI (#2) and AppVeyor (#3)
  • Users can file bug reports and feature requests here
  • Users that aren't necessarily involved with the project can submit pull requests to improve the code

Can't use WPFLag and GPFlag together?

I get an error when I have both the WPFlag and GPFlag set to 1. It says "Attempting to allocate already allocated variable 'walls'". If I turn off GPFlag, it runs. This may be true if using FSFlag too, but I haven't tried. Can someone else confirm that this is the case? If so, is the idea, perhaps, that, if using a wall file, you would include your own ground plane in the wall file rather than use GPFLag?

Makefile fails if GIT_VERSION cannot be identified

Issue by whophil
Thursday Jun 16, 2016 at 21:10 GMT
Originally opened as https://github.com/whophil/CACTUS-SNL/issues/34


Make command fails if GIT_VERSION cannot be identified.

GIT_VERSION is used, e.g., here, and in other locations.

This may happen if:

  1. The machine doesn't have git
  2. The repository is downloaded without the .git directory
  3. git describe fails for some other reason

The fix is to add some sort of error catching to the git describe line. e.g., "if git describe fails, GIT_VERSION='unknown' "

Blade Reynolds number was above table limit

I've gotten this warning at the end of simulations a few times: AT LEAST ONE BLADE REYNOLDS NUMBER WAS ABOVE TABLE LIMIT. UPPER LIMIT USED. I'm surprised to see it, though. In deciding what Reynolds numbers to use to calculate polars, I calculated all possible Reynolds numbers using the chord distribution and tip speed ratio to get the relative velocities, and then the freestream velocity to get the resultant at each span location. The highest Reynolds number that I used for my polars is about twice the highest Reynolds number I calculated. Could you verify how the Reynolds number is being determined in the simulation and, perhaps, explain how it could be so much higher than my estimates?

Can Field Data be irregularly spaced?

What would it take to have an irregular grid for the FieldData output? Given the "atmospheric conditions" of the simulations, the gradient from wake to ambient can be very sharp, especially in the near wake. It would be useful to have higher resolution within the wake and lower resolution outside so as not to increase the computational time too much.

Clarification about yawing and `RotN`

Is there a way to yaw the turbine or set the inflow angle relative to the rotor plane? Can this be set with the geometry variable RotN, which sets the axis of rotation? I don't see a way to set RotN or anything related to yaw angle in the Matlab files provided to create geometry. I think there's more than one way to create geometry with the Matlab files, so, to be clear, I'm using create_hawt.m and editing hawt_params.m as needed for my geometry.

Issues with the Geometry File

Hi Everyone, I am new to coding and doing my best to learn it. I am having issues understanding the Cactus geometry file. I want to simulate a straight-bladed rotor with three blades (Like RM2 tow-tank Experiment Sandia Lab). I don´t know how to calculate the blade unit tangent vectors for my simple geometry to modify the cactus geometry file.
I would appreciate it if you can provide any document to understand this geometry file. So far I have the Cactus and the Cactus development Manual Only.
Thank you.
@whophil

Blade pitch from geometry is halved in ElementData

Hi all! I am working on a new VAWT concept (X-Rotor) to characterise its aerodynamic behaviour. In the two cases I am simulating, I am comparing data between zero-pitch and 20-degree pitched blades (attached JPG images).

However, after running the simulations, if I isolate the angle of attack data from the simulations, I see that the pitch offset is only half of the requested 20 degrees (attached plot). This results in wrong values of power and thrust for the pitched case. But it outputs accurate results for the no-pitch case.

I have tried to see if the data is being halved while calculating the forces from the polars, but it doesn’t seem to be the case, else the no-pitch case results would be bad.

Any input would be great!

xrotor_pitch_0
xrotor_pitch_20
AngleOfAttack

Using wall files

I am trying to create and use a wall file to represent the turbine tower and nacelle in a simulation. I have created a mesh in Pointwise and exported it in plot3d format, but it's come to my attention that CACTUS is not using the "standard" plot3d format.

From the Wikipedia entry on plot3d files:
A multiblock, 3 dimensional grid file begins with a single integer for the number of blocks M on its own line. The next M lines contain three integers for each of the blocks, which give the i, j, and k dimension sizes for each block. The M blocks are read in next. Each block contains a coordinate value iterated over i, j, k, and then the three coordinates, x, y, and z.

From the plot3d.f95 source file:
subroutine read_p3d_multiblock(xyz_filename,nblocks,ni,nj,nk,x,y,z)
! read_p3d_multiblock() : Read a formatted (ASCII) Plot3D multi-block mesh file.
! Coordinates must be specified one number per line.

Also, I'm less sure of this, but apparently different programs may export plot3d files in different formats. The mesh that I created in Pointwise did open correctly in Paraview, so it's right in some sense. As is, it seems like CACTUS wants one coordinate per line and I have four per line, but it's not totally clear to me how to convert between formats. Has anyone run into this and figured it out?

Tower and nacelle/hub implementation

Tower:
I have the tower "turned on" with the following parameters:
itower = 1
tower_x = 0
tower_ybot = 0
tower_ytop = 2.3704
tower_D = 0.1481
tower_CD = 0.87
When I look at outputs, though, I actually see a speed up in the flow where the tower should be. I've attached two images of results averaging the last 10 timesteps of 41 revolutions with 20 timesteps per revolution. The first is the centerline vertical-streamwise plane and the second is the ground level horizontal-streamwise plane. They're both the average streamwise velocity (not normalized or just induced).
1
2

Nacelle/hub:
This may or may not be related, but, because there is no nacelle/hub, I get a speed up in the middle of the wake that persists for about 5 radii downstream. I'm concerned that this could affect the wake decay. Could there be a way to implement an effective blockage in the middle similar to the tower? I'm going to try to essentially extend the circular section of the blade shaft all the way to the axis to see how that affects the results, but that is also potentially not realistic.

Request: restart from pause or interruption

Perhaps there's a way to do this already, but it would be nice if there were a way to restart a simulation from where it left off if it got interrupted or if the user needed to pause it.

Effect of tower tilting

I work with a floating vertical axis wind turbine. There, I need to quantify the effects of tower tilting on turbine performance.
I think there exists two ways for this purpose. 1. changing the geometry 2. changing inflow angle.
However, I am still uncertain how to do this in CACTUS?

FieldData being output with non-standard file names and unknown file type

I don't know what I could have done, but now my simulations are outputting the field data with file names like V27NOS~1, V27NOS~2, etc. Those are the first six characters of my job title, so it's not random, but not the typical <input file name>_FieldData_<timestep>.csv. After it got to V27NOS~5, it switched to TI31000~, TI31001~,...TI31004~, then KBBD0KP~ and other seemingly random names. I have no explanation for the latter two. They still work in that I can open them and process them in Matlab, so I guess it's not a problem, but it's odd if not concerning.

Is my rotor going forwards AND backwards?

This has never happened before. How is this possible?
It looks like, approximately, every rev starting around rev 15 has one timestep that reads as rev 33. Around rev 32 or 33, it gets more mixed up with an additional rev reading out for some timesteps. It's set to start saving data at rev 35. It's saving over old data from a run that failed, but that's never been an issue before.
image

Error compiling in MSys2

Hi guys,

Compiling the code in Windows 10, using the updated MSys2, mingw-64 (build as of feb15 2021). After updating all packages to the current editions, I'm getting an error in the last step "Linking Fortran executable." This seems to be due to an issue with the -static libraries for use with windows.

Error:

[100%] Linking Fortran executable ../bin/cactus
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0\libgfortran.a(read.o):(.text$_gfortrani_convert_real+0xb7): relocation truncated to fit: IMAGE_REL_AMD64_REL32 against undefined symbol strtoflt128' C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0\libgfortran.a(read.o):(.text$_gfortrani_convert_infnan+0xb3): relocation truncated to fit: IMAGE_REL_AMD64_REL32 against undefined symbol strtoflt128'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/cactus.dir/build.make:1050: ../bin/cactus] Error 1
make[1]: *** [CMakeFiles/Makefile2:95: CMakeFiles/cactus.dir/all] Error 2
make: *** [Makefile:103: all] Error 2

Anyone else experiencing this issue? I'm not sure if this is innate to the MSys2 system or some easier work around.

I can successfully compile when the -static link is removed, but I can't run the program as it is missing essential .dlls.

Thanks for your time!

Bruce

Compilation possible on macOS with ARM64 architecture?

I tried to compile using the conda-forge compilers toolchain, but it didn't work.
What I tried was:

conda create -y --name cactus
conda activate cactus
conda install -c conda-forge compilers cmake
mkdir -p build
cd build
cmake ..
make

When I run cmake, I got the following output:

cmake ..
-- The Fortran compiler identification is GNU 11.3.0
-- Checking whether Fortran compiler has -isysroot
-- Checking whether Fortran compiler has -isysroot - yes
-- Checking whether Fortran compiler supports OSX deployment target flag
-- Checking whether Fortran compiler supports OSX deployment target flag - yes
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Check for working Fortran compiler: /Users/yhlee/conda/envs/cactus/bin/arm64-apple-darwin20.0.0-gfortran - skipped
-- The C compiler identification is Clang 14.0.6
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Users/yhlee/conda/envs/cactus/bin/arm64-apple-darwin20.0.0-clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Looking for Fortran sgemm
-- Looking for Fortran sgemm - not found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE  
-- Looking for Fortran dgemm
-- Looking for Fortran dgemm - found
-- Found BLAS: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Accelerate.framework  
-- Looking for Fortran cheev
-- Looking for Fortran cheev - found
-- Found LAPACK: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Accelerate.framework;-lm;-ldl  
-- Found OpenMP_C: -fopenmp=libomp (found version "5.0") 
-- Found OpenMP_Fortran: -fopenmp (found version "4.5") 
-- Found OpenMP: TRUE (found version "5.0")  
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/yhlee/Documents/CACTUS/build

However, when I try to make, I get following error message:

make          
[  1%] Building Fortran object CMakeFiles/cactus.dir/src/mod/airfoil.f90.o
arm64-apple-darwin20.0.0-gfortran: fatal error: no input files
compilation terminated.
/bin/sh: -O2: command not found
make[2]: *** [CMakeFiles/cactus.dir/src/mod/airfoil.f90.o] Error 127
make[1]: *** [CMakeFiles/cactus.dir/all] Error 2
make: *** [all] Error 2

When I checked the folder CMakeFiles/cactus.dir/src/mod/, there was no "airfoil.f90.o" file created there.
However, I was able to still find the input file (../src/mod/airfoil.f90), and I also checked the content of the source code.

How can I resolve this problem? Thank you.

Convergence problems in non-linear iteration loop

I got this error while running. Can you help me figure out what needs to be addressed to fix it?
Norm. Time, Theta (rad), Revolution, Torque Coeff., Power Coeff.
0.19640E+02 0.15834E+03 26. 0.59640E-01 0.48082E+00
Timestep: 506
0***** NON-LINEAR ITERATION LOOP DID NOT CONVERGE IN 10 ITERATIONS. PROGRAM TERMINATED. *****
Note: The following floating-point exceptions are signalling: IEEE_DIVIDE_BY_ZERO IEEE_UNDERFLOW_FLAG IEEE_DENORMAL

CACTUS GUST SIMULATION

Hi everyone,

I was wondering how do one correctly model the gust simulation correctly in CACTUS? I have played around with the igust, gustamp, gusttime, gustX0 parameters but I get no difference in the result. Would be grateful for some tips and suggestions!

Best Wishes,
Sadman Sakib
The University of Texas at Dallas

Not compiling with Intel Fortran

Dear CACTUS-Community,

I cloned the repo and followed the compilation instructions. Unfortunately, I receive the following error when executing make:

image

Has someone suggestions on how to fix the problem? What additional information do you require to help me? I am a Mac user with intel compilers installed.

Thank you very much in advance

Nils

Clarification on output files

The User Guide says that, when FieldOutFlag is on, it outputs induced velocity on a 3D Cartesian grid. I'm getting an essentially 2D output as all of the x-coordinates are zero at all times. Is that what it really should be or is this an issue? If an issue, whos?

Additionally, WakeElemData can be output, which appears to be nominally the same except that it is not output on a Cartesian grid. Will implementing the wake grid options (nxgrid, nygrid, nzgrid, etc.) force this output onto a Cartesian grid?

Basically, I'm wondering what the easiest way is to get an output of 3D induced velocities on a Cartesian grid.

Unknown error after geometry file is read

My simulation will run, but in the display, after all the geometry data is shown, it repeats four times "The syntax of the command is incorrect." I have no idea to what it is referring or if it's actually causing any issues. It continues right after with generating the wall and then runs to the end without further issues. See below:

        EAreaR:   4.65032e-03   6.22399e-03   5.92880e-03   5.63429e-03   5.33918e-03   5.04379e-03   4.74760e-03   4.45184e-03   4.15498e-03   3.86052e-03   3.56704e-03   3.26992e-03   2.97480e-03   2.67956e-03   2.38349e-03
        iSect:   1   2   3   4   4   4   4   5   5   6   6   7   7   7   8

The syntax of the command is incorrect.
The syntax of the command is incorrect.
The syntax of the command is incorrect.
The syntax of the command is incorrect.
 Generating wall influence matrix...
Time to generate influence matrix =           0.961 seconds.

Errorneous results at very small timescales.

Hello,

I am using CACTUS to simulate VAWT behaviour with secondary tip rotors (HAWT). These tip rotors rotate 50x faster than the primary blades, thus in order to accurately represent the effect of the secondary rotors one must simulate them at a range of phase angles. Attempts to rotate the tip rotors 60deg per time step require 310 time steps per rotation. However, when attempting to run CACTUS at such a large number of time steps (even without secondary tip rotors) leads to torque/power coefficients greater than 1 after 8 revolutions. In these situations, transient behaviour is highly erratic and shows little sign of converging.

I have played around with vortex core radius settings; namely significantly reducing the vortex core radius, however, this does not improve the situation. Timestep filtering does result in coefficients<1, however, the results seem very artificial and non-physical.

I am wondering whether I am encountering some obvious/known limitation of the model, or if anyone else has encountered this issue. Tips are much appreciated

Does not use output path given in .inp file

This is a little thing, but it seems to me that the output files are always placed one level above the folders for the airfoil data and geometry. I haven't done thorough testing, but that's where they always go for me. Would be nice if they actually went in the assigned folder.

Modify Computational Domain

Hi,

I was wondering is it possible to modify the computational domain in CACTUS to match a wind tunnel test section? What we are trying to do is to capture the effect of bounding walls on the rotor power and loads (blockage effect). Any suggestions regarding the issue will be greatly appreciated.

Best
Sadman Sakib

Does shear make velocity a function of height?

Typically, to calculate the "actual" velocity from the output induced velocities in the FieldData, it would be induced velocity*U_inf+Uinf in order to denormalize it and then add the freestream to the induced velocity. When shear is turned on, does the added velocity need to be a function of height to match the shear profile?

Related to the use of shear, is it possible that the use of shear causes the wake to drift upward? I struggle to think about this in terms of a free vortex method, but I'm thinking the shear is perhaps effectively superimposed as I suggest above, which would cause the top of the wake to advect faster than the bottom. In full fidelity, I think this would, in turn, increase the vertical mixing and, perhaps, drive the wake upward. Just spit balling on that. Basic question is how realistic is the use of shear in these simulations?

Fixed preset blade pitch angle

Hello,
I am working on a straight-bladed cross-flow turbine (NACA0015) with a solidity of 0.15. I have the experimental data and am trying to simulate the same in CACTUS. I have the data for different pitch angles and want to simulate the same in the cactus. I am modifying the blade pitch angle by changing the mount point ratio (eta) in the code during geometry creation (the quote). My cactus results are not in agreement at all with the experiment data on all the pitch angles. I could not find a way to give a fixed preset blade pitch angle in the code other than changing the mount point for a VAWT.

"**A forward shift of mount-point from the centre of the chord towards the leading edge corresponds to an effective toe-in pitch

change of β = tan^-1[x/R]**"

where x is the distance between the two shifting points.
Could you please tell me the ways I can provide blade pitch angle in the code for a Straight-bladed VAWT?
image

Failed install in Linux

Hello everyone,

I am compiling in the linux platform. With make command, I got this error:

[100%] Linking Fortran executable ../bin/cactus
/usr/bin/ld: CMakeFiles/cactus.dir/src/WSolnSetup.f95.o: in function wsolnsetup_': WSolnSetup.f95:(.text+0x77a): undefined reference to dgesv_'
/usr/bin/ld: CMakeFiles/cactus.dir/src/mod/wallsystem.f95.o: in function __wallsystem_MOD_invert_influence_matrix': wallsystem.f95:(.text+0x1438): undefined reference to dgesv_'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/cactus.dir/build.make:1029: ../bin/cactus] Error 1
make[1]: *** [CMakeFiles/Makefile2:76: CMakeFiles/cactus.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

Any help would be appreciated.

Best,
Jingna

Explanation of DSData headings

Could please briefly explain the headings in the DSData output file? If I'm not mistaken, this is not covered in the user guide.

compilation with intel compiler on windows

Hello,

I know that the windows tips recommend using MinGW, but I was wondering whether there is any way to compile in windows with Intel Compiler (Intel OneAPI 2021.5.0.20211109).
Cmake seems to run but gives some warnings including:

-- Could NOT find BLAS (missing: BLAS_LIBRARIES)
-- Could NOT find LAPACK (missing: LAPACK_LIBRARIES)
Reason given by package: LAPACK could not be found because dependency BLAS could not be found.

Then, trying to build from Visual Studio fails with the following errors:

Error fatal error LNK1120: 1 unresolved externals
Error error LNK2019: unresolved external symbol DGESV referenced in function WALLSYSTEM_mp_INVERT_INFLUENCE_MATRIX wallsystem.obj
Error error LNK2001: unresolved external symbol DGESV WSolnSetup.obj

to note that there are several warnings related to

Warning command line warning #10006: ignoring unknown option '/mkl' ifort

I then tried to include the MKL during compilation, and even though I get an executable, it does not run as expected. Issuing cactus.exe from the command prompt does not produce any result at all. I doubt the .exe is meaningful at all.
Any help would be much appreciated.

Simulation not moving from "Timestep: 1"

I have a new simulation that is not moving on from printing "Timestep: 1" after it loads the geometry and generates matrices. I didn't note my start time, but I'd say it's been there at least an hour whereas, typically, there's barely a pause there if any delay. It had more blade elements than I had tried before, so I arbitrarily halved them and tried again, but it seems the same so far. I also tried another server in case it was hung up or something, but again no change. What could cause this?

UPDATE:
A colleague advised that I troubleshoot this by removing one polar at a time and rebuild the geometry without it. After removing the polar for the cicular foil at the root, the simulation runs. I have, however, successfully used the exact same polar for a circular foil with other blade geometries, so it's not clear to me why it caused a problem here. Just in case, I added additional Reynolds numbers to the polar file to see if that could have been the issue. Upon trying to run again with the new polar for the circular foil, I got the error Warning: NaN encountered in wall_ind_vel().

So now my general question is what are some recommended or best practices for building the root sections of a blade geometry? There's an additional problem in that tools like XFOIL have difficulty producing polars for thick airfoils that transition from the cicular root to the first "true" airfoil section. Without the cicular airfoil, the geometry I'm working on now begins at r/R of 0.12 because I cannot generate any polars closer in. On the other hand, with the cicular airfoil, its polar is used for the first four of 48 elements (up until the next available polar), which also doesn't seem very accurate. Any suggestions?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.