new fluid solver
Task: rewrite algorithm from
vorticity_equation.cpp, but using the
vorticity_equation.cpp should not know anything about FFTW or other possible backends.
We need a clear procedure to decide whether or not this is a reasonable goal with respect to efficiency/scalability.
@bbramas, I will ask for help with this "procedure" after I address the first three immediate tasks below.
Immediate tasks as of commit 2253a792:
- test script
tests/test_vorticity_equation.pyshould check that the results obtained with the two different codes are identical to within numerical precision.
- timings should be placed throughout the
- the test code should also be able to handle particles; this can be achieved by simply passing the
get_rdata()pointers instead of
- figure out how to perform statistics with new code --- choose between direct translation of old statistics methods to the new class, or moving some functionality to the python class.
vorticity_equationcode should be able to use either binary I/O or HDF5 I/O (at the moment it's just binary).
fieldclass and related classes (
kspace) should be made consistent with the
field.?ppfiles should be split into three.
More general things to consider:
- some of the functionality from a solver might be better off as a method of the
fieldclass (for instance the computation of curls). In particular the
field.?ppfiles define a method for computing the gradient of a
fieldobject into another
fieldobject; what are the pro-s and con-s of such an approach?
- particle code should work directly with the
fieldclass (such that scalar/tensorial fields can be interpolated directly). There's an old
feature/field-interpolatorbranch that is addressed to this, and there's also the
hack/tensor-interpolationbranch that needs to be cleaned up.
@bbramas, please let me know if you can think of anything I missed in this plan.