PulseTLM is a more full featured 3D Transmission Line Matrix (TLM) simulator that is published under the GNU General Public License with an input language that allows a wide variety of EM systems to be solved without recompiling the simulator.  PulseTLM allows a variety of input (ex, ey, ez, hx, hy, hz) crossed with (impulse, sin, exp) sourcing and output (ex, ey, ez, hx, hy, hz, |e|, |h|) crossed with (viz, BoB, pnm, dat, grace, binary) display options.  This is currently in alpha stage, however has passed several canonical tests which are included in the package.  This is the simulation engine where the ideas, algorithms and  coding strategies tested in the Toy and ToyPlane variants will be integrated.

TLM is a full wave time-domain local-operator algorithm for solving Maxwell''s equations.  Don''t let the name fool you, in this situation ''Transmission Line'' is actually an abstraction that allows the set of coupled differential equations to be solved in a different manner.  This uniquely different manner has some very interesting properties which can be seen in the PulseTLM code. 

This alpha release should be functional for you, yet there are only spartan README files and simulation examples.  Expect more to come.  The code is well documented and should be adequate for the moment.

Contributing Authors

P. R. Hayes, H. G. Sasse


Added VTK OutputPulseTLM-0.2.6.tar.gz
ChangeLog PulseTLM-0.2.5.tar.gz
ChangeLog PulseTLM-0.2.2.tar.gz

Numerous tests are included in the package with MANY more coming, one quick way to start is run one of the test cases and study the results.  Once comfortable with the results, then copy the original test case and modify it to suit your current needs.  Note, that only MINIMAL INPUT CHECKING is performed currently.  If the input file is modified incorrectly, you may cause it to crash/core dump. Better input checking/parsing is on the calendar for development.

PulseTLM''s ''Language''

PulseTLM is fed by an input file of single line control statements.

Comments are allowed when preceded on the line by a pound sign, #.  The code actually disregards all lines that do not fit into the language specification.  However, to be safe, do not count on this.

The overall mesh dimensions are specified by the line

mesh 132 20 9
which should be the first operational line of the file.  Comments, of course, may precede since they are not operational.  This line tells the simulator that 132 voxels in the x direction, 20 voxels in the y direction and 9 voxels in the z direction should be allocated for this simulation.

The maximum number of iterations the simulation will run is specified by the line

maximumIteration 1003
where zero, 0, is assumed as the start and one, 1, is the first iteration.  This line tells the simulator that 1003 iterations in time should be performed.

The spatial deltas in each coordinate direction are specified by the lines

dx 0.00113333
dy 0.001145
dz 0.00113333
which specify the physical size of a modeling voxel, or 3D box, in each of the Cartesian directions.  These lines straightforwardly set the appropriate spatial delta.

The previous input lines should be the first operations ones in the input file.  The remaining input control statements may appear in any order and describe the geometry, boundary conditions, input , output and materials to the simulator.

Excitations are specified in a reasonably general form

excitation 1 1   1 20   1 9 ez sin 1.1 10.0e9 1.2e-9 0.00015
tells the simulator that from x voxels 1 to 1, from y voxels 1 to 20 and from z voxels 1 to 9 the ez field in each voxel should be set as a sine function of the following form
1.0 * sin(2.0*M_PI*10.0e+9*(t - 1.2e-9)) + 0.00015
>excitation iLow iHigh jLow jHigh kLow kHigh [ex, ey, ez, hx, hy, hz] [sin, exp1] k1 k2 k3 k4
where one of the field components to excite [ex, ey, ez, hx, hy, hz] must be chosen, one of the excitation functions [sin, exp1] must be chosen and the constants k1-4 must be set for the particular function chosen.  The Low and High values set the range of the excitation within the TLM 3D mesh of voxels.  This form allows a point excitation by setting the iLow = iHigh, jLow=jHigh and kLow=kHigh.  It allows a linear excitation if only one set varies, for example iLow = iHigh, jLow=jHigh and kLow<kHigh.  It allows planar and volumetric excitations with the other combinations.  It''s not perfect, but it gets quite a few input possibilities there.

Outputs are specified somewhat similarly to the excitations

output 20 20  10 10  5 5  ez dat 1
output 1 132  1 20  1 9  ez viz 100
The range operations are identical to excitations.  Both lines here specify output of the ez field component.  The first line output to a ''dat'' file which is an ASCII formatted file with each line containing the currentSimulationTime and the field component at that time.  This format is usefull when ''point'' ranges have been set.  The ''dat'' file then becomes an xy data file suitable for plotting in xmgr, xmgrace or other graphing packages.  The second line specified a viz formatted output set that contains a viz control file and all the requested BoB files.  The viz control file contains sizing information, scaling information for the real values of the field components (BoB being only bytes doesn''t contain any floating point range information.) and other relevant info for viz.  The last number on the output line is the modulo of the output which allows some measure of control on how much data is dumped out.  With ''dat'' files, size is really not much of a problem in 1D dumps.  With viz and BoB files, size becomes a problem VERY quickly so using modulo dumps of every 100''th iteration is quite valuable for saving disk space.

Being based on a transmission line analogy allows a unique strategy for specifying boundaries in the simulator.  Reflection and transmission coefficients identical to transmission line analysis or plane wave analysis may be set in the simulator as

rtxl 1 1   1 20   1 9 0.0
rtxh 132 132   1 20   1 9 -1.0

rtyl 1 132  1 1  1 9 -1.0
rtyh 1 132  20 20  1 9 -1.0

rtzl 1 132  1 20  1 1 -1.0
rtzh 1 132  1 20  9 9 -1.0

where the keyword, rtxl, indicates a rho-tau boundary at the x lower face of the voxels defined by the ranges 1 to 1 in x, 1 to 20 in y and 1 to 9 in z.  The applied reflection coefficient is 0.0 which indicates that this boundary has 0.0 reflections or is acting as an absorbing boundary.  The keyword, rtzh, indicates a rho-tau boundary at the z upper face of the voxels defined by the ranges 1 to 132 in x, 1 to 20 in y and 20 to 20 in z.  The applied reflection coefficient is -1.0 which indicates that this boundary has -1.0 reflections of the electric field or is acting as a perfect electric conductor (PEC).  The same point, line and plane philosophy can be applied to the range specification here which allows single voxel boundaries, linear voxel boundaries or planar boundaries.  Currently, the file format limits the planes to lie normal to one of the coordinate axes.  There is a workaround, though by specifying the single voxel boundaries over a stair stepped range.  A separate program could create the input file to PulseTLM.  This is primarily an input file limitation.

Generic points, lines, planes and boxes of voxels may be set to a material property with the following line

material 1 30 1 30 1 30 1.0 5.0 0.0
which sets the box (1-30, 1-30, 1-30) to relative permeability 1.0 and relative permittivity 5.0.  The last number is conductivity which is not currently implemented in the simulator.  Quite complex material systems may be created via Constructive Solid Geometry (CSG) which works in this case via overlays.  If you''re familiar with IC processing, you''ll recognize this one.  Add a line to the input file describing a material region comparable to laying a region of material on the wafer surface.  Add a line AFTER that line yet covering SOME of the same voxel regions.  The second line will overwrite the first lines material parameters in the overlapping region.  This is comparable to a deposit-etch cycle in IC processing.

This alpha release should be functional for you, yet there are only spartan README files and simulation examples.  Expect more to come.  The code is well documented and should be adequate for the moment.

Spartan page?  Well, it IS alpha source.  Consider yourself forewarned.  Check back again to obtain a upgraded release.  If you have ideas or possible upgrades, please send them in.