Introductions

[Cameron Sajedi]

Hello, 

I am glad to be added to the development group for Dedalus. I am a computer programmer with an interest in numerical modeling. I've been searching for a project to contribute and learn with, and this one looks promising.

I think it makes sense for me to ask you developers what problems are still outstanding, and what kind of developer you would most like to add to the team? My previous speciality is GPU parallelization, and so I thought maybe I could write some routines to optimize the algorithm for a highly parallel environment. What do you think? Feel free to comment and make different suggestions as well. 

Cheers,

Cameron

[Keaton Burns]

Hi Cameron, 

Great to meet you!  We’re actually in the midst of a large overhaul/rewrite of the codebase, to give us more flexibility in terms of the spectral domains we can represent.  However, these changes are somewhat orthogonal to your suggestions regarding parallel optimization and particularly GPU programming.  A few of us have messed around with GPUs a bit in the past, but we haven’t invested much time yet in seeing how we might use them to benefit Dedalus, so I think that would be a fantastic contribution to the project.  

I’m not sure how much you’ve already read about the code, but for a nominal simulation of resolution (Nx, Ny, Nz) with Nf fields, a typical timestep currently consists of (a few)*Nf spectral transforms (FFTs) and MPI all-to-all calls to explicitly evaluate nonlinear terms in the equations via the pseudospectral method, and (Nx*Ny) independent, sparse, banded matrix solves of size (Nz*Nf), distributed over however many cores you’re using.  As a rule of thumb, we typically find that things scale well out to roughly 8 separate solves per core.

It would be really interesting to get a better idea of whether GPUs or coprocessors could help us out with the spectral transforms or the sparse matrix solves.  Most crucially, some of the bases we’re adding have transforms that can’t be done with an FFT, and instead require dense matrix multiplication.  This could likely become the bottleneck for many simulations, so it might be the most important thing to try to speed up, if possible.

Looking forward to hearing everyone’s thoughts!

Best,

-Keaton

--
You received this message because you are subscribed to the Google Groups "Dedalus Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dedalus-dev...@googlegroups.com.
To post to this group, send email to dedal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dedalus-dev/0e037f23-5181-4dc0-afcd-888fc1cd7860%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Cameron Sajedi]

Hello Keaton and Company,

Nice to meet you, I am sorry it has taken me so long to reply, I am traveling for a few months, so progress from me may be out of pace with your development schedule.  I have been doing some reading on GPU parallelization of spectral transforms, and I will implement some codes as I get the feel for it. If you've got any reading suggestions, I am sure they will help me get up to speed efficiently. 

Regards, 

Cameron

[Cameron Sajedi]

Hello, 

I have been reading about the workings of Dedalus and I realize that the developers must have a way to talk to eachother. Is there a slack channel or something like an IRC? I'd love to join in, if there is one.

Best!

Cameron

[Jeffrey S. Oishi]

Hi Cameron,

No, we don't have IRC or slack. Typically, we communicate primarily via email, with the occasional Google Hangout. Maybe we should think about getting a slack channel...

Jeff

To view this discussion on the web visit https://groups.google.com/d/msgid/dedalus-dev/b9e522af-e97a-4032-b536-0ee2eec8460d%40googlegroups.com.