
This folder contains source code and executables for the NEC2D variant posted by Jos. Bergervoet
and further modified as follows:
    (1)The source code for NEC2D was translated to FORTRAN 95.
    (2)ALLOCATABLE arrays replace all but one named common block in NEC2D.
          This allows a single executable to be used for an arbitrary number of segements and 
          patches.
    (3)An 'SZ' card was introduced to pass information to the program regarding the size of 
          the interaction matrix and associated arrays. (See below)
    (4)Various variables and arrays were declared of a changed type to avoid compiler warnings.
          These involved coercions like  REAL*8= CHARACTER*3 etc.

Nec2d_Me.exe uses the standard NEC input 'deck' EXCEPT that an 'SZ' card must follow the 'CE' card.
====================================================================================================
      The format for this card is: SZ  NO. OF SEGEMENTS, NO. OF PATCHES,
      For example : SZ  200,0,     (SZ must be upper case)

NOTE: Only the combination NEQS=[(NO. OF SEGEMENTS) + 2*(NO. OF PATCHES)], which is the number of 
      linear equations to be solved, is actually used to set the various array sizes. For situations
      that use the NGF (Numerical Green's Function) option NEQS must be double the size of the 
      original geometry specification from which the NGF file was written.

NOTE: The executables were compiled with Leahy LF95 PRO Ver. 5.6 and targeted to Pentium Pro,
      Pentium II, Celeron and Pentium III processors. They will not execute on earlier platforms.
      The .exe files are WIN32 executables (not extended DOS) and open in "Windows Console
      Mode." (Looks like a DOS box, walks like a DOS box, quacks like a DOS box) However, they
      will run only on a 32 bit Windows OS. (Windows 95, 98, NT4, 2000, Me)

NOTE: The two executables must reside in the same folder. somnec2d.exe puts its output files
      SOM2D.NEC and SOM2D.OUT in the folder in which it resides; but NEC2D_Me.exe expects these files
      in its folder.

NOTE: The free RAM required to avoid the use of virtual memory is about (16*(NEQS**2) + 1.0E6)
      bytes where NEQS= (NO. OF SEGEMENTS) + 2*(NO. OF PATCHES). The program will run as long as
      the total real plus virtual memory exceed this amount ---BUT--- the use of virtual memory
      will result in painfully long execution times.

NOTE: If the program crashes check the output file for a diagnostic message.

NOTE: The function of the optional last field on a GM (geometry move) card is unclear in both
      the .pdf and HTML on-line versions of the NEC USER'S GUIDE. It's action is as follows.
      The last field is entered as a floating point number, say, 7.0. The program adds 0.5 to
      this number and then truncates the result to an integer, in this case 7. The statements in 
      the geometry specification section of the input deck are scanned in order until a tag
      number of 7 is found. That geometry element and ALL those up to the GM card are "moved"
      according to the data on the GM card. This occurs regardless of the numerical sequence 
      of the tag numbers. If the tag numbers occur in the order 1,2,199,40,5,8,7,10,3,GM in the
      above example then elements 7,10 and 3 are moved as required.

NOTE: LF95 is a lot less forgiving of "invalid array references" than F77. I believe I have
      corrected all of these errors but may have missed some due to the effort required to 
      exercise all the options in NEC2D. Please bring such occurances to my attention.

                        ************ joe_lastovka@yahoo.com ******************