Coder Social home page Coder Social logo

fourierflows / geophysicalflows.jl Goto Github PK

View Code? Open in Web Editor NEW
148.0 8.0 30.0 8.96 MB

Geophysical fluid dynamics pseudospectral solvers with Julia and FourierFlows.jl.

Home Page: https://fourierflows.github.io/GeophysicalFlowsDocumentation/stable/

License: MIT License

Julia 97.41% TeX 2.59%
qg quasigeostrophy pdes sqg baroclinic geophysical-fluid-dynamics fourierflows navier-stokes julia gpu

geophysicalflows.jl's Introduction

GeophysicalFlows.jl

💨🌏🌊 Geophysical fluid dynamics pseudospectral solvers with Julia and FourierFlows.jl. https://fourierflows.github.io/GeophysicalFlowsDocumentation/stable

Buildkite CPU+GPU build status Build Status for Window stable docs latest docs DOI ColPrac: Contributor's Guide on Collaborative Practices for Community Packages DOI badge

This package leverages the FourierFlows.jl framework to provide modules for solving problems in Geophysical Fluid Dynamics on periodic domains using Fourier-based pseudospectral methods.

Installation

To install, use Julia's built-in package manager (accessed by pressing ] in the Julia REPL command prompt) to add the package and also to instantiate/build all the required dependencies

julia> ]
(v1.6) pkg> add GeophysicalFlows
(v1.6) pkg> instantiate

The most recent version of GeophysicalFlows.jl requires Julia v1.6 (the current long-term-release) or later. We strongly urge you to use this version.

The latest version that is compatible with Julia v1.5 is GeophysicalFlows.jl v0.13.1.

Examples

See examples/ for example scripts. These examples are best viewed by browsing them within the package's documentation.

Some animations created with GeophysicalFlows.jl are online @ youtube.

Modules

  • TwoDNavierStokes: the two-dimensional vorticity equation.
  • SingleLayerQG: the barotropic or equivalent-barotropic quasi-geostrophic equation, which generalizes TwoDNavierStokes to cases with topography, Coriolis parameters of the form f = f₀ + βy, and finite Rossby radius of deformation.
  • MultiLayerQG: a multi-layer quasi-geostrophic model over topography allowing to impose a zonal flow U_n(y) in each layer.
  • SurfaceQG: a surface quasi-geostrophic model.
  • BarotropicQGQL: the quasi-linear barotropic quasi-geostrophic equation.

Scalability

For now, GeophysicalFlows.jl is restricted to run on either a single CPU or single GPU. These restrictions come from FourierFlows.jl. Multi-threading can enhance performance for the Fourier transforms. By default, FourierFlows.jl will use the maximum number of threads available on your machine. You can set the number of threads used by FourierFlows.jl by setting the environment variable, e.g.,

$ export JULIA_NUM_THREADS=4

For more information on multi-threading users are directed to the Julia Documentation.

If your machine has more than one GPU available, then functionality within CUDA.jl package enables the user to choose the GPU device that FourierFlows.jl should use. The user is referred to the CUDA.jl Documentation; in particular, CUDA.devices and CUDA.CuDevice. The user is also referred to the GPU section in the FourierFlows.jl documentation.

Getting help

Interested in GeophysicalFlows.jl or trying to figure out how to use it? Please feel free to ask us questions and get in touch! Check out the examples and open an issue or start a discussion if you have any questions, comments, suggestions, etc.

Citing

If you use GeophysicalFlows.jl in research, teaching, or other activities, we would be grateful if you could mention GeophysicalFlows.jl and cite our paper in JOSS:

Constantinou et al., (2021). GeophysicalFlows.jl: Solvers for geophysical fluid dynamics problems in periodic domains on CPUs & GPUs. Journal of Open Source Software, 6(60), 3053, doi:10.21105/joss.03053.

The bibtex entry for the paper is:

