We currently evaluate flamelet right-hand sides and Jacobian matrices by iterating over mixture fraction points and calling into reactor-style thermo/kinetics handlers. Early prototyping showed significant speedup by rewriting these calls in a way that the compiler can vectorize. We should focus on flamelet performance, as 1D and 2D flamelet models are far more expensive than reactor models and are really becoming the primary production usage. Ideally we can avoid duplicating code across reactors and flamelets without hurting performance of reactors too much.
Kokkos would be nice for this, as the optimal data layout may change when large mechanisms are used (more species than grid points). One day this may also support threading/GPUs without major changes to Griffon. A surprising little issue here is that Kokkos may require cmake 3.10+, for which conda may not provide a simple installation.
We currently evaluate flamelet right-hand sides and Jacobian matrices by iterating over mixture fraction points and calling into reactor-style thermo/kinetics handlers. Early prototyping showed significant speedup by rewriting these calls in a way that the compiler can vectorize. We should focus on flamelet performance, as 1D and 2D flamelet models are far more expensive than reactor models and are really becoming the primary production usage. Ideally we can avoid duplicating code across reactors and flamelets without hurting performance of reactors too much.
Kokkos would be nice for this, as the optimal data layout may change when large mechanisms are used (more species than grid points). One day this may also support threading/GPUs without major changes to Griffon. A surprising little issue here is that Kokkos may require cmake 3.10+, for which conda may not provide a simple installation.