Possible NEC2 bug
 

Hi,

I believe I have come across a possible bug in the original
NEC2 (nec2dx.f) program. It shows up in nec2c, my translation
of NEC2 from FORTRAN to C, as a segmentation fault when
running in Linux. In the original nec2dx.f it shows up as
an Array bounds violation fault if compiled with
gfortan -fbounds-check. In both cases of course the
programs crash. This happens when an input file specifying
a wire segment in contact with a patch and with the extended
thin-wire kernel (EK card) enabled:

CM --- NEC2 Input File created by xnec2c 0.9-beta ---
CE --- End Comments ---
GW 1 8 0.0 0.0 0.0 0.0 0.0 1.0 .003
SM 3 3 0.5 0.5 0.0 0.5 -0.5 0.0 0.0
SC 0 0 -0.5 -0.5 0.0 0.0 0.0 0.0 0.0
GE 0 0 0 0 0 0 0 0 0
EX 0 1 1 0 1.0 0.0 0.0 0.0 0.0 0.0
EK 0
FR 0 11 0 0 50.0 5.0 0.0 0.0 0.0 0.0
XQ 0 0 0 0 0 0 0 0 0 0
EN 0 0 0 0 0 0 0 0 0 0

The fault is due to an "illegal" value in the connections array
ICON2 where ICON2(1) in subroutine CMWW has a value of 10001.
This signals a connection of wire segment 1 to a patch and this
value is later used as an index to ICON2 itself causing an array
bounds violation, since ICON2 is dimensioned as 2*MAXSEG and
MAXSEG=1500 in this NEC2 version.

I don't think I am qualified enough to fix this bug so I wonder
if there is still an "official" maintainer of NEC2 and whether
it is possible to contact him with the above bug report.

Possible NEC2 bug
 

"neok" wrote in message
oups.com...
Hi,

I believe I have come across a possible bug in the original
NEC2 (nec2dx.f) program. It shows up in nec2c, my translation
of NEC2 from FORTRAN to C, as a segmentation fault when
running in Linux. In the original nec2dx.f it shows up as
an Array bounds violation fault if compiled with
gfortan -fbounds-check. In both cases of course the
programs crash. This happens when an input file specifying
a wire segment in contact with a patch and with the extended
thin-wire kernel (EK card) enabled:

CM --- NEC2 Input File created by xnec2c 0.9-beta ---
CE --- End Comments ---
GW 1 8 0.0 0.0 0.0 0.0 0.0 1.0 .003
SM 3 3 0.5 0.5 0.0 0.5 -0.5 0.0 0.0
SC 0 0 -0.5 -0.5 0.0 0.0 0.0 0.0 0.0
GE 0 0 0 0 0 0 0 0 0
EX 0 1 1 0 1.0 0.0 0.0 0.0 0.0 0.0
EK 0
FR 0 11 0 0 50.0 5.0 0.0 0.0 0.0 0.0
XQ 0 0 0 0 0 0 0 0 0 0
EN 0 0 0 0 0 0 0 0 0 0

The fault is due to an "illegal" value in the connections array
ICON2 where ICON2(1) in subroutine CMWW has a value of 10001.
This signals a connection of wire segment 1 to a patch and this
value is later used as an index to ICON2 itself causing an array
bounds violation, since ICON2 is dimensioned as 2*MAXSEG and
MAXSEG=1500 in this NEC2 version.

I don't think I am qualified enough to fix this bug so I wonder
if there is still an "official" maintainer of NEC2 and whether
it is possible to contact him with the above bug report.

A quick check of the NEC 2 manual indicates the SC card
does not appear to be supported. It does not run with
my NEC2 program, but works fine in NEC4.

I am sure Gerry Burke at LLNL would be glad to help you.

Regards,

Frank

Possible NEC2 bug
 

On Oct 30, 12:29 am, "Frank's" wrote:
A quick check of the NEC 2 manual indicates the SC card
does not appear to be supported. It does not run with
my NEC2 program, but works fine in NEC4.

Well it is, it has to be since its the only way to input data
for anything but a random shaped patch. It works for me
here anyhow. It doesn't work on its own though, has to
follow an SP card.
I am sure Gerry Burke at LLNL would be glad to help you.

I managed to find an email address I could reach him eventually,
hope he can have a look at this, it may be in the NEC4 code as
well.

Thanks for your input and 73's

Neoklis

Possible NEC2 bug
 

A quick check of the NEC 2 manual indicates the SC card
does not appear to be supported. It does not run with
my NEC2 program, but works fine in NEC4.

Well it is, it has to be since its the only way to input data
for anything but a random shaped patch. It works for me
here anyhow. It doesn't work on its own though, has to
follow an SP card.

I should have looked more carefully. I found it on page 30
under details for the SP card. Strange, but my NEC-Win Pro
does not recognize SC. When I attempt to run your code
I get the following error message in the NEC output file:
"NUMBER OF WIRE SEGMENTS AND SURFACE
PATCHES EXCEEDS DIMENSION LIMIT".

You could also try to contact LB Cebik for help at:
www.cebik.com

73,

Frank

I am sure Gerry Burke at LLNL would be glad to help you.

I managed to find an email address I could reach him eventually,
hope he can have a look at this, it may be in the NEC4 code as
well.

Thanks for your input and 73's

Neoklis

Possible NEC2 bug
 

Frank's wrote:

I am sure Gerry Burke at LLNL would be glad to help you.

See: http://www.robomod.net/mailman/listinfo/nec-list

Arie.

Possible NEC2 bug
 

"Arie" wrote in message
ups.com...
Frank's wrote:

I am sure Gerry Burke at LLNL would be glad to help you.

See: http://www.robomod.net/mailman/listinfo/nec-list

Arie.

Thanks Arie. I subscribe to the nec-list, so saw Gerry's reply.

Frank

Possible NEC2 bug
 

On Oct 30, 8:01 pm, "Frank's" wrote:
I should have looked more carefully. I found it on page 30
under details for the SP card. Strange, but my NEC-Win Pro
does not recognize SC. When I attempt to run your code
I get the following error message in the NEC output file:
"NUMBER OF WIRE SEGMENTS AND SURFACE
PATCHES EXCEEDS DIMENSION LIMIT".

This is very likely to do with the bug I reported. Gerry has now
verified
it is a bug and provided me with a fix. I don't know what he intends to
do now to notify vendors and users but this bug never showed all these
years because the input that causes it (wire connected to a patch and
EK
card used) is not a useful case.

73's

Neoklis 5B4AZ

Possible NEC2 bug
 

"neok" wrote in message
oups.com...


On Oct 30, 8:01 pm, "Frank's" wrote:
I should have looked more carefully. I found it on page 30
under details for the SP card. Strange, but my NEC-Win Pro
does not recognize SC. When I attempt to run your code
I get the following error message in the NEC output file:
"NUMBER OF WIRE SEGMENTS AND SURFACE
PATCHES EXCEEDS DIMENSION LIMIT".

This is very likely to do with the bug I reported. Gerry has now
verified
it is a bug and provided me with a fix. I don't know what he intends to
do now to notify vendors and users but this bug never showed all these
years because the input that causes it (wire connected to a patch and
EK
card used) is not a useful case.

73's

Neoklis 5B4AZ

Interesting, thanks Neoklis. Since NEC 4 ignores the EK card I guess
it explains why it runs without error.

73,

Frank (VE6CB)