To implement loop tiling, the 3D space must be broken into independent tiles according to the data dependencies of the FDTD kernel. Thus, each tile must be "self-contained" without the need to access field coordinates outside the cell - There should be no "spooky action from a distance".
However, some openEMS engine extensions break this assumption:
| Engine | Compatible |
|---|---|
| engine_ext_cylinder.cpp | No? |
| engine_ext_cylindermultigrid.cpp | No? |
| engine_ext_dispersive.cpp | Yes |
| engine_ext_excitation.cpp | Yes |
| engine_ext_lorentzmaterial.cpp | Yes |
| engine_ext_mur_abc.cpp | ? |
| engine_ext_steadystate.cpp | ? |
| engine_ext_tfsf.cpp | ? |
| engine_ext_upml.cpp | Yes |
Conclusion: The top priorities are engine_ext_excitation, engine_ext_dispersive,
engine_ext_lorentzmaterial and engine_ext_upml, which are necessary for basic
simulations. Fortunately it seems that they all can be converted relatively
simply.
Mur ABC is problematic and I still need to analyze its code to determine the feasibility of conversion. So ironically UPML may have better performance than Muc ABC in in the future for a while. Not really a problem though.
engine_ext_steadystate and engine_ext_tfsf are low priority tasks. I didn't
spend time to analyze engine_ext_steadystate yet... TFSF's comment says it's
unsafe to run under MPI, so it may be unsafe to run under loop tiling too...
FDTD in cylindrical coordinates is a challange.