You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It may be a good time to start scoping out which discretization and solver libraries the project will use to solve PDEs. It will be important to decide early on what kinds of parallelism will be supported (threading, MPI, GPU, etc).
Do you think it's a bad idea to support multiple kinds of parallelism? GPUs seem perfect for high resolution PDEs, but I don't want to conclusively say we'll do that and nothing else.
Basically, what do you think is the best approach that stays general?
sympy.utilities.codegen has automatic code generation capabilities, I believe mostly for finite difference methods.
FEniCS is a partial differential equation solver using the finite element method (which is fairly similar to the spectral element method). From what I can tell, the equations need to be converted into variational form, but otherwise it looks very flexible. The biggest advantage of the finite element method is the geometric flexibility, which makes it highly suitable for simulating things like tokamaks which have circular-triangular-ish cross sections.
Dedalus is a flexible differential equation solver that's used for a lot of fluid problems. For this you write the equations in plain text as strings, and then these strings get parsed and solved. I don't think it can be installed using conda though.
I'm much more familiar with fluid rather than kinetic simulations, so I don't really know what's out there for particle-in-cell (PIC) simulations. My impression is GPUs are highly suitable for PIC simulations.
I've thought less about parallelization. There will probably be users who run small simulations on their laptops or workstations, and eventually others who will run them on large clusters. I'm very interested in other people's thoughts on this.
Well, multicore processors are the norm these days. It'd be a terrible shame not to use them at least!
And GPUs are indeed the best thing there is for PICs, as far as I know. We might have to look into PyCUDA for that, but it's probably not a very high priority just now.
Whatever piece of software handles the mesh for the PDE domain typically handles the parallelism too, and it can be difficult to add it after the fact. If support for multiple kinds of parallelism is in the cards, then it is important to choose libraries that support them.
I have used a lot of MFEM which is a C++ library, but there are python bindings. It works in serial, but scales up to thousands of cores on a cluster via MPI. GPU support is in progress and coming along well. It could be a decent fit for the project with the only gotcha being that it is a C++ library which of course will have to be compiled and linked before the python binding s will work. I should disclose that I am a dev on the MFEM project.
Activity
StanczakDominik commentedon Jul 30, 2017
Are you aware of any existing ones for PDEs?
Do you think it's a bad idea to support multiple kinds of parallelism? GPUs seem perfect for high resolution PDEs, but I don't want to conclusively say we'll do that and nothing else.
Basically, what do you think is the best approach that stays general?
namurphy commentedon Jul 30, 2017
Yes, this is a really good thing to bring up!
Some existing tools include:
sympy.utilities.codegenhas automatic code generation capabilities, I believe mostly for finite difference methods.I'm much more familiar with fluid rather than kinetic simulations, so I don't really know what's out there for particle-in-cell (PIC) simulations. My impression is GPUs are highly suitable for PIC simulations.
I've thought less about parallelization. There will probably be users who run small simulations on their laptops or workstations, and eventually others who will run them on large clusters. I'm very interested in other people's thoughts on this.
StanczakDominik commentedon Jul 31, 2017
Well, multicore processors are the norm these days. It'd be a terrible shame not to use them at least!
And GPUs are indeed the best thing there is for PICs, as far as I know. We might have to look into PyCUDA for that, but it's probably not a very high priority just now.
acfisher commentedon Jul 31, 2017
Whatever piece of software handles the mesh for the PDE domain typically handles the parallelism too, and it can be difficult to add it after the fact. If support for multiple kinds of parallelism is in the cards, then it is important to choose libraries that support them.
I have used a lot of MFEM which is a C++ library, but there are python bindings. It works in serial, but scales up to thousands of cores on a cluster via MPI. GPU support is in progress and coming along well. It could be a decent fit for the project with the only gotcha being that it is a C++ library which of course will have to be compiled and linked before the python binding s will work. I should disclose that I am a dev on the MFEM project.