[FLASH-USERS] PFFT Usage Independent of Poisson Solver

[Klaus Weide]

On Tue, 16 Feb 2016, Jason Galyardt wrote:

> Dear FLASH Users,
> 
> Does anyone know of a convenient way to use the PFFT utility independent of
> a Poisson solver? I would like to use it to set up a Gaussian random
> density field in the initial condition similar to what one might do for a
> cosmological simulation (but without the actual Cosmology unit).

I have used the Pfft code in the past for implementing a 3D convolution, 
in order to smear a given UNK variable. That code was for internal use, 
not ready for release; but let me know if you want to have a look at the 
Grid_convolve.F90 I wrote and some modified Pfft routines. Maybe you can 
figure out how it worked, and derive something useful for you from it.

I know of others who have done a similar thing.

> Looking at the FLASH 4.3 code, it seems like this is *almost* possible. The
> Config file in Grid/GridSolvers/Pfft/ specifies a default Poisson solver
> (DirectSolver) such that if I include the Grid/GridSolvers/Pfft unit in my
> simulation, I'm forced to include a Pfft-based Poisson solver. This is
> actually a problem, since I would much prefer to use the BHTree Poisson
> solver that I've been using for awhile.

The secret to establishing a priority between the different instances of 
Grid_solvePoisson.F90 lies in the CHILDORDER directive in the file

  source/Grid/GridSolvers/Config .

All you should have to do is add BHTree anywhere AFTER Pfft on the 
CHILDORDER line.

(If this turns out to be generally useful, we might add this for the next 
release.)


> (Developers: it might make sense to move the Pfft implementation out of the
> Grid unit, perhaps to numericalTools.)

The main reason why some given code is part of the Grid unit: The code 
uses variables and data structures directly that are private to the Grid 
unit.  That includes, in particular, internal data owned by PARAMESH (like 
the UNK array itself, etc).

There may be some code in the GridSolvers subunit to which this does not 
apply; or which could easily be changed so that it doesn't depend on 
direct access to Grid data - by replacing direct references with calls
to accessors like Grid_getBlkPtr, Grid_getBlkRefineLevel, other 
Grid_getSomething that are part of the official API of the Grid unit,
and similar changes. On the one hand, such changes could affect 
performance. On the other hand, frankly I don't see us taking on
a reorganization like that anytime soon, perhaps unless there
are clear benefits like enabling important new functionality.

With that said, if you have a proposal of concrete changes in the form of 
a patch against FLASH 4.3_release that works, I am certainly willing to 
look at it :)

Klaus