S4 Home | Download | FAQ | Lua API | Developer information | Changelog
Vector field generation in pattern.c fails for large discretization sizes without CHOLMOD.
The iteration limit of the conjugate gradient solver may need to scale up faster at large grid sizes.
Crash on unknown material name in GetEpsilon.
There is no stringent checking to make sure all materials referenced in layers are defined. This needs to be fixed.
Incorrect results when using multithreading (SolveInParallel).
This is most likely an indication of a poorly compiled LAPACK library.
Make sure to compile LAPACK with no static variables. This means using
the -frecursive flag with gfortran, or else manually patching up the
functions which get called (mainly zgeev and its callees).
Vector field generation in pattern.c does not correctly handle shapes which have portions extremely far outside the unit cell.
Workaround: When defining shapes, do not allow the extent of the shapes to extend beyond the 8 neighbors of the real space lattice’s (origin centered) fundamental parallelogram.
Vector field generation in pattern.c currently does not support generating everywhere-normal fields with natural boundary conditions.
Proposal: Implementation of natural boundaries and interpolated source placement. Constraint computation should be similar to the tangential case, except cross products are taken with the pixel edges themselves.
Vector field generation in pattern.c currently fails silently or produces poor output on non-orthogonal lattices with substantially different basis vector length to sampling ratios.
Proposal: The problem is partially mitigated by the use of circular G-vector truncation; the length-to-sampling ratios will usually be approximately equal. Correctly supporting the general case requires generating a non-trivial implicit mesh for the fundamental parallelogram. The resulting sparse matrix system would then become substantially larger and the overall complexity of the field generation would be much greater. No attempt to fix will be made any time soon.
Dipole excitation source is not implemented in main.c and S4.cpp.
Proposal: Dipole sources require knowledge of (px,py,pz) instead of (hx,hy) in the planewave case. It may be possible to express the dipole as a set of tangential H field values. Further planning is needed.