@article{GeophysicalFlowsJOSS,
  doi = {10.21105/joss.03053},
  url = {https://doi.org/10.21105/joss.03053},
  year = {2021},
  publisher = {The Open Journal},
  volume = {6},
  number = {60},
  pages = {3053},
  author = {Navid C. Constantinou and Gregory LeClaire Wagner and Lia Siegelman and Brodie C. Pearson and André Palóczy},
  title = {{GeophysicalFlows.jl: Solvers for geophysical fluid dynamics problems in periodic domains on CPUs \& GPUs}},
  journal = {Journal of Open Source Software}
}

Contributing

If you're interested in contributing to the development of GeophysicalFlows.jl we are excited to get your help, no matter how big or small a contribution you make! It's always great to have new people look at the code with fresh eyes: you will see errors that other developers have missed.

Let us know by open an issue or start a discussion if you'd like to work on a new feature or implement a new module, if you're new to open-source and want to find a cool little project or issue to work on that fits your interests! We're more than happy to help along the way.

For more information, check out our contributors' guide.

geophysicalflows.jl's People

Contributors

apaloczy avatar brodiepearson avatar dkarrasch avatar github-actions[bot] avatar glwagner avatar jbisits avatar juliatagbot avatar liasiegelman avatar maleadt avatar mjclobo avatar navidcy avatar stevengj avatar szy21 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  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

geophysicalflows.jl's Issues

Docs are making repo size huuuge?

I just cloned the repo and it's 500MB... I think the .pngs and .mp4 files in the docs (and potentially others) are making the repo size large.

This reminds me of the issue in Oceananigans.jl, which btw is still ongoing... :( few days ago the Oceananigans.jl repo was ~300MB :(

Tag a new version and remove Manifest.toml?

The latest tagged version seems to have issues on Julia v1.3, which are resolved on master:

GeophysicalFlows.peakedisotropicspectrum(mygrid, 2, 0.5)
MethodError: no method matching abs2(::Array{Complex{Float64},0})
Closest candidates are:
  abs2(!Matched::SymEngine.Basic) at /Users/karrasch/.julia/packages/SymEngine/zSUGO/src/mathfuns.jl:62
  abs2(!Matched::Missing) at missing.jl:100
  abs2(!Matched::Bool) at bool.jl:84
  ...

So, I'd like to kindly request that you tag a new version unless you have some hot stuff that you want to get in first.

Also, I wanted to ask why you put the Manifest.toml in here? IIUC, the way to put compatibility bounds on dependencies is via the compat section in the Project.toml. Maybe, you could remove the Manifest and see what the latest versions of your dependencies are? Also, having a Manifest.toml seems to "restrict" basically all the packages in the dependency tree. I'd suggest to have lower bounds on your direct dependencies, and then leave to Pkg figuring out which subdependencies to use. If I can help with anything, let me know.

Use KernelAbstractions to accelerate `MultilayerQG.streamfunctionfrompv!`

KernelAbstractions.jl can be used to accelerate the function

function streamfunctionfrompv!(ψh, qh, params, grid)
for j=1:grid.nl, i=1:grid.nkr
CUDA.@allowscalar @views ψh[i, j, :] .= params.invS[i, j] * qh[i, j, :]
end

A simple example showing how to use KernelAbstractions is the "Naive Transpose":

https://juliagpu.gitlab.io/KernelAbstractions.jl/examples/naive_transpose/

MultilayerQG fails GPU tests

Initially this was because some GPUArrays.jl bug. But even when that was resolved, test still fail... I haven't gone to the bottom of it yet.

Forcing in TwoDTurb is not correct

This implementation of forcing is only valid either for forcing that is constant in time, or only changes at the beginning of a time-step:

https://github.com/FourierFlows/GeophysicalFlows.jl/blob/master/src/twodturb.jl#L191

This implementation is not valid for forcing functions that change smoothly in time. In that case, calcF! must be called and the forcing added to the nonlinear term N each time that calcN! is called --- not only on 'substeps'.

I'm worried that correcting this will break some tests involving stochastic budgets. @navidcy, can you fix it? Are there similar issues elsewhere?

The trickiness involving substeps occurs for stochastic forcing, in which the forcing needs to be calculated only at the beginning of a whole timestep (and should not change during the substeps).

I propose that we write some code to help users implement stochastic forcing and add this to FourierFlows. I'm not sure exactly what this should look like, but I think it should somehow help the user avoid having to put if t==s.t statements in their forcing function, and also store prevsol automatically.

Load Error with getfieldspecs

I tried to run the barotropic QG example and unfortunately got an error in the first importing step.

Is this a known problem? I'm using julia 1.5.2, in case that helps.

https://fourierflows.github.io/GeophysicalFlowsDocumentation/dev/generated/barotropicqg_betadecay/

julia> import GeophysicalFlows.BarotropicQG
[ Info: Precompiling GeophysicalFlows [44ee3b1c-bc02-53fa-8355-8e347616e15e]
ERROR: LoadError: LoadError: UndefVarError: getfieldspecs not defined
Stacktrace:
 [1] include(::Function, ::Module, ::String) at ./Base.jl:380
 [2] include at ./Base.jl:368 [inlined]
 [3] include(::String) at /home/fpoulin/.julia/packages/GeophysicalFlows/mZXo8/src/GeophysicalFlows.jl:1
 [4] top-level scope at /home/fpoulin/.julia/packages/GeophysicalFlows/mZXo8/src/GeophysicalFlows.jl:13
 [5] include(::Function, ::Module, ::String) at ./Base.jl:380
 [6] include(::Module, ::String) at ./Base.jl:368
 [7] top-level scope at none:2
 [8] eval at ./boot.jl:331 [inlined]
 [9] eval(::Expr) at ./client.jl:467
 [10] top-level scope at ./none:3
in expression starting at /home/fpoulin/.julia/packages/GeophysicalFlows/mZXo8/src/barotropicqg.jl:27
in expression starting at /home/fpoulin/.julia/packages/GeophysicalFlows/mZXo8/src/GeophysicalFlows.jl:13
ERROR: Failed to precompile GeophysicalFlows [44ee3b1c-bc02-53fa-8355-8e347616e15e] to /home/fpoulin/.julia/compiled/v1.5/GeophysicalFlows/xFqhg_lrx0p.ji.
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] compilecache(::Base.PkgId, ::String) at ./loading.jl:1305
 [3] _require(::Base.PkgId) at ./loading.jl:1030
 [4] require(::Base.PkgId) at ./loading.jl:928
 [5] require(::Module, ::Symbol) at ./loading.jl:923

3D Navier-Stokes

We can use the analytical solutions of

Antuono, M. (2020). Tri-periodic fully three-dimensional analytic solutions for the Navier–Stokes equations. Journal of Fluid Mechanics, 890, A23. doi:10.1017/jfm.2020.126

as bench tests for a the 3D Navier-Stokes module.

Systematic error in budgets?

I ran the 2D Navier-Stokes example that computes the energy and enstrophy budgets with higher amplitude excitation and for longer so it became nonlinear. Both residuals for energy and enstrophy budgets seems to have a systematic negative bias, although still the residuals are ~3 orders magnitude smaller that the each of the terms in the budgets.

Here's a plot of the budgets when I let the energy/enstrophy example run for up to μt=2.

budgets

I'm pretty sure that the terms are correct. Perhaps testing that the budgets close when in the nonlinear regime with deterministic forcing is a good idea. There are less ambiguities there...

@BrodiePearson @glwagner

Stratified Flows module

We've discussed this before, but now I've submitted my thesis (yay!), I actually have time to start working on a module for a vertical plane with an imposed mean stratification. There are a couple of options for the implementation of this:

  • Vorticity-streamfunction formulation. Should be relatively simple to implement given its similarity to the existing modules.
  • Primitive variable formulation for velocity (u, w) and buoyancy perturbation θ with a pressure solve through a projection method. I saw you have a 3D box as a potential future development on FourierFlows, so implementing a pressure solver may be useful to lead in to that.

Any thoughts?

Once this is working it should be relatively simple to include multiple scalars and make some cool examples of salt fingering and diffusive convection.

I'll be using the existing modules as a starting point and will let you know how I get on. Any tips for developing these modules are much appreciated!

Not shipping `examples` with Manifest.toml can create some confusion

This is example is broken for me too, although the error I get is different than @francispoulin:

~/Projects/GeophysicalFlows.jl/examples$ julia --project
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.5.2 (2020-09-23)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> include("barotropicqg_betadecay.jl")
ERROR: LoadError: MethodError: no method matching Problem(::CPU; nx=128, Lx=6.283185307179586, β=10.0, μ=0.0, dt=0.05, stepper="FilteredRK4")
Closest candidates are:
  Problem(; nx, Lx, ny, Ly, dt, f0, β, eta, ν, nν, μ, stepper, calcFU, calcFq, stochastic, T, dev) at /Users/gregorywagner/.julia/packages/GeophysicalFlows/i9qG7/src/barotropicqg.jl:34
Stacktrace:
 [1] top-level scope at /Users/gregorywagner/Projects/GeophysicalFlows.jl/examples/barotropicqg_betadecay.jl:45
 [2] include(::String) at ./client.jl:457
 [3] top-level scope at REPL[1]:1
in expression starting at /Users/gregorywagner/Projects/GeophysicalFlows.jl/examples/barotropicqg_betadecay.jl:45

julia> 

Originally posted by @glwagner in #128 (comment)

Drop CuArrays.jl from deps and move to CUDA.jl

CuArrays has Adapt ^1 as its dep while Plots requires Adapt ^2
This creates some trouble. E.g., if you have Plots v1.6 installed and you try

]add GeophysicalFlows

you end up with GeophysicalFlows v0.3.0.

Scalar operations on GPU arrays: a potential source of slowdown

This error message

julia> using GeophysicalFlows
julia> gr  = TwoDGrid(GPU(), 32, 2π)
┌ Warning: Performing scalar operations on GPU arrays: This is very slow, consider disallowing these operations with `allowscalar(false)`
└ @ GPUArrays ~/.julia/packages/GPUArrays/J4c3Q/src/indexing.jl:16

stems from these two lines in domains.jl:
https://github.com/FourierFlows/FourierFlows.jl/blob/0c813d6b35235e5cd91364388111af562e48d992/src/domains.jl#L151, https://github.com/FourierFlows/FourierFlows.jl/blob/0c813d6b35235e5cd91364388111af562e48d992/src/domains.jl#L155

But is there any way to avoid it?
For constructing the grid it doesn't really matter because it's only done once. But many times we use, e.g., fh[1, 1]=0 to make sure that f has zero mean. See:


and in this case this may be slowing down the computations on the GPU significantly.

Chan-type forcing

@glwagner: I'm very tempted to ditch this example. How do you feel about that?

using PyPlot, FourierFlows
import FourierFlows.TwoDTurb
import FourierFlows.TwoDTurb: energy, dissipation, work, drag
n, L = 128, 2π
nu, nnu = 2e-4, 1
mu, nmu = 1e-1, -1
dt, tf = 2e-1, 1000
nt = round(Int, tf/dt)
# Forcing
fi = 0.01
ki = 8
θk = π/4
i₁ = round(Int, abs(ki*cos(θk))) + 1
j₁ = round(Int, abs(ki*sin(θk))) + 1 # j₁ >= 1
j₂ = n + 2 - j₁ # e.g. j₁ = 1 => j₂ = nl+1
amplitude = fi*ki * n^2/4
function calcF!(F, sol, t, s, v, p, g)
F[i₁, j₁] = amplitude
F[i₁, j₂] = amplitude
nothing
end
prob = TwoDTurb.ForcedProblem(nx=n, Lx=L, nu=nu, nnu=nnu, mu=mu, nmu=nmu, dt=dt, calcF=calcF!, stepper="RK4")
function runtest(prob, nt)
TwoDTurb.set_q!(prob, rand(prob.grid.nx, prob.grid.ny))
E = Diagnostic(energy, prob, nsteps=nt)
D = Diagnostic(dissipation, prob, nsteps=nt)
R = Diagnostic(drag, prob, nsteps=nt)
W = Diagnostic(work, prob, nsteps=nt)
diags = [E, D, W, R]
tic()
stepforward!(prob, diags, round(Int, nt))
@printf("step: %04d, t: %.1f, time: %.2f s\n", prob.step, prob.t, toq())
diags
end
function makeplot(prob, diags)
E, D, W, R = diags
TwoDTurb.updatevars!(prob)
close("all")
E, D, I, R = diags
fig, axs = subplots(ncols=3, nrows=1, figsize=(13, 4))
sca(axs[1]); cla()
pcolormesh(prob.grid.X, prob.grid.Y, prob.vars.q)
xlabel(L"x")
ylabel(L"y")
sca(axs[2]); cla()
i₀ = 1
dEdt = (E[(i₀+1):E.count] - E[i₀:E.count-1])/prob.ts.dt
ii = (i₀+1):E.count
# dEdt = W - D - R?
total = W[ii] - D[ii] - R[ii]
residual = dEdt - total
plot(E.time[ii], W[ii], label="work (\$W\$)")
plot(E.time[ii], -D[ii], label="dissipation (\$D\$)")
plot(E.time[ii], -R[ii], label="drag (\$R\$)")
plot(E.time[ii], total, label=L"W-D-R")
plot(E.time[ii], dEdt, "k:", label=L"E_t")
plot(E.time[ii], residual, "c-", label="residual")
ylabel("Energy sources and sinks")
xlabel(L"t")
legend(fontsize=10)
sca(axs[3]); cla()
plot(E.time[ii], E[ii])
xlabel(L"t")
ylabel(L"E")
tight_layout()
show()
residual
end
diags = runtest(prob, nt)
res = makeplot(prob, diags)
@printf "rms residual: %.3e" sqrt(mean(res.^2))

Remove large-scale flow U(t) from BarotropicQG

I'm tempted to remove the large-scale flow from BarotropicQG as it's too specific and makes the code hard to penetrate for first-time users. Perhaps move U(t) functionality in an example or a different module...

Clean up comments regarding work done by stochastic forcing

The code is sprinkled with comments about how one should implement the work done by stochastic forcing in Ito or Stratonovich interpretation. We should remove all those comments, as they read a bit out of context. Instead we should make sure that discussion on forcing in the Docs is clear and include in that discussion an example of work implemented via Ito or via Stratonovich calculus.

Diagnostics slow down modules running on GPU by a lot

there must be something the gives GPU a serious bottleneck in diagnostics.jl in FourierFlows.jl

Where I run this test script I get:

we time-step without diagnostics
step: 0400, t: 1, walltime: 0.87 sec
step: 0800, t: 2, walltime: 1.66 sec
step: 1200, t: 2, walltime: 2.45 sec
step: 1600, t: 3, walltime: 3.24 sec
step: 2000, t: 4, walltime: 4.03 sec

re-initialize and run again with diagnostics
step: 0400, t: 1, walltime: 135.30 sec
step: 0800, t: 2, walltime: 305.39 sec
step: 1200, t: 2, walltime: 459.79 sec
step: 1600, t: 3, walltime: 599.51 sec
step: 2000, t: 4, walltime: 770.04 sec

If, on the other hand, I run on CPU the slowdown I get is just 1-2%.

Separate updatevars! for physical space and Fourier space

Updating variables in physical space requires an inverse Fourier transform, which in turns requires a deepcopy(). Sometimes, though, we only need to update the Fourier transform of variables. Therefore if we split updatevars! into two separate function we might gain on allocation.

Make streamfunctionfrompv! faster by using StaticArrays and KernelAbstractions?

streamfunctionfrompv! in MultilayerQG:

function streamfunctionfrompv!(ψh, qh, params, grid)

might be a rate-limiting step, and may prevent MultilayerQG from being efficient on the GPU.

We might be able to speed this up by storing the invS matrix for each k, l wavenumber as a StaticArray. We can then write a parallel kernel to compute the stream function at each k, l that executes on the GPU or multithreaded on the CPU using KernelAbstractions.

Cannot load v0.3 via Pkg

When I simply try to ]add GeophysicalFlows, I am getting delivered version 0.2.0. Is that a problem on my end, or is it related to registering/tagging etc.? Usually, when a package has a Project.toml, you're not supposed to have a REQUIRE file, but this one has both. I can put my package status in here if that's necessary, but wanted to quickly check if that issue has an "easy fix" without digging into all depencies installed in my Julia.

Examples should come first in docs

The examples in all their glory should be just below "Home" in the docs, I think. Also I think "Forcing" should come after "Modules".

TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

Adding Surface QG dynamics?

Are there plans to include a SurfaceQG model in GeophysicalFlows, to complement the other 2D and QG systems that can be modelled?

I started making an SQG model for GeophysicalFlows and I'd be happy to share/collaborate on it if there is not one already being developed. A very rough example code is here, and the SurfaceQG.jl file is also in that branch. It produces flow fields that look reasonable but I am still working to reproduce the results of a specific paper. I'd be happy to put together a doc of the equation set I'm trying to solve if that would be helpful (it is essentially the Equations of Section 2.1 in this paper).

Add 1.5-layer QG functionality

It's easy to include a finite Rossby deformation radius in BarotropicQG module. I vote first to clear up BarotropicQG module as implied by #135 and then modify the BarotropicQG module to add such functionality.

pinging @liasiegelman as she's interested and could help us out here.

Combine BarotropicQG and BarotropicQGQL

Continuing the discussion from FourierFlows issue #72.

At first glance, these problems have a lot in common.

In fact, I think it may ultimately make sense to include 2D turbulence in BarotropicQG, at least for the purposes of the GeophysicalFlows package. In GeophysicalFlow, 2D turbulence certainly is a type of barotropic QG flow.

Let's discuss the specific pros and cons. I'm not sure what is meant by the inclusion being 'cumbersome', but I do see some pros in avoiding the duplication of functions that calculate things like energy and enstrophy.

Convention for the hypoviscosity order: should it be positive or negative

At the moment, the code assumes that hypoviscosity order must is negative; see, e.g.,

L = @. - params.ν * grid.Krsq^params.- params.μ * grid.Krsq^params.

but the Docs in some places imply that it is positive, e.g.,
$$\mathcal{L} = -\mu k^{-2n_\mu} - \nu k^{2n_\nu}\ ,$$

Let's choose one of the two conventions and smooth out everything in source code, examples, and docs (across all modules). Opinions?

error message: multilayerqg_2layer.jl

Hi,

I tried to follow the example of multilayerqg_2layer.jl and encountered the following error message:

## Problem setup

We initialize a Problem by providing a set of keyword arguments,

prob = MultilayerQG.Problem(nlayers, dev; nx=nx, Lx=Lx, f0=f0, g=g, H=H, ρ=ρ, U=U, dt=dt, stepper=stepper, μ=μ, β=β)
nothing # hide

MethodError: no method matching zeros(::Int64, ::CPU, ::Tuple{Int64,Int64})
Closest candidates are:
  zeros(!Matched::CPU, ::Any, ::Any) at /Users/XXX/.julia/packages/FourierFlows/Xyzjv/src/utils.jl:76
  zeros(!Matched::Union{Integer, AbstractUnitRange}...) at array.jl:499

Stacktrace:
 [1] top-level scope at In[14]:1

Not sure how to solve this...

Best

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.