neBEMGetPrimitive gives the details of the of the primitives as is evident from the name of the function. We pass the primitive number for which we want the details. The details of this interface primitive are returned in terms of number of vertices, coordinates of these vertices, the direction of the out-going normal, volume reference number referring to itself and that referring to the external medium.
Next, the neBEMVolumeDescription function is invoked twice for each primitive in order to get various important information such as the shape, material, relative dielectric permittivity, potential, charge density and finally the type of boundary. Based on the type of boundary on both sides of a given interface, an interface type for a given primitive is determined. The allowed boundary and interface types and their respective integer values are shown in the following lists:
| BoundaryType | Value |
| Vacuum | 0 |
| Conductor at specified potential | 1 |
| Conductor with a specified charge | 2 |
| Floating conductor (zero charge, | 3 |
| perpendicular E) | |
| Dielectric interface (plastic-plastic) | 4 |
| without "manual" charge | |
| Dielectric with surface charge | 5 |
| (plastic-gas, typically) | |
| Symmetry boundary, E parallel | 6 |
| (may not be necessary) | |
| Symmetry boundary, E perpendicular | 7 |
| (may not be necessary) |
| InterfaceType | Value |
| To be skipped | 0 |
| Conductor-dielectric | 1 |
| Conductor with known charge | 2 |
| Conductor at floating potential | 3 |
| Dielectric-dielectric | 4 |
In the same vein, we list the possible values of other variables: materials from 1 to 10 are conductors and from 11 to 20 are dielectrics keeping in tune with the Garfield code. shape (at present does not have much of an utility) can be 0 for vacuum or a gas, 2 for a wire, 3 for a triangular and 4 for a rectangular interface. In fact, the shape value reflects the shape of the interface rather than that of the volume. For a conductor, the potential is expected to be specified while the relative dielectric permittivity is usually needed for a dielectric material. Known charge distribution is also another possibility for both these types of material. We'll soon have the effect of space charge incorporated into the toolkit. There will be several ways of incorporating the effect of known charge distributions including the standard Particle-In-Cell (PIC) and the Particles-On-Surface (ParSue) model, recently proposed by us.
By periodicity of any primitive, we mean having it repeated at some other location in space besides the original one where it is initially defined. The repetition is carried out symmetrically on the positive and negative axes. The repetition is made first on Z, then Y and finally on X. The periodicity can also imply mirror reflections. The type of periodicity is determined from the i- parameters, while the number of repetition is obtained from the j- parameters. Finally, the distance at which the repeated image is to be constructed is decided by the s- parameters. As can be seen from the source code, each primitive can have a different amount of periodicity. On each of these repeated primitives, all the discretization details, boundary conditions on the elements, solved singularity distribution are assumed to be identical. Please note that the handling of repetitive structures (mirrored, or otherwise) is likely to undergo several modifications in the near future. This is especially true for repetitions other than those implying simple copies.
The number of elements into which the primitives are discretized is determined by the hints supplied by the user through the two-dimensional integer array passed as as argument to the neBEMDiscretize function. How the user decides on the number of elements depends entirely on the user. The meshing is carried out such that the larger element number is used for the longer side of a primitive. If we have a wire primitive, the first number is used for meshing. Please note that, although planned, no adaptivity has been built into the toolkit as yet.
At the end of this phase, files suitable for viewing the final geometry, primitive, elements is prepared and placed as the 1#1MeshDir2#2/GViewDir/gView.gp file. For viewing, the user needs to issue
gnuplot <MeshDir>/GViewDir/gView.gpat the command prompt. It is assumed that the gnuplot is installed in the machine on which the code based on the neBEM toolkit is being executed.
The neBEMBoundaryCondition function takes care of setting up the proper boundary conditions on each of the elements and usually would not require any user intervention. The information related to setting up of boundary condition is extracted from the volume files. As we have noted earlier, each interface is in between two volumes. If one of the volumes is made of conducting material, the interface turns out to be a conducting-dielectric interface. In such an event, the interface is likely to represent a conductor with known potential, or a floating conductor with zero total charge. If both the volumes on either side of an interface is dielectric in nature, the interface is considered to be a dielectric-dielectric interface. The boundary condition in such an event is the continuity of the normal component of the electric displacement vector. For interfaces with known charge distributions, no boundary condition is enforced on the elements and the effect of the known charge distribution is incorporated in a manner similar to the one described for space / volume charge distributions mentioned elsewhere.
Once the boundary conditions are set up, we can proceed to the most important and computationally expensive part of the solution procedure. From the user point of view, the work is, however, as simple as invoking the function neBEMSolve, after setting up the proper flags and counters. For the example under discussion, and most of the other examples in the archive at present, the problems are known to be static. This is the reason the invocation is done only once, and the variables related to time (TimeStep and EndOfTime have both been set to 3#3. However, for a dynamic problem being solved under the assumption of quasi-statics, there can be several invocation of the neBEMSolve function. If the device geometry, discretization and material properties remain unchanged, the matrix inversion step can be avoided that can lead to a huge saving computationally. In fact, this is one of the major advantages of BEM techniques. This has been illustrated in a very simple-minded modeling of an idealized plasma device where the positive and negative ions are moved randonly from one time step to another and the voltage on a floating conductor within the device is estimated at each time-step.
Even a static problem with a given geometry can be re-solved with a different boundary condition. In this case, a similar advantage can be extracted if the inverted matrix is stored. However, storing the inverted matrix may lead to a very large file. Moreover, to ensure that neBEMSolve takes advantage of the situation, the user will need to set-up the proper flags and counters if multiple invocations are made for the same device as mentioned above. For example, NewModel and NewMesh should be made equal to zero, ModelCntr and MeshCntr being kept at their previous values.
At the end of neBEMSolve, we are left with the singularity distribution on the elements. The array of Element structures is updated with the new values of singularity density and thus are completely defined in all respects. The Elements can now be used to evaluate any relevant property at any arbitrary location. In the present study, we have summed up the charges on all the elements to find out the total charge on the plate.
Finally, by using neBEMEnd, we end the use of the toolkit gracefully, that allows it to write to certain log files and save them properly.
In PostProcess/PlatePP.c, we can see how easily the total charge on the plate is obtained simply by adding the charge on each of the elements present in this simple device.
Finally, we need to create a Makefile suitable for this project. The easiest thing is to copy one of the existing ones in the Applications directory and change it according requirements. Only a very small number of changes is required usually if the directory structure as provided in the toolkit archive is maintained. The driver routine, the interface routine and the post-processing source and object codes need to be correctly mentioned. In addition, the binary file has to be given a suitable name.