Bug in PFTFile and EMTPFTFile when using scuff-scatter with multiple incident fields

[DAWardle]

In scuff-scatter, power, force, and torque data can be requested using any of the options:
--PFTFile MyGeometry.PFT
--EMTPFTFile MyGeometry.EMTPFT
--OPFTFile MyGeometry.OPFT
--DSIPFTFile MyGeometry.DSIPFT
I have only observed the bug reported here with the --PFTFile and --EMTPFTFile options and only in scattering problems in which fields are added to make the incident field (using the --OPFTFile and --DSIPFTFile options, or using a simple incident field, things seem to work OK).

I am running scuff-em under Docker in Windows (Windows 10 and Docker Desktop version 3.3.3).

I am running the Mie Scattering example and focusing on the absorbed power reported in the PFT file (from here on, this refers to either the PFTFile or the EMTPFTFile) at a frequency of 0.1.

In the example, the incident field is specified in the Args file using:
pwDirection 0 0 1
pwPolarization 1 0 0

(I will refer to this as ArgsWhole) and the resulting PFT file gives 1.4e-07 for the absorbed power which matches the Mie Scattering prediction.

The incident field can be equivalently specified:

• In an Args file as:
  pwDirection 0 0 1
pwPolarization 0.5 0 0
pwDirection 0 0 1
pwPolarization 0.5 0 0
  (which I will refer to as ArgsSplit).
• In an IFFile as:
• PWwhole PW 0 0 1 1 0 0
  (which I will refer to as IFFwhole).
• In an IFFile as:
  PWsplit
PW 0 0 1 0.5 0 0
PW 0 0 1 0.5 0 0
END
  (which I will refer to as IFFsplit).

ArgsWhole and IFFwhole are scattering problems with one incident field. ArgsSplit and IFFsplit are scattering problems with two incident fields (which happen to add to the one incident field in ArgsWhole and ArgsSplit).

Using recent versions of scuff-em, I find the absorbed power for IFFwhole and ArgsWhole match, but the absorbed power for IFFsplit and ArgsSplit are -2.140576e-07 (i.e. they are not correct, and, being negative, not physically realistic). So there is a problem with the absorbed power when there are multiple incident fields.

Going back in time, the earliest commit I can find which behaves as I've just described is 4a7763f which dates from August 28, 2016 (so the problem seems to have been present for a long time).

As far as I can tell, the IFFile was introduced into scuff-em sometime in the year 2016. The most recent commit I can find in which the absorbed power of ArgsWhole and ArgsSplit match each other and also match the Mie scattering theory (so the PFT files appear correct even with multiple incident fields) and for which specifying an IFFile results in an error (error: stdin:7: unknown option --IFFile (aborting)) is c2dd22d which dates from January 24, 2016 (so this is a sensible commit to use if you want to use PFTFile or EMTPFTFile in a scattering problem involving multiple incident fields).

I only tried a small proportion of the commits between c2dd22d (Jan 24, 2016) and 4a7763f (Aug 28, 2016), mainly selecting those with a green tick mark. All of those I tested either had errors when Docker tried to build them or, when I ran them, either produced no PFT file, or produced a PFT file where all entries were zero (very small numbers of order 10^(-310) being interpreted as zero). In other words, they had other problems.

I can work around this bug because I can either use my Docker image of c2dd22d
or --OPFTFile / --DSIPFTFile options. I point out the bug in case it trips up other users and to help others who might be able to fix the bug (I don't have the required expertise to do that).

[texnokrates]

Hi David, thank you for looking into this. Actually I encountered some nonphysical absorptions myself but never had the time to debug it further or even to open an issue.

And IIRC, periodic systems in SCUFF-EM seem to be completely broken.

It would be super cool to have these things working. I think that the frequency-domain integral methods such as BEM or multiple-scattering T-matrix methods (some self-promo here) have a great potential and are extremely underrated in the photonics and radio communities (and can be combined together!).

However, the implementations (including SCUFF-EM) are typically

1. written by physicists or mathematicians without proper software development training / knowledge about best practices etc.,
2. written in rush and without proper testing, because in academia you don't get credit/funding for taking the time for writing high quality software – you need rEsULTs and pUbLiCaTiOnS and you always need them now or tomorrow at latest.

Been there, done that.

So in the end, instead of having high quality open source implementation of efficient methods, research groups use commercial implementations of often inferior methods – paying in aggregate much more that would be needed to create and maintain the proper OSS implementation of the better method.

SCUFF-EM with some refactoring, proper unit tests and rewriting into clean modern C++ (now the code looks like from the nineties and has some heavy FORTRAN smell) would be a great piece of software... I think that (and maybe even with some cool new features) would be doable with some 100k€ budget, which would be totally worth it in my opinion, saving thousands of mandays of poor PhD students and others trying to debug the current code.

However, getting a bunch of research group leaders to chip in from their budgets sounds like an utopic scenario (tragedy of the commons). Getting the funds from some public funding programme – good luck with finding a call that would fit.

I guess it's just better for them to spend millions of taxpayers' money in total on a crappy commercial FDTD software because that's what they always have done and what everybody does, right? 🤷

Sorry for the rant, couldn't help myself. 😃