#gpusph — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #gpusph, aggregated by home.social.
-
The reason for this is that the process of formation of sugar crystals in #fudge has strong parallels with the formation of crystals in #magma, which is fascinating.
I'm not as surprised as I could be, because this is actually the second time that I come across #food-related physics that is relevant for #geophysics: one of the rheological models that we have implemented in #GPUSPH to study #lava flows is the DeKee & Turcotte model, which is a regularization of the Herschel–Bulkley model that was developed for biological materials, among which food stuff such as honey, yogurt, mayonnaise and banana puree
https://doi.org/10.1080/00986448008912535
Preliminary results for this were presented at the VII Congress on Rheology in 1976, and the DeKee et al contribution, available in the conference proceedings <https://doi.org/10.1007/978-1-4684-3746-1_107> is titled
“Rheological Characterization of Time-Dependent Foodstuffs“
-
The number of people who don't know about #GPUSPH within #INGV is too damn high (.jpg).
Memes aside, I've had several opportunities these days to talk with people both within the Osservatorio Etneo and other branches of the Institute, and most of them had no idea something like that was being developed within INGV.
On the one hand, this is understandable, especially for teams that have never had a direct need to even look for #CFD code because of the focus of their research.
On the other hand, this also shows that I should have been much more aggressive with marketing the project internally. (And don't even get me started on who had the actual managerial power to do so before me, but that would put me on a rant that I'd rather avoid for now.)
I'm glad I've finally started working on this aspect, but also I can't say I'm too happy about having to do so.
Hopefully this is something that will help bring mass to it.
-
Our most recent paper on #SPH / #FEM coupling for offshore structures modeling with #GPUSPH has been published:
https://authors.elsevier.com/c/1m3VB_hNWk2tT
These kinds of works, with validation against experimental results, is always a challenging task, even for the simpler problems. Lab experiments and numerical simulations have each their own set of problems that need to be addressed, and the people working on the two sides of the fence often have a very different perspective on what should be considered trivial and not worth measuring, and what is instead crucial to the success of the experiment.
Getting these two sides to talk to each other successfully is no walk in the park, and I wish to extend my deepest gratitude to Vito Zago, who has gone to incredible lengths both during the “science making” to make things work out, and during the manuscript submission and review process, a nearly Sisyphean task in itself.
#SmoothedParticleHydrodynamics #FiniteElements #FiniteElementMethods
-
Today I introduced a much-needed feature to #GPUSPH.
Our code supports multi-GPU and even multi-node, so in general if you have a large simulation you'll want to distribute it over all your GPUs using our internal support for it.
However, in some cases, you need to run a battery of simulations and your problem size isn't large enough to justify the use of more than a couple of GPUs for each simulation.
In this case, rather than running the simulations in your set serially (one after the other) using all GPUs for each, you'll want to run them in parallel, potentially even each on a single GPUs.
The idea is to find the next avaialble (set of) GPU(s) and launch a simulation on them while there are still available sets, then wait until a “slot” frees up and start the new one(s) as slots get freed.
Until now, we've been doing this manually by partitioning the set of simulations to do and start them in different shells.
There is actually a very powerful tool to achieve this on the command, line, GNU Parallel. As with all powerful tools, however, this is somewhat cumbersome to configure to get the intended result. And after Doing It Right™ one must remember the invocation magic …
So today I found some time to write a wrapper around GNU Parallel that basically (1) enumerates the available GPUs and (2) appends the appropriate --device command-line option to the invocation of GPUSPH, based on the slot number.
#GPGPU #ParallelComputing #DistributedComputing #GNUParallel
-
Talking about dependencies: one thing we did *not* reimplement in #GPUSPH is rigid body motion. GPUSPH is intended to be code for #CFD, and while I do dream about making it a general-purpose code for #ContinuumMechanics, at the moment anything pertaining solids is “delegated”.
When a (solid) object is added to a test case in GPUSPH, it can be classified as either a “moving” or a “floating” object. The main difference is that a “moving” object is assumed to have a prescribed motion, which effectively means the user has to also define how the object moves, while a “floating” object is assumed to move according to the standard equations of motion, with the forces and torques exerted on the body by the fluid provided by GPUSPH.
For floating objects, we delegate the rigid body motion computation to the well-established simulation engine #ProjectChrono
https://projectchrono.org/Chrono is a “soft dependency” of GPUSPH: you do not need it to build a generic test case, but you do need it if you want floating objects without having to write the entire rigid body solver yourself.
1/n
#SmoothedParticleHydrodynamics #SPH #ComputationalFluidDynamics
-
That first implementation didn't even support the multi-GPU and multi-node features of #GPUSPH (could only run on a single GPU), but it paved the way for the full version, that took advantage of the whole infrastructure of GPUSPH in multiple ways.
First of all, we didn't have to worry about how to encode the matrix and its sparseness, because we could compute the coefficients on the fly, and operate with the same neighbors list transversal logic that was used in the rest of the code; this allowed us to minimize memory use and increase code reuse.
Secondly, we gained control on the accuracy of intermediate operations, allowing us to use compensating sums wherever needed.
Thirdly, we could leverage the multi-GPU and multi-node capabilities already present in GPUSPH to distribute computations across all available devices.
And last but not least, we actually found ways to improve the classic #CG and #BiCGSTAB linear solving algorithms to achieve excellent accuracy and convergence even without preconditioners, while making the algorithms themselves more parallel-friendly:
https://doi.org/10.1016/j.jcp.2022.111413
4/n
-
Even now, Thrust as a dependency is one of the main reason why we have a #CUDA backend, a #HIP / #ROCm backend and a pure #CPU backend in #GPUSPH, but not a #SYCL or #OneAPI backend (which would allow us to extend hardware support to #Intel GPUs). <https://doi.org/10.1002/cpe.8313>
This is also one of the reason why we implemented our own #BLAS routines when we introduced the semi-implicit integrator. A side-effect of this choice is that it allowed us to develop the improved #BiCGSTAB that I've had the opportunity to mention before <https://doi.org/10.1016/j.jcp.2022.111413>. Sometimes I do wonder if it would be appropriate to “excorporate” it into its own library for general use, since it's something that would benefit others. OTOH, this one was developed specifically for GPUSPH and it's tightly integrated with the rest of it (including its support for multi-GPU), and refactoring to turn it into a library like cuBLAS is
a. too much effort
b. probably not worth it.Again, following @eniko's original thread, it's really not that hard to roll your own, and probably less time consuming than trying to wrangle your way through an API that may or may not fit your needs.
6/
-
I believe our approach to “develop what we need when we need it”, which has been a staple in the development of #GPUSPH, has been a strong point. We *do* depend on a few external dependencies, but most of the code has been developed “in-house”.
Fun fact: the only “hard dependency” for GPUSPH is NVIDIA's Thrust library, which we depend on for particle sorting (and in a few other places, but for optional features, like the segmented reductions used to collect body forces when doing #FSI i.e. #FluidStructureInteraction aka #FluidSolidInteraction).
And this hard dependency has been a *pain*.
We first had issues in the Maxwell architecture era, which stalled our work for months because all simulations would consistently lead to a hardware lock-up
https://github.com/NVIDIA/thrust/issues/742
and a few years later we had another issue —luckily one we could work around within GPUSPH this time:
https://github.com/NVIDIA/thrust/issues/13415/
-
I believe our approach to “develop what we need when we need it”, which has been a staple in the development of #GPUSPH, has been a strong point. We *do* depend on a few external dependencies, but most of the code has been developed “in-house”.
Fun fact: the only “hard dependency” for GPUSPH is NVIDIA's Thrust library, which we depend on for particle sorting (and in a few other places, but for optional features, like the segmented reductions used to collect body forces when doing #FSI i.e. #FluidStructureInteraction aka #FluidSolidInteraction).
And this hard dependency has been a *pain*.
We first had issues in the Maxwell architecture era, which stalled our work for months because all simulations would consistently lead to a hardware lock-up
https://github.com/NVIDIA/thrust/issues/742
and a few years later we had another issue —luckily one we could work around within GPUSPH this time:
https://github.com/NVIDIA/thrust/issues/13415/
-
I believe our approach to “develop what we need when we need it”, which has been a staple in the development of #GPUSPH, has been a strong point. We *do* depend on a few external dependencies, but most of the code has been developed “in-house”.
Fun fact: the only “hard dependency” for GPUSPH is NVIDIA's Thrust library, which we depend on for particle sorting (and in a few other places, but for optional features, like the segmented reductions used to collect body forces when doing #FSI i.e. #FluidStructureInteraction aka #FluidSolidInteraction).
And this hard dependency has been a *pain*.
We first had issues in the Maxwell architecture era, which stalled our work for months because all simulations would consistently lead to a hardware lock-up
https://github.com/NVIDIA/thrust/issues/742
and a few years later we had another issue —luckily one we could work around within GPUSPH this time:
https://github.com/NVIDIA/thrust/issues/13415/
-
I believe our approach to “develop what we need when we need it”, which has been a staple in the development of #GPUSPH, has been a strong point. We *do* depend on a few external dependencies, but most of the code has been developed “in-house”.
Fun fact: the only “hard dependency” for GPUSPH is NVIDIA's Thrust library, which we depend on for particle sorting (and in a few other places, but for optional features, like the segmented reductions used to collect body forces when doing #FSI i.e. #FluidStructureInteraction aka #FluidSolidInteraction).
And this hard dependency has been a *pain*.
We first had issues in the Maxwell architecture era, which stalled our work for months because all simulations would consistently lead to a hardware lock-up
https://github.com/NVIDIA/thrust/issues/742
and a few years later we had another issue —luckily one we could work around within GPUSPH this time:
https://github.com/NVIDIA/thrust/issues/13415/
-
I believe our approach to “develop what we need when we need it”, which has been a staple in the development of #GPUSPH, has been a strong point. We *do* depend on a few external dependencies, but most of the code has been developed “in-house”.
Fun fact: the only “hard dependency” for GPUSPH is NVIDIA's Thrust library, which we depend on for particle sorting (and in a few other places, but for optional features, like the segmented reductions used to collect body forces when doing #FSI i.e. #FluidStructureInteraction aka #FluidSolidInteraction).
And this hard dependency has been a *pain*.
We first had issues in the Maxwell architecture era, which stalled our work for months because all simulations would consistently lead to a hardware lock-up
https://github.com/NVIDIA/thrust/issues/742
and a few years later we had another issue —luckily one we could work around within GPUSPH this time:
https://github.com/NVIDIA/thrust/issues/13415/
-
And of course if possible you want to let the user choose arbitrary inter-particle spacings, possibly at runtime. This is e.g. the reason why #GPUSPH has a built-in simple #CSG (#ConstructiveSolidGeometry) system: it's not needed for #SPH, but it allows user to set up test cases even with relatively complex geometries without resorting to external preprocessing stages that wouldn't give the same flexibility in term of resolution choices.
And here's the thing: the CSG in GPUSPH has a *lot* of room for improvement, but it's not really the “core” of GPUSPH: how much developer time should be dedicated to it, especially considering that the number of developers is small, and most have more competences in the mathematical and physical aspects of SPH rather than in CSG?
The end result is that things get implemented “as needed”, which brings me back to the gamedev thread I was mentioning earlier:
3/
-
Hello all! This will be the official #GPUSPH account on the Fediverse going forward. What is GPUSPH, you ask? It's a software for #ComputationalFluidDynamics using the #SmoothedParticleHydrodynamics method, accelerated by running entirely* on GPU. In fact, it was the first to do so, leveraging the new GPGPU capabilities offered by NVIDIA CUDA.
(These days we have wider hardware support, but for a long time CUDA was all we supported.)
#introduction #newHere #CFD #HPC
*conditions apply
-
The result is something that can be trivially parallelized with #OpenMP.
As an alternative, it's possible to use the #multiGPU support in #GPUSPH to run code in parallel. This is obviously less efficient, although it may be a good idea to use it in #NUMA setups (one thread per NUMA node, OpenMP for the cores in the same node). This is not implemented yet. -
It's out, if anyone is curious
https://doi.org/10.1002/cpe.8313
This is a “how to” guide. #GPUSPH, as the name suggests, was designed from the ground up to run on #GPU (w/ #CUDA, for historical reasons). We wrote a CPU version a long time ago for a publication that required a comparison, but it was never maintained. In 2021, I finally took the plunge, and taking inspiration from #SYCL, adapted the device code in functor form, so that it could be “trivially” compiled for CPU as well.
-
Well, this is interesting.
Someone has posted an announcement for open #postDoc and #ResearchAssociate positions on the #GPUSPH forum
https://gpusph.discourse.group/t/postdoc-ra-positions-at-oregon-state-university/207
Although they are not specifically about GPUSPH the software, they are about #GPU, #SPH and related topics (including wave modeling for #oceanEngineering #coastalEngineering), so I think I'll leave the announcement up. -
I've been working on thermal support in #GPUSPH, and was finally at the stage where I could run some tests and check the results. Except that #ParaView was refusing to open my files, complaining about “invalid token”s. I just spent over half an hour trying to understand what I changed in my code that had broken the output, even though I haven't changed anything related to it recently … turns out it wasn't my problem, but an issue with an upgrade ParaView and libexpat:
https://discourse.paraview.org/t/i-cannot-read-a-vtp-file-i-could-open-yesterday-can-someone-try-to-open-it/13938/12 -
Ultime ore per venire a lavorare con me all'#INGV participando a questo bando per un assegno professionalizzante, 18 mesi.
Argomento: simulazione del trasporto di #plastiche sotto costa e ricerca di strategie di #mitigazione. Useremo il nostro #GPUSPH, quindi anche per i curiosi di programmazione #GPU questa è un'ottima occasione.
#ecologia #scienza #lavoro #ricerca #ambiente #lavoroOffro #offroLavoro
-
I'm sitting here trying to finish the presentation on #GPUSPH to be presented at #SIMAI2023 next week, and while the thing is “done” overall, I can't think of anything to put on the #conclusions (final slide). I'm stymied.
-
I'm sitting here trying to finish the presentation on #GPUSPH to be presented at #SIMAI2023 next week, and while the thing is “done” overall, I can't think of anything to put on the #conclusions (final slide). I'm stymied.
-
I'm sitting here trying to finish the presentation on #GPUSPH to be presented at #SIMAI2023 next week, and while the thing is “done” overall, I can't think of anything to put on the #conclusions (final slide). I'm stymied.
-
I'm sitting here trying to finish the presentation on #GPUSPH to be presented at #SIMAI2023 next week, and while the thing is “done” overall, I can't think of anything to put on the #conclusions (final slide). I'm stymied.