Added two 4-poly triangular pyramid models (equilateral and directional)

[zeyus]

Additional low-poly agent models.

• Equilateral triangular pyramid (4 poly)
• Arrowhead triangular pyramid (4 poly)

[Robadob]

Changes look good, will try and find time to test it out tomorrowMonday*. Will also merge the other pending PR then (which has changes in main repo too), so that main lib gets updated visualiser.

[zeyus]

Documentation added here: https://github.com/FLAMEGPU/FLAMEGPU2-docs/pull/92

[Robadob]

Out of curiosity @zeyus, how did you find out about FLAMEGPU?

[zeyus]

Out of curiosity @zeyus, how did you find out about FLAMEGPU?

I'm an ex-dev currently getting my bachelors in cognitive science, one of our courses had a big ABM section and they were demonstrating writing them in NetLogo and R. I felt sad that their models took so long to run, so I tried to search for a bunch of different phrases along the lines of "gpu abm" and eventually found FLAMEGPU. It seemed fleshed out enough that I could use it for an exam paper, and it's been fun learning it so far. My main problem is that I think I've decided to model something that's increasingly akin to modelling the universe haha.

[Robadob]

they were demonstrating writing them in NetLogo and R. I felt sad that their models took so long to run

Yeah, traditionally ABMs are very computationally expensive compared to macroscopic modelling techniques. So with CPU based simulators, you can quickly run into performance issues when your agent population grows. The Single Instruction Multiple Threads (SIMT) architecture of GPUs is well suited for ABMs though, where you have many agents executing the same code.

With FLAMEGPU2 we're able to push agent populations to the millions.

This graph is the performance we're seeing with the "Circles" model, using spatial messaging, such that agents each read around ~200 messages from their local neighbourhood. It's a relatively simple model (and this is using beefy V100/A100 GPUs), however it's representative of communication which is generally the most expensive component of most models we work with.

Same graph, but with BruteForce communication (all-to-all). Performance is significantly worse, but generally we'd discourage people from using this for large populations.

The main limitation we run up against is having enough GPU memory to store all the agents. FLAMEGPU is currently constrained by a single GPUs memory. We've applied for funding to continue development, to 'ExaScale', supporting multi-gpu and potentially distributed across multi-node too. So if we're lucky enough to get that, we'll hopefully be able to support even larger agent populations in a few years time.

It seemed fleshed out enough that I could use it for an exam paper

FLAMEGPU2 is ready to be used, it's probably been there for around a year now, the model of a Neuroblastoma (tumour) that I've been working on the past few years (which has funded my time working on this project) has been transferred to FLAMEGPU2 (from a highly modified version of FLAMEGPU1) and works correctly with performance similar to that of the FLAMEGPU1 version.

Likewise, a PhD candidate at our university is currently developing a model of tumours in bone and a visiting researcher is developing a mechanical model of tissue.

FLAMEGPU1 has been used for alot more than just biological sims though: pedestrians, traffic, floods and more.

We currently have a paper under review, to properly announce FLAMEGPU2. It's possible when that's published we'll move to a full release (or maybe just beta). Although there's still a breaking change I want to make (getting rid of the references during model description), it's time consuming and not a priority,

and it's been fun learning it so far.

One of the goals with FLAMEGPU2 has been to make it more accessible to researchers who aren't comfortable writing models in C++ (which is why we have the Python interface). Agent functions are still in a subset of CUDA C++, and from supporting the visiting researcher I'm seeing their challenges using it from a Python background. One of my boss's pet projects is to write a transpiler to convert python-esqe syntax to compliable agent functions, but that's still in the early stages. Hopefully, if you have a development background, you will be more comfortable though.

My main problem is that I think I've decided to model something that's increasingly akin to modelling the universe haha.

The hardest part I normally find is the calibration and validation.

[zeyus]

Hey @Robadob, I'm back from vacation now, I'll take a look at this now :)

[zeyus]

I just double checked and it seems correct, did you import the obj with the X forward Z up?

I'm happy to change the orientation if it makes more sense to have it rotated differently.

[zeyus]

By the way thanks for the information in the previous reply, that's really interesting. I'll be implementing a grid communication, maybe spatial as well. I'm essentially confining my simulation to 2 spatial dimensions (no need for Z axis agent movement) as I'm representing group dynamics so the agents should cluster by group attributes.

Also, this is just an anecdotal report, but after returning and trying out the simulation I've started working on, I saw a massive speed increase. My python (3.10.5), pyflamegpu (2.0.0-alpha.3), CUDA (11.7) versions haven't changed, but there were two things that were updated: my nvidia drivers (516.59) and the windows 11 version (10.0.22622). I didn't run any benchmarks previously, but just visually watching the simulation it seemed like a huge speed increase (it's now running at 600 sps, I'm somewhat confident that previously it was running around 60-80 sps). Unfortunately, I don't think I can give much insight into why exactly this might be.

We've applied for funding to continue development, to 'ExaScale', supporting multi-gpu and potentially distributed across multi-node too. So if we're lucky enough to get that, we'll hopefully be able to support even larger agent populations in a few years time.

This is amazing! Meanwhile, I'll just keep grinding away on my 1070 with 8GB VRAM ;)

One of the goals with FLAMEGPU2 has been to make it more accessible to researchers who aren't comfortable writing models in C++ (which is why we have the Python interface). Agent functions are still in a subset of CUDA C++, and from supporting the visiting researcher I'm seeing their challenges using it from a Python background.

I think that's really great, I probably would not have tried it without the python interface, I can write C++, but I'm not that comfortable in it, and while I get a kick out of diving into things, that would have been an additional hurdle for this project that would require too much time to make it feasible. The CUDA C++ part I don't personally find bad at all, but I can imagine a lot of researchers might find that too difficult (even just the concept of variable types).

One of my boss's pet projects is to write a transpiler to convert python-esqe syntax to compliable agent functions, but that's still in the early stages.

Oof, that seems like a massive project, but I can see huge value for it.

Have you thought of getting swig to generate R bindings as well? In my degree program, most of the lecturers seem to use R, and a fair bit of course time was spent on R-oriented projects. If that's something you're interested in, I could probably help out a bit with the R interface (though the CUDA C++ hurdle will still exist for users). I'm no swig expert but the documentation implies it's possible to get cross platform functionality working https://swig.org/Doc4.0/R.html#R:

They have been used to compile and run an R interface to QuantLib running on Mandriva Linux with gcc. They are also used to create the SimpleITK R package, which runs on Linux and MacOS. SWIG is used to create all wrapper interfaces to SimpleITK. The R bindings also work on Microsoft Windows using Visual C++.

[Robadob]

I just double checked and it seems correct, did you import the obj with the X forward Z up?

I'm happy to change the orientation if it makes more sense to have it rotated differently.

I don't actually recall how I put it into blender, I probably dragged it in, rather than using import.

We use Y up, rather than Z up (afaik this is common to OpenGL, but some game engines order the axis differently). Perhaps where the confusion is coming from.

I first tested it by running the python boids example, this should be configured correctly with the airplane model, so it faces the direction the agents move.

[Robadob]

Unfortunately, I don't think I can give much insight into why exactly this might be.

Not immediately clear to me either. We've made several performance improvements since the last official release though.

Oof, that seems like a massive project, but I can see huge value for it.

It looks close to being merged, you can keep an eye on it here. Unlikely to get a new official release for it though, so will require a manual build.

Have you thought of getting swig to generate R bindings as well?

Yes, this has been mentioned in our ExaScale grant application as R is used quite heavily by many researchers that our wider (research software engineering) team support.

Two caveats though

• The swig support for each language differs. Python is one of the oldest/most developed interfaces so it has very good support (we do alot of weirder C++ stuff that SWIG has to deal with). We haven't looked properly at SWIG's R support, so can't confirm its thorough enough for our requirements.
• None of us who currently develop FLAMEGPU are R users, so we will need to get to grips with it first.

[zeyus]

We use Y up, rather than Z up (afaik this is common to OpenGL, but some game engines order the axis differently). Perhaps where the confusion is coming from.

Fixed, they're now exported with Z up, and I also adjusted the origin to be the center of the bottom face so it sits on the X,Z plane as I saw that's also how the teapot was configured.

[zeyus]

It looks close to being merged, you can keep an eye on it here. Unlikely to get a new official release for it though, so will require a manual build.

Seems really nice!

Two caveats though

• The swig support for each language differs. Python is one of the oldest/most developed interfaces so it has very good support (we do alot of weirder C++ stuff that SWIG has to deal with). We haven't looked properly at SWIG's R support, so can't confirm its thorough enough for our requirements.
• None of us who currently develop FLAMEGPU are R users, so we will need to get to grips with it first.

That's all fair, I'll have some time in a couple of weeks and I'll see what would be involved in at least generating the bindings for R, I know there are R libraries that use C lib bindings, but I don't know what their build process is like (i.e. no idea if the use swig, some other tool, or their own custom code).

[zeyus]

imported plane (body only) with default orientation and the arrowhead pyramid model: