The default tolerance for the dR/dz solver (LMPParams().integrationparams.tolerance) is currently 1e-8. However, the tolerance used by the GRPF algorithm (currently default at 1e-5) dominates the affect of the differential equation solver tolerance when it comes to identifying eigenangles. In fact, even an integration tolerance of 1e-3 finds the same modes as a tolerance of 1e-10, but is more than a factor of 2 faster. Sometimes 1e-3 results in instabilities, so a default tolerance of 1e-4 or 1e-5 should be used instead.
Additionally, findmodes currently performs filtering of the candidate modes by 1) uniqueness of the modes to some tolerance and 2) closeness of the mode condition to 0. However, it appears that there is rarely (never?) a need to remove any modes based on 2 (GRPF takes care of this correctly). In fact, it appears that valid modes are unnecessarily removed for nearly any waveguide scenario with the current settings. This filtering should be removed.
In a test of 30 random waveguides there were not any duplicate modes either, but I know in earlier versions of LMP this occurred. To some extent, it is down to the user to ensure the tolerances on GRPF and integrationparams and appropriate (if the tolerance of the mode finder is too small relative to the integration tolerance, identical modes may be identified).
This is breaking because propagation results will change.
The default tolerance for the dR/dz solver (
LMPParams().integrationparams.tolerance
) is currently1e-8
. However, the tolerance used by the GRPF algorithm (currently default at1e-5
) dominates the affect of the differential equation solver tolerance when it comes to identifying eigenangles. In fact, even an integration tolerance of1e-3
finds the same modes as a tolerance of1e-10
, but is more than a factor of 2 faster. Sometimes1e-3
results in instabilities, so a default tolerance of1e-4
or1e-5
should be used instead.Additionally,
findmodes
currently performs filtering of the candidate modes by 1) uniqueness of the modes to some tolerance and 2) closeness of the mode condition to 0. However, it appears that there is rarely (never?) a need to remove any modes based on 2 (GRPF takes care of this correctly). In fact, it appears that valid modes are unnecessarily removed for nearly any waveguide scenario with the current settings. This filtering should be removed.In a test of 30 random waveguides there were not any duplicate modes either, but I know in earlier versions of LMP this occurred. To some extent, it is down to the user to ensure the tolerances on GRPF and
integrationparams
and appropriate (if the tolerance of the mode finder is too small relative to the integration tolerance, identical modes may be identified).This is breaking because propagation results will change.