11 ms·
GPU vendor-agnostic fluid dynamics solver in Julia
- brlcad 3y agoReally? Fluid solver with no pics?
- cl0ckt0wer 3y agoTheir Github page has it: https://github.com/weymouth/WaterLily.jl https://github.com/weymouth/WaterLily.jl
- ChrisRackauckas 3y agoThis is computational fluid dynamics, not colorful fluid dynamics /s
- boywitharupee 3y agoWhat is the difference?
- markkitti 3y agoI thought this might be related to the prior Julia to wasm fluid dynamics simulation, but it seems to be independent of that effort. https://alexander-barth.github.io/FluidSimDemo-WebAssembly/ https://alexander-barth.github.io/FluidSimDemo-WebAssembly/
- ksec 3y agoOn related note. Julia [1] announced their v1.9 release. [1] https://news.ycombinator.com/item?id=35861288 https://news.ycombinator.com/item?id=35861288
- sdfghswe 3y agoWhat? On the official page it's still on 1.9-rc3
- alhirzel 3y agoThe home page is not yet updated (probably waiting for the official binaries to be done, which are also not yet on the download bucket).
- Sukera 3y agoThere will also be a release blogpost, highlighting the new stuff. The release will likely come with that.
- sdfghswe 3y ago> probably waiting for the official binaries to be done For 3 weeks? Because that's how old those release notes are.
- Sukera 3y agoThere's a lot more than release notes going into a release - we've had 3 release candidates for a reason, and those regressions/bugs need to be fixed first.
- sdfghswe 3y agoe got it, but doesn't that suggest that just because release notes exist, doesn't mean something has been released? Unless ksec has special inside info for his claim, I think his link doesn't show anything.
- deleted 3y ago[deleted]
- ChrisRackauckas 3y agoThe release was just cut 9 hours ago, as shown on the releases part of the Github page (https://github.com/JuliaLang/julia/releases/tag/v1.9.0 https://github.com/JuliaLang/julia/releases/tag/v1.9.0). That then starts the jobs for the creation and deployment of the final binaries, and when that's done the Julialang.org website gets updated to state it's the release, and when that's done the blog post for the new release goes out. You can even follow the last step of the process here (https://github.com/JuliaLang/www.julialang.org/pull/1875 https://github.com/JuliaLang/www.julialang.org/pull/1875), since it all occurs on the open source organization.
- markkitti 3y agoThis is slightly premature. They only just tagged the release on Github several hours ago. While it does suggest the actual release is imminent, it's not really official until you see here on Discourse: https://discourse.julialang.org/c/announce/25 https://discourse.julialang.org/c/announce/25
- mnky9800n 3y agoAs a card carrying python-stack scientist who works at the intersection of machine learning and physical sciences for the last decade who now is working on an R package (pro-tip: go where the money is don't bring the money to you), can someone make a convincing argument for me to learn Julia? I would like to hear more than the typical "the code auto-differentiates" or "it's faster" or whatever it is that people have said in the past. I am really not trying to be flippant I just don't see the added value of learning a new language unless it has interesting packages/functionality that my current toolset does not (e.g., this is why I am working on an R package).
- JZL003 3y agoYou can have nice foreign function interface between R->Julia and Julia ->R. If you're already happy pulling out slow functions into RCpp, then maybe there's no speed benefit. But there are some very nice, very fast libraries in Julia, where if you have a tight inner loop, it could be worth looking into It reads and writes a lot like python (but nicer IMO), I don't think the learning curve is immense to try it for small optimizations. And it's also not unreadable so other people can verify your code
- mncharity 3y ago> nice foreign function interface between R->Julia and Julia ->R JuliaCall[1] and RCall[2]. Python<->Julia is similarly well exercised with PyCall[1], and recently PythonCall[2]. [1] https://non-contradiction.github.io/JuliaCall/index.html https://non-contradiction.github.io/JuliaCall/index.html [2] https://github.com/JuliaInterop/RCall.jl https://github.com/JuliaInterop/RCall.jl [3] https://github.com/JuliaPy/PyCall.jl https://github.com/JuliaPy/PyCall.jl [4] https://cjdoris.github.io/PythonCall.jl/stable/ https://cjdoris.github.io/PythonCall.jl/stable/
- Sukera 3y agoFor me personally, I just think it's really fun to write julia code. Granted, I'm neither machine learning nor physical science, but the fact that I can go through the whole stack and choose an abstraction that's right for the problem at hand (Metaprogramming? Regular struct-based abstractions? External program? LLVM optimization? Inline assembly?) and still being able to understand what's going on while getting good performance at the same time, is just magical to me. Maybe that's not for everyone, but to me the ratio of dev time to run time is just really, really good.
- Sukera 3y agoThe authors have previously also shown off that this can do 3D visualization in real time: https://twitter.com/gabrielweymouth/status/1648682741620195328 https://twitter.com/gabrielweymouth/status/16486827416201953...
- worldsayshi 3y agoHmm, the 3d render is done in Julia as well right? I wonder if there's a way to share the data buffer across languages. Would be neat if it was feasible to use the real time model data in a game.
- adgjlsfhk1 3y ago>I wonder if there's a way to share the data buffer across languages This is pretty much what Arrow is made for.
- worldsayshi 3y agoI assume you're talking about Apache Arrow? Interesting! Don't think I've seen this one. https://arrow.apache.org/ https://arrow.apache.org/ Edit: I'm surprised to not find anything when I try to find projects that try to use Apache Arrow in unity 3d. Seems to be a lot of interesting potential in leveraging various simulation libraries in game like applications. Edit2: Ah, probably because something like waterlilly would have to be rewritten quite a bit too use arrow.
- Archit3ch 3y agoSuccess stories like this make a better argument for "Why Lisp?" than abstract blog posts. We know macros are awesome, but if you're trying to convert others please provide code, screenshots, or even an interactive web demo.
- shakow 3y ago> abstract blog posts If you refer to the blog post that made Top HN yesterday, it is very much backed by actual experience (https://nyxt.atlas.engineer/ https://nyxt.atlas.engineer/) and quite a load of code (https://github.com/atlas-engineer/nyxt/tree/master/source https://github.com/atlas-engineer/nyxt/tree/master/source).
- nextaccountic 3y agoJust a little thing, this is in Julia
- elcritch 3y agoSome have said Python is "enough" of a Lisp, but it's really not. Julia is much closer to being a true Lisp. It has macros sure, but its the overall feel and flexibility of the ecosystem that feels Lispy. At least as much as I've dabbled with Lisp and its history.
- cosmojg 3y agoHave you tried running `julia --lisp`? That's a full-blown Femtolisp interpreter built right into the REPL! I also recommend playing with `Meta.show_sexpr` which can take any Julia expression and represent it as an S-expression. For example: julia> Meta.show_sexpr(:(f(x, g(y,z)))) (:call, :f, :x, (:call, :g, :y, :z)) Lastly, this old doc page comparing and contrasting Julia with Common Lisp is a fun read: https://docs.julialang.org/en/v1.3-dev/manual/noteworthy-differences/#Noteworthy-differences-from-Common-Lisp-1 https://docs.julialang.org/en/v1.3-dev/manual/noteworthy-dif...
- vrglvrglvrgl 3y ago[dead]
- samstave 3y agoDope! Can anyone help me with the following, as this has been 'floating' around in my head for nearly a decade ; Wales (the animal) oft have barnacles on the leading edges of their flippers, which results in an eddy effect which increases efficiency/thrust. Da Vinci was the earliest known documentor of eddy-based pumps and predicted the eddies in the ventricular systems of the hearts pumping of blood... What I would like to model is a toroidal propeller with leading edge bumps ('barnacles') while also having the dimpling pattern of a golf ball to reduce drag... and I want to measure if this idea holds water. I just dont know how to model this using this tool... help?
- b-fg 3y agoAs long as you can define a signed distance function, and the function governing the motion of the propeller, WaterLily can simulate it!
- elil17 3y agoI don’t think that’s true. What about cavitation?
- b-fg 3y agoCavitation has nothing special other than multi-phase flow. And implementing a VOF method is definitely in our roadmap. You can currently simulate it without cavitation to get a feeling of the unsteady flow solution, or wait for us to implement VOF.
- samstave 3y agoCavitation is precisely what I would like to test... Also, will 'waterlilly' work with a viscosity to Air? Meaning - toroidal props are a newer entering thing in drones... and I'd like to find out if the above applies equally to fluid/air?
- b-fg 3y agoThen you should is a different solver that fills your needs. WaterLily is an incompressible flow solver that works in non-dimensional units (assuming constant unit density). So you can change the viscosity of the fluid by modifying the Reynolds number (with set a set characteristic velocity and length scale).
- codedokode 3y agoThe title says "GPU vendor-agnostic". But in fact for AMD only professional (expensive) GPUs are supported (ROCm is officially unsupported on most consumer and integrated GPUs). To be truly vendor-agnostic it needs to support OpenGL or Vulkan. Also this is the first time I saw examples of Julia code and the syntax looks worse than C++.
- DNF2 3y ago> Also this is the first time I saw examples of Julia code and the syntax looks worse than C++. For someone who writes both Julia and C++, the above comment comes across as an obscene joke. Possibly, you object to the programming style in that library, the choice of identifiers or whatever? But that has nothing to do with language syntax.
- codedokode 3y agoI explained in this comment https://news.ycombinator.com/item?id=35868305 https://news.ycombinator.com/item?id=35868305
- markkitti 3y agoYou may be confusing front end APIs and the compiler backends. Julia is flexible enough that you can essentially define domain specific languages within Julia for certain applications. In this case, we are using Julia as an abstract front end and then deferring the concrete interface to vendor specific GPU compilation drivers. Part of what permits this is that Julia is a LLVM front end and many of the vendor drivers include LLVM-based backends. With some transformation of the Julia abstract syntax tree and the LLVM IR we can connect the two. That said we are mostly dependent on vendors providing the backend compiler technology. When they do, we can bridge Julia to use that interface. We can wrap Vulkan and technologies like oneAPI. https://github.com/JuliaGPU/Vulkan.jl https://github.com/JuliaGPU/Vulkan.jl https://github.com/JuliaGPU/oneAPI.jl https://github.com/JuliaGPU/oneAPI.jl As for syntax, Julia syntax scales from a scripting language to a fully typed language. You can write valid and performant code without specifying any types, but you can also specialize methods for specific types. The type notation uses `::`. The types also have parameters in the curly brackets. The other aspect that makes this specific example complicated is the use of Lisp-like macros which starts with `@`. These allow for code transformation as I described earlier. The last aspect is that the author is making extensive use of Unicode. This is purely optional as you can write Julia with just ASCII. Some authors like to use `ε` instead of `in`.
- DNF2 3y agoAfter clicking trough to the repository, I found this part a bit perplexing: "running on a GPU requires initializing the Simulation memory on the GPU, and care needs to be taken to move the data back to the CPU for visualization." The original purpose of GPUs were visualization, so that seems backwards to me. And, GLMakie is used, which makes it even more counter-intuitive, isn't that specifically built for GPU visualization?
- b-fg 3y agoYou are right. Ideally we would like to keep everything in GPU memory of course. But we have not been able to render CuArrays with Makie yet, and I'm not sure if that is actually implemented, as you suggest. If so, it would be great to see an example of this :)
- mif 3y agoI‘m currently playing around with Oceananigans.jl (https://github.com/CliMA/Oceananigans.jl https://github.com/CliMA/Oceananigans.jl). Do you know how both are similar or different? Oceananigans.jl has really intuitive step-by-step examples and a great discussion page on GitHub.
- b-fg 3y agoOceananigans is used for climate modelling and they use a different set of equations for this purpose (hydrostatic Boussinesq equations instead of Navier-Stokes equations). On the other hand, the numerical method both use is the same, finite volume, and the way we have CPU and GPU execution is using KernelAbstractions.jl in both cases too.
- spearman 3y agoThis is cool but following some of the links it seems like there are a lot of immature parts of the ecosystem and things will not "just work". See for example this bug which I found from the blog post: https://github.com/odsl-team/julia-ml-from-scratch/issues/2 https://github.com/odsl-team/julia-ml-from-scratch/issues/2 Summarizing, they benchmark some machine learning code that uses KernelAbstractions.jl on different platforms and find: * AMD GPU is slower than CPU * Intel GPU doesn't finish / seems to leak memory * Apple GPU doesn't finish / seems to leak memory Would also be interesting to compare the benchmarks to hand-written CUDA kernels (both in Julia and C++) to quantify the cost of the KernelAbstractions layer.