Python versus Perl

Our software is designed for integration into complex sequences controlled by external programs or scripts. This integration is facilitated by the following features:

  1. All our programs may be launched from the command prompt or may be called by other programs with pass parameters.
  2. Although the user interfaces are largely interactive, our programs feature input buffered through text scripts. These scripts may be created or modified by external programs, giving wide latitude for passive or active control loops.

Interpreter languages represent an efficient option for creating shells that call our programs and take care of global data organization. In previous posts (Automatic solution control with Perl and Making movies with the AMaze programs) I discussed the Perl language and gave examples of its application. After recently comparing notes with my son, I feel that Perl may not be the best choice. We both had similar problems as occasional Perl user. Returning to the language always seemed like starting at square zero. Its syntax and control structures are arcane, and the documentation is spotty. Perl would appeal to a computer scientist because it is clever and succinct. On the other hand, succinctness can be a curse to applied scientists and engineers. I often found that I could not understand Perl codes that I had written a few months earlier. Minimalist syntax might be useful for writing Forth programs on a ZX81, but it makes no sense in an age of cut-and-paste editors and terabyte hard disks.

My son suggested Python as an alternative. Like Perl, Python is available at no charge for Windows, Linux and Apple computers. As a test, I decided to see how much effort it would take to duplicate the movie-making script described in a previous post. The task proved to be relatively easy. I downloaded and installed the programs, read the introductory documentation and duplicated the function of the script in about 3 hours. Here is a link to down my resulting script (with a .txt suffix added to avoid download problems):

Phython example

These are the critical lines for launching our software from Python:

import subprocess
ProgName = "phiview"
ScriptPrefix = "pvscript"
...
Command = ProgName + " " + ScriptPrefix
subprocess.Popen(Command).wait()

They create the command line string “phiview pvscript” and then call the program as a subtask. The .wait() directive ensures that only one instance of phiview.exe runs at a time. In less than a minute, the script generates 100 graphics files showing the electrostatic potential distribution at different positions in the solution space.

In comparison to Perl, I feel that Python is the better choice for the occasional user working on applied problems for the following reasons:

  • Python syntax has more intuitive appeal. Special characters to denote data types (“$”, “&”, “@”,….) are not required. It is unnecessary to put a vestigial semicolon at the end of each line, a frequent source of error. I like the idea of defining control loops by indentation since it closely matches my style of programing in FORTRAN.
  • Python scripts may be run from an interpreter window. In this case, the script should have a name of the form fprefix.py. You can open the script with a built-in editor with syntax highlighting. A script is built by adding material and making changes in the editor and pressing F5 at any time to check the operation. Printed results and error messages appear in the interpreter window and the error position is marked in the editor. This simple arrangement is quite effective for building and debugging programs. When the script is complete, you simply rename it as fprefix.pyw. Then it can be run as a background task without opening a window.
  • Python has a comprehensive and well-organized help system that can be called directly from the interpreter. This makes it easy to find the structure of a control sequence, and easy to look it up again when you have forgotten it. In contrast, I had to buy two tomes from OReilly to get started with Perl. Long searches through the books were necessary each time I returned to the language.

You can get Python for Windows at http://python.org/download/. There is a question of whether to download Python 2.7 or 3.1.2. The latter is the development version with advanced features, The 2.7 version is still active and is compatible with many current resources available on the Internet. Considering that 2.7 has far more features than I would ever use, I decided to be conservative and use it. Installation is largely automatic. There are two operations you may need to do by hand:

  • Add a desktop icon to run the interpreter (c:\python27\pythonw.exe).
  • Add c:\python27 to your path. In XP, run the Control Panel. Run System and click on the Advanced tab. Click on Environmental variables, highlight the PATH variable and click on EDIT. Go to the end of the long string and add “;C:\PYTHON27″ (be sure to include the semicolon). Exit by clicking OKs. The modified path variable will not take effect until the next time you log in. It’s not necessary to restart the computer. Just Log Off the current user and log in again.

Improved 3D plotting

The generation of attractive and accurate three-dimensional views of meshes, particle orbits and calculated quantities was a challenge in creating 3D finite-element programs in our AMaze series. The standard approach to 3D graphics is to use a library like OpenGL where surfaces are approximated with the the minimum number of facets that provide a psychologically-satisfying sense of objects. This is the approach we used for the 3D modeling environment of the Geometer program. With a limited number of facets, the regeneration time is short enough for real-time animation effects.

In contrast, averaging techniques are not suitable for mesh and orbit plots in MetaMesh and the AMaze postprocessors. Generally users expect an exact representation of the physical system. It’s risky to allow the program to make decisions about discarding information. Therefore, we designed the programs to faithfully display all facets on region borders and all segments of charged particle orbits. The amount of information to define a surface may be 1-2 orders of magnitude larger than a typical OpenGL model. The  challenge is to produce effective 3D displays (with hidden surfaces and lighting effects) in a perceptually short time. In other words, graph regeneration of huge meshes should be a relatively painless experience for the user.

Over the years, we have steadily improved the appearance and operation of 3D technical plots in our programs. This month, we introduced bitmap transfer techniques that give a significant increase in speed. At the same time, the procedure ensures correct operation with Windows 7, even with advanced graphics themes. The picture shows the current 3D plot environment in MetaMesh. The mesh for the planar electron-beam gun includes 11 million elements.

MetaMesh screen: surface plot menu

MetaMesh screen: surface plot menu

♦ The user can move toward or away from the assembly (zoom and expand), walk around it toward the sides, top and bottom (rotations) or shift the view sidways or up-and-down (translations). The operations are controlled by the mouse with an active cursor (not shown in the picture) that changes shape according to the function. Individual regions may be displayed or hidden, and cutplanes may be added to view inside the assembly.

♦ Mouse actions are reflected in the animated orientation display at the top-right. To save time, the main plot is regenerated only when the mouse button is released. After a delay, the new view flashes to the screen. For standard meshes (~1 million elements), the regeneration delay is almost imperceptible. Depending on the number of regions displayed, the delay for huge meshes may be a second or two.

♦ The introduction of saved view parameter files further reduces time and effort with huge meshes. The user can restore a 3D view immediately, without repeating the operations necessary to construct it.

Saved views and the other 3D plot features will be included in the October update of the AMaze programs.

Making movies with the AMaze programs

A previous post described new graphics features planned for the AMaze series of programs. They will be included with the October 1 update. The motivation is the creation of animations (movies in AVI format). We are adding expanded capabilities to the initial-value solution programs and postprocessors to generate sequences of BMP plot files, either autonomously or under direct user control. Several types of animations are possible with the finite-element solutions:

  1. Showing the time evolution of calculated quantities in HeatWave (dynamic mode) and Aether (pulse mode).
  2. Generating a large set of solutions under script control to show the effect of parametric variations, either in geometry or material properties.
  3. Illustrating the three dimensional nature of a solution by a set of slice plots (walking through the solution space along an axis).
  4. Moving around a three-dimensional space to show complex objects.
  5. Following a slice in a 3D view of a solution space to show the variation of calculated quantities.

There are many other possibilities, giving free reign to the user’s imagination.

New dialog to initiate plot files

New dialog to initiate plot files

This post describes some recent, related developments. To begin, we have improved commands to generate graphics files of currently-displayed plots in the interactive environments of the AMaze postprocessors. The PLOTFILE command (which may be invoked from the PLANEPLOT, SLICEPLOT and SURFACEPLOT menus) brings up the dialog shown in the picture. The user supplies a unique file prefix and chooses the output format. The default BMP format is preferred because there is no loss of information and files may be incorporated directly into animations. The dialog gives common choices of image size. The user may also set a custom size by specifying the pixel dimensions. Depending on the resolution, the resulting image files may have considerably better quality than the screen display. Here is an example at 640×480 resolution:

Illustration created with the PLOTFILE command

Illustration created with the PLOTFILE command

A second development enables automatic generation of images under script control. As discussed in the previous post, we have added a new command to analysis scripts for AMaze postprocessors:

INPUT TARGET.HOU
PLOT PlotTest TargetPlot 1024 768
INPUT WALKTHRU.HOU
PLOT PlotTest WalkThruPlot 1024 768
ENDFILE

The first command loads the solution file TARGET.HOU. The second command creates a plot file TARGETPLOT.BMP with pixel dimensions 1024×768. The plot parameters are defined by the saved view PLOTTEST.FPV. The features of saved views in MetaMesh and the AMaze postprocessors were described in a recent post.

With the PLOT command, it is relatively easy to generate movies automatically. To illustrate, I wrote a Perl template to create the fifth type of animation listed above, a moving slice display of a electrostatic potential in a 3D solution space. Here is a link to the script: make_movie.pl.txt. The txt suffix was added to avoid download problems.

I built a sample movie from a HiPhi electrostatic solution with the following steps:

  1. Load the solution file in PhiView and experiment to define a good three-dimensional surface plot.
  2. Save the view as TEMPLATE.FPV. With an editor, change the numerical value of SurfacePlanePos to the marker “@”.
  3. Run movie_maker.pl to create 100 sequential BMP files. The Perl script walks along the z axis of the solution space, modifies the value of SurfacePlanePos in a temporary view file TEMP.FPV, writes a script that includes the PLOT command with the current BMP file name, and executes PhiView.
  4. Use CECIL_B to assemble the BMP files into an animation at 25 frames/second.

The whole process took a couple minutes. Here’s the finished product (I added the title and transition with Camtasia):

Case study of a high-current electron beam system

Three new tutorials are available in the technical library that describe design studies for a hollow-beam, high-power klystron. The documents include material of general interest to anyone interested in high-current electron beam technology.

In the case study, an annular electron beam with kinetic energy 100 keV and power 20 MW power is generated from an immersed cathode in a solenoid field of amplitude 0.1 tesla. The motivation for a hollow beam is to reduce the space-charge potential for a given current, and hence to minimize the longitudinal energy spread. The reduced-energy beam leaving the klystron is captured in a biased collector to recover power.

The following three documents are available in our technical library:

Electron gun design for a hollow-beam klystron using Trak
PerMag design of a focusing magnet for a hollow-beam klystron
Trak design of a single-stage collector for a hollow-beam klystron

Some of the technical issues discussed:

  • Design of a hollow-beam gun with no internal anode structure to generate the required current at the operating voltage. Two goals are to minimize 1) the electric field stress on the surface of the focusing electrode and 2) the transverse spread energy of the extracted beam.
  • Requirements on magnetic field uniformity for transporting a hollow beam. Determining coil currents in a finite-length solenoid to maximize the field uniformity and the length of the good-field region. Discussion of the role of shielding iron to improve uniformity and to minimize the drive current.
  • Review of the energetics of biased collectors in electron beam systems for microwave generation. Concepts for electrostatic collectors in a region of expanding magnetic field. Determining energy efficiency and properties of reflected electrons.
Annular-beam electron run, r-z plot

Annular-beam electron run, r-z plot

Saved Views in MetaMesh and the AMaze postprocessors

Plotting is critical to understand meshes and field solutions in three-dimensional spaces. In consequence, we have included a wide variety of options for creating plots in MetaMesh and the analysis programs PhiView, MagView, HWV, RFE3View and Aerial. For example, the following information is neede to create a 3D view of a mesh:

  • Parameters of the point of view, such as the origin of the view axes, the position of the viewpoint in rotational space and the distance from the assembly. These quantities affect the centering of objects, visible surfaces and the perspective.
  • Choice of regions or parts to display.
  • Cut planes to reveal inner details.
  • Reference axes with automatic or user-specified grids and ticks.

Users can expend significant effort to create an optimal display. Therefore, the ability to record to to restore one of more specific views of an assembly saves time and provides documentation.

Tools for saved views, AMaze programs

Tools for saved views, AMaze programs

We have added saved views to MetaMesh and other AMaze plotting programs. The picture shows new tools that appear in all plotting menus. They function for both 3D plots (as shown) or 2D slice plots. The Save view command generates a formatted text file FPrefix.FPV where FPrefix is a descriptive name. The file contains the complete set of plotting parameters. This excerpt illustrates the format:

Program: MetaMesh
2D/3D: 2D
DisplayBy: Regions
Outline: On
NSlice:     40
SliceAxis: YAxis
PlotType: LogElemUp
XPMin: -1.500000E+00
XPMax:  4.250000E+00
...

The ability to restore an exact plot when a specific solution has been loaded is useful but not particularly original or interesting. Saved views in the AMaze programs transcend the standard in two ways:

  • Dynamic adaptation to different solutions.
  • Option for user control of the view parameter set.

Regarding the first feature, there are situations where the user wants to create consistent views of a set of solutions with different geometries, maintaining a similar appearance. Some plot properties (like the viewpoint rotation matrix) are applicable to any solution, but others (like region cutplanes or slice plot limits) depend on the geometry. In AMaze, the load process is adaptive. The programs check each plot parameter for validity. If a parameter is outside the allowed range for the currently-loaded solution, the program computes an alternative. The goal is to preserve as many features of the view as possible.

The second unique feature is that users can modify view files. The order of entries is not rigid. On input, the program uses a free-form parser. If a parameter is missing, the program simply makes no change from the current value in the program. The implication is that a user can edit a view to include only elements essential to his application. For example, one could compare a series of assemblies with different sizes, maintaining an orthographic 3D view from the same point in Cartesian space. In this case, the view file would contain only the entries:

DView:  1.000000E+37
R11:  8.660253E-01
R12: -5.000002E-01
R13:  0.000000E+00
R21:  1.669031E-01
R22:  2.890846E-01
R23:  9.426408E-01
R31: -4.713208E-01
R32: -8.163510E-01
R33:  3.338061E-01