[SOLVED] Dipole Array Simulation in 4NEC2

[kakar133]

Hello Everyone;
I am trying to simulate dipole array in 4nec2. There are two identical configurations for arrays.
In one configuration I put dipole array parallel to a ground plane (4 elements at y=0,x=3x1 and 4 elements at x=0, y=3y1). While in second configuration I used same array with only change in y co-ordinates (y=-3y1).
I was expecting two radiation pattern with only 90 degree phase difference between them.but in first case i am getting a zero which was not expected. I have attached the plots and code for it.
any suggestion for mistake.

Thanks


View attachment dipolearray-(XY_plane).txt
View attachment dipoleArray-(-XY-plane).txt

 

[Darktrax]

I have several NEC2 tools, but no direct experience of 4nec2 because the base PC is Linux based.
You have a Multiple Patch Surface (SM) but I do not yet know what is SC.

When things go wrong for me, it is usually because parts of the structure try to occupy the same space, or parts end up beneath the ground level.

With 4NEC2, the ability to have symbol variable, and functions in the value fields of GW input lines might be making values that you cannot see becoming unrealistic. Because I am curious, I have downloaded the files. If I get opportunity, I might try them in a Windows PC.

 

[kakar133]

I am using Surface patches as a ground plane to increase directivity in particular direction.

I have several NEC2 tools, but no direct experience of 4nec2 because the base PC is Linux based.
You have a Multiple Patch Surface (SM) but I do not yet know what is SC.

When things go wrong for me, it is usually because parts of the structure try to occupy the same space, or parts end up beneath the ground level.

With 4NEC2, the ability to have symbol variable, and functions in the value fields of GW input lines might be making values that you cannot see becoming unrealistic. Because I am curious, I have downloaded the files. If I get opportunity, I might try them in a Windows PC.

 

[Darktrax]

I am using Surface patches as a ground plane to increase directivity in particular direction.

Hi kakar133

That is OK, though I think you may need to check that no part of the patches extends into the ground if you still have a default ground also present.

It has also been shown that one can get reasonably accurate results by making reflectors out of a grid, generated by using the GM transformation command to generate repeats. The rules about keeping track of tag numbers, and how to avoid generating repeats are quite strict, and also quite awkward to keep in the mind. The rules about connections to the center of patches are similarly quite strict.

The original NEC2 and NEC4 were written in FORTRAN, which is near-assembly language, and a compiled version on a modern PC is extremely fast. Even though it had some programming tricks we now avoid, (like unconditional GOTO), it was rigorously debugged (by the US military), and also extensively verified with real structures. The modern usage, such as by 4NEC2, NEC4WIN, NEC2C and XNEC2C add front-ends to make data entry input easier, and run from file input of structure descriptions. Some have also translated from FORTRAN to C, C++ and possibly others. Some front-ends still call a compiled FORTRAN binary engine.
All of these variants may have added in some constraints of their own which might be hindering your input description.

My point here is that the original rules still generally apply. You might be able to get away with free form input strings, and it may be more tolerant of where you sprinkle comment (CM) inputs, or using //, or %, whatever, but allowing bits to occupy the same space, or ends not to connect still causes hard-to-understand crashes. Note that like all integral Equation solvers, the number of structure parts affects the computation time in a non-linear way. Since each element affects every other, to many bits can quickly expand the computation unreasonably.

A clean PDF version of the original old NEC2 manual is available online. A quick read of the introduction chapter might give you some clues as to what might be upsetting the design.

Another trick is to divide and conquer. Try offering only parts of the design in stages, by commenting out some lines. Leave out the patches entirely, and see if the remainder is accepted. When you get to the bit that crashes it, you will have a better idea of what to fix. Make sure the sequence of entry generates the thing you want. It is very easy to end up with parts of the structure displaced very far away if one is not careful.