Repository navigation
Include a full particle in cell code #69
Description
With the particle stepper pretty much being finished and live I believe we could begin thinking about including a full pic simulation within the code.
I don't think we need to focus on beating commercial and research codes at scalability, efficiency or speed, it'd be nice if that turned out to be the case, but it'd take a lot of effort and it's probably better to start small.
I think what would work better within open source is to have a simulation code that's feature complete, reliable, well documented, with ample test cases, visualization, something people could study and learn from, something you can compare results with. I know that part has been a pain in my experience.
It'd also be somewhat neat to have the same interface as the MHD simulation.
Generality is also nice, being able to easily replace and compare the numerical methods used seems like a good idea.
Of course, that doesn't mean we're going slow on it either, I'd like to start with numpy, numba and possibly add pycuda later on (that'd need a separate issue).
I've got a code of mine that I'd like to adapt here.
What does everyone think about this? I'd very much appreciate input and help with this one. Literature suggestions beyond Birdsall and Landon would also be nice!
Activity
antoinetavant commentedon Aug 1, 2017
I'd like to contribute. I totally agree with the objectives you said, especially about speed and well documented and tested.
However, I think we have to discuss about few points to begin with :
I would answer the 3. by the second proposition : let's provide a toolbox and a framework. So that every users can simulate what they want, the way they want, and we won't have to think of all of the possibilities ourselves. And of course we would provide examples. I guess this make reference to #73 .
I'm not sure I'm clear. Anyway I'm supper down for that !
PS : there is some Python PIC codes
https://github.com/fbpic/fbpic
https://github.com/skuschel/postpic
I've got plenty of paper about PIC validation and benshmarks, but Birdsall is still my bible ! :)
StanczakDominik commentedon Aug 1, 2017
@antoinelpp re: your 1, I know that's a pain, but that's kind of a given for a generic package for plasma physics, probably one of the broadest fields in physics.
I think the framework idea is best: letting people pick and choose the kind of simulation they want to run helps the most people, though it is indeed going to be difficult. Besides, if they built something on top of it, that can always be pulled back into the main package.
If I understand it right, this would mean making a few presets:
Cold plasma,Laser-plasma,Space... maybe picking one that's relatively simple and inviting collaborators for other kinds of plasmas?Do you think it's too crazy to want to, at least eventually, support full 3D PIC simulation in PlasmaPy, or is that potentially realistic?
antoinetavant commentedon Aug 1, 2017
@StanczakDominik 3D pic is very time consuming. Even in the HPC sector, people don't try it too much.
However, we can think of it, starting from low but keeping in mind that 3D can eventually supported.
Building a generic framework for the different presets sound nice ! I like that.
StanczakDominik commentedon Aug 3, 2017
Awesome, let's start with 1D and 2D first then :) I made a project for this one. I'll try to make a bunch of issues for things to do to make this stepper a full fledged PIC code, but I probably won't be able to do that today. If you want to try, go right ahead!
18 remaining items
tulasinandan commentedon Apr 24, 2018
Oh I so wish that I had learned C at some point in my life. I tried a couple of times but never pushed any project hard enough to learn and use C on a regular basis. I guess this will eventually be my first dig at something that is close to C. At the first dig we should probably stick to the serial versions that @StanczakDominik and @antoinelpp have and increment on top of that base.
lemmatum commentedon Apr 24, 2018
@StanczakDominik you've read the Cython book, do you remember anything about memory allocation for parallelization? It may just be that we need to slice up the PIC simulation into subregions and then let each core handle a region.
@tulasinandan Here's some stuff on the GIL. Looks like Numba is another way of dealing with GIL/parallelization.
tulasinandan commentedon Apr 24, 2018
@lemmatum Yes, that is the standard strategy: slice up the domain into subregions handled by individual cores. For fields it's pretty straightforward, the cores simply exchange boundaries with their neighbors. For particles we have to think about all the mess mentioned above.
StanczakDominik commentedon Apr 24, 2018
As for the Cython book, that only skimmed on parallelism. It touched on disabling the GIL, showed a couple of examples and mentioned OpenMP, if I remember correctly, but there wasn't much about the subject. I'll keep digging into this...
I'm loving the discussion in this thread, by the way!
lemmatum commentedon Apr 30, 2018
@tulasinandan I see! I didn't initially understand that this was about dealing with particles being passed off between subregions where each subregion is assigned to a processor/thread.
@StanczakDominik yea, I remember parallelism being a bit scant. I guess we'll have to dig into OpenMP and Cython's online documentation.
Also Cython has a structure called Memoryviews which may be applicable. Here is some stuff on Cython memory allocation as well.
github-actions commentedon Oct 19, 2024
This issue will be closed in 90 days due to five years of inactivity unless the stale label or comment is removed.
github-actions commentedon Jan 18, 2025
This issue was closed because it has had no activity for five years.