NEC-LIST: More on PowerStation 1.00

(This won't make much sense before reading my previous posting on this topic.
Hopefully, it will after.)

After some more experimentation I found that the reaction of PowerStation
1.00-compiled NEC-4.1 to the test file I posted varies with the parameters in
NECPAR.INC and with whether debug code is specified during compilation. In some
cases program operation seems normal but the output file is truncated at the
SOMS file creation point. There may or may not be an error message generated by
HANK12 at the end of the output file. A simpler test file gives the same result:

CM Test dipole
CE
GW 1,11,0.,-5.,10.,0.,5.,10.,.001
GE 1
FR 0,1,0,0,14.
GN 2,0,0,0,13.,.005
EX 0,1,6,0,1.,0.
RP 0,181,1,1000,90.,0.,-1.,0.,0.
EN

(Remember, SOMS.NEC or SOMD.NEC must be erased before running.)

Out of curiosity I tracked down the source of the error in PowerStation 1.00.
It's occurring in HANK12, at the line

   DZS=SQRT(DEL)/CABS(B-A)

and is caused by the previous operation

   B=SQRT(XLN)

With the new test file, the first execution of these lines occurs with XLN =
8.95+. XLN is a real variable, so SQRT(XLN) is also real. Here's the trap. B is
complex and the implicit conversion of the real number SQRT(XLN) to complex B
doesn't work right. B ends up with the value (0, 0), resulting in the crash.
Changing the line to

   B=CSQRT(XLN)

fixes the immediate problem. The DZS assignment works o.k. despite the fact that
variable DEL is real. This is probably because the real-complex conversion takes
place as a result of the division, leaving a complex number to be assigned to
complex B.

I'd be surprised if there weren't other traps like this in the NEC-4.1 code for
Microsoft PowerStation 1.00. The bottom line is to avoid using that compiler.
Get an update if you still can from Microsoft, or use a different compiler.

Roy Lewallen
Received on Thu Dec 19 1996 - 22:05:00 EST