Need FluidKernelFFT type

[Jacob Hinkle]

Currently our program code has stuff like this:

if mType == ca.MEM_HOST:
    self.diffOp = ca.FluidKernelFFTCPU()
else:
    self.diffOp = ca.FluidKernelFFTGPU()

This is needlessly verbose, and actually can confuse the python parser if you compile without cuda support so that ca.FluidKernelFFTGPU does not exist.

Instead we need a higher level object like we have with Image3D and Field3D, so we can instantiate the same as in those cases:

self.diffOp = ca.FluidKernelFFT(grid, mType)

[Jacob Hinkle]

It might also be possible to make this use the memory manager. The only quirk is that we need contiguous memory, and twice as much of it as we do for a normal image. Since the memory manager works in image sized chunks that might be a little bit tricky.

[Sam Preston]

(Reply via [e-mail]):

This should probably be done in the C++ code, just make a wrapper object which holds a pointer to FluidKernelFFTInterface and allocates either a FluidKernelFFT<EXEC_CPU> or FluidKernelFFT<EXEC_GPU> based on whether we ask for a MEM_HOST or MEM_DEVICE object. This will also need to be done for all the external classes in alg, they all require this if/else syntax in python right now.

On Mon, Feb 18, 2013 at 7:26 PM, Jacob Hinkle

[Jacob Hinkle]

Cool. While we are at it, we might add grid, alpha, beta, gamma and divergenceFree to the constructor.

[Jacob Hinkle]

After talking w/ sam this afternoon, there's something we need to keep in mind. That is that the LUT gets generated only when the grid is set or changed. In particular, it is NOT updated when running setAlpha, etc. That's why it used to take the diffOpParam type and updating meant passing in the grid, etc. all at once. I'm not sure exposing setAlpha and friends individually is very useful, and is probably unsafe for casual users. I propose having a constructor with all parameters, and an updateParameters method that also takes all parameters with the grid required, and no defaults for lpow, divergencefree, alpha,beta,gamma either. This lets us still instantiate diffOp on one line, and should make us think twice if we reset parameters, to remind us it's going to recompute the LUT.

[Jacob Hinkle]

Since we are planning to deprecate the setAlpha method (and friends) I am wondering if it might be useful to have a macro that helps us keep track of these deprecated functions. I'm imaging I insert something like the following:

void setAlpha(float a) {
    DEPRECATED("FluidKernelFFT::setAlpha", 0, 03, "Setting diffOp parameters " +
        "should now only be done using the constructor or the setParams() " +
        "function")
    _mAlpha = a;
}

What does the DEPRECATED macro do you ask?

• If our version is less than 0.03 it simply prints the following warning:

WARNING: FluidKernelFFT::setAlpha is DEPRECATED and will be removed after
version 0.03.  Setting diffOp parameters should now only be done using the
constructor or the setParams() function.

• If the version is equal or greater than 0.03 it complains at compile time, and possibly refuses to compile, in order to remind us to actually remove it.

I think the macro itself would be pretty painless to write since we now have facilities for getting version numbers. I am just thinking it might be good to have functions not just disappear immediately, but hang around for say, one or two minor versions.

As an extra bonus this would let us put a link to the issue tracker or wiki with some more explanation so people aren't just bewildered when they're code starts breaking.

[Jacob Hinkle]

@jspreston does FluidKernelFFT actually need contiguous memory? If it just used 3 mempools then it wouldn't be a big deal to just pad every mempool in the memory manager that slight amount. Then the user codes a temporary managed diffOp object like so

import PyCA.Core as ca

diffOp = ca.ManagedFluidKernelFFT(grid, mType, alpha, beta, gamma)
diffOp.applyInverseOperator(velocity, momentum)
del diffOp

In fact if we structured it so that all Field3D objects used padded MemPools, we could just have FluidKernelFFT be a lightweight object that tests the capacity of the MemPools in a field then does the operation in place. Or better yet just make applyInverseOperator a static method. The downside is the slight memory increase from growing all our fields. the upside is not having to carry diffOp around.

[Jacob Hinkle]

On second thought, I just realized we need the LUT to be stored. OK this gets nasty because when we delete the managed operator it will delete its LUT. Then it becomes the memory manager's problem to hold on to kernel parameters, which could be messy. A possible approach would be to have a global diffOp, like how ThreadMemoryManager works. That would let us get around passing diffOps everywhere, and if it used ManagedField3D for temporary memory it would automatically be space efficient.

That might be a decent approach since we generally only use a single type of metric anyway, and since we already are initializing it when we pass it our parameters. Just something to think about, and maybe this thread can move to the mailing list, since the original issue is pretty trivial to address.