Installtion

1. Unpack the archieve at a convenient location. The necessary directory structure is created as a result. Have a look into the lib directory and you'll find that both 32 and 64 bit versions of the libIsles are present in this directory. Based on your system architecture, copy the relevant binary as lib/libIsles.a which is the one that is linked during a make.

2. The libraries and some example binaries will be there in the lib and bin directories. However, it is safer to issue make cleanall to remove the older object files, libraries and binaries.

In order to remove binaries related to a specific application, a command similar to the following may be issued
make -f src/Applications/MakeExampleDev clean
In order to remove all binaries related to all applications, issue ./CleanApplications

4. In a similar manner, individual examples or several of them can be tried out.

Since the former uses gcc and the latter g++, it is better to clean the directories of old binaries by issuing a make cleanall or a ./CleanApplications.

Please note that when being invoked from Garfield, no init-file is used and all the parameters are passed to neBEM via parameters. For details, please check the Garfield help files:
(http://consult.cern.ch/writeup/garfield/help/).

The init-files, when present and relevant, provide certain default values to carry out the computations using neBEM for any given problem. It even allows control over the phase in which the computation is started. For example, if only a new post-processing is necessary for a device that has already been solved for a specific electrostatic configuration and whose charge densities have been saved, it is possible to change the flags related as NewModel=0, NewMesh=0, NewBC=0, NewPP=1. It is necessary to maintain the correct counters for these parameters so that the correct model, mesh, boundary conditions are used for the necessary post-processing. One initialization file is usually maintained for each application and they are expected to be stored in $HOME/.neBEMv<version number>/<ApplicationSpecific>.init This default behaviour can surely be modified by editing the interface file specific for an application. If an initialization file is not found, the computation is carried out by the parameter-set defined in the neBEMSetDefaults function. So, after the files are unpacked and before you start executing neBEM, it may be useful to create a directory $HOME/.neBEMv<version-counter> and copy the initialization files from InitFiles to that directory. If necessary, keep a copy of older initialization files.

In the following table, we have explained in brief the different parameters that may be controlled using the init files:

Parameter	Explanation
`MinNbElementsOnLength`	Minimum number of elements allowed along the length of a primitive.
`MaxNbElementsOnLength`	Maximum number of elements allowed along the length of a primitive.
`ElementLengthRqstd`	Preferred length of the side of an element. neBEM tries to adapt to this
	but is over-ridden by the minimum and maximum number of elements.
	A log is maintained in `MeshLog.out` file.
`LengthScale`	Specifies the length scale to be used during a given computation. This can be useful
	to maintain accuracy of solution for problems very small or very large.
`New or old?`	These parameters, including the accompanying counters have been described below.
`DeviceOutDir`	Output directory. Internal subdirectories are created
	by `neBEM` automatically within this directory.
`OptDeviceFile`	`1` implies that the user will specify the device
	by means of input files - useful for stand-alone applications.
`DeviceInputFile`	User specified input file. Check stand-alone applications
	described below.
`OptPrint(s)`	Determines the level of terminal outputs.
`OptGnuplot(s)`	Determines whether files are to be maintained
	for use with the `gnuplot` routine.
`OptPrimitiveFiles`	Determines whether files describing the primitives are to be stored.
`OptElementFiles`	Determines whether files describing the elements are to be stored.
`OptReuseDir`	Determines whether the output directories are allowed to be overwritten.
`OptInvMatProc`	Procedure to be adopted for inverting the influence matrix (0 or default: LU, 1: SVD).
`OptValidateSolution`	Whether a cross-check on satisfaction of boundary conditions is done (XChk.out).
`OptForceValidation`	Whether cross-check is forced, if needed by recomputing influence matrix (XChk.out).
`OptStorePrimitive`	Determines whether primitive details are stored.
`OptStoreElements`	Determines whether element details are stored.
`OptStoreInflMatrix`	Determines whether the influence matrix is stored.
`OptStoreInvMatrix`	Determines whether the inverted matrix is stored.
`OptFormattedMatrix`	Determines whether files are stored in formatted mode.
`OptUnformattedMatrix`	Determines whether files are stored in unformatted mode.
`OptRepeatLHMatrix`	Determines whether the influence matrix computations are
	to be repeated in order to validate solution.
`OptSystemChargeZero`	Determines whether the total charge of the system is
	to be made zero. This usually means addition of a
	voltage shift throughout the device.

Note that the parameter NewBC is of special importance. If this parameter is set to 1, while maintaining NewModel = NewMesh = 0, it is assumed that we are delaing with the same geometry and discretization, while having a different boundary condition. The inverted matrix from an earlier calculation (where NewModel and NewMesh were equal to 1) needs to have been stored for this to proceed. In such an event, the inverted matrix is read in, and the solution for the relevant boundary condition is easily and very quickly obtained. This can save an enormous amount of time, especially for a complex device for which generartion of the influence matrix, as well as its inversion is of significant computational expense. Through Garfield, this is achieved by invoking parameters such as new-model, reuse-model, keep-inverted-matrix (please see relevant portion of the Garfield manual).