In MetaMesh 3.0 (released today) we revamped the STL routines and did an extensive efficiency analysis. Furthermore, we parallelized the import process in the 64-bit program. There are two results:

• A speed increase by up to a factor of 5.
• High reliability for any valid STL object (i.e., no holes), independent of the shape of the facets.

The second figure shows the problematic user example, resolved quickly and successfully by MetaMesh 3.0. I believe that we now have the fastest, most reliable and simplest method for importing 3D CAD information of any finite-element system. Equally important, the process has a high level of user transparency. Accordingly, my official advice to potential users has changed: if you want to transfer an entire assembly from SolidWorks, go right ahead.

I thought I would take an opportunity to explain why we picked STL files as the transfer medium. Semi-proprietary formats like IGES and STEP are verbose, laden with far more information than required for electromagnetic field solutions. Furthermore, these formats are complex and malleable, with the potential introduction of proprietary features. Direct interaction with the API of the CAD programs has its own drawbacks. Creation of the interface involves extensive labor for each CAD program, contributing to higher costs for the finite-element program. A version change by one CAD vendor necessitates additional work and an update of the client program. Most important, with a direct API connection the mesh conversion process is hidden from the FE program user. Although conversions may proceed smoothly for certain classes of solutions, the crash of a closed process for solutions outside the envelope leaves no recourse for repairs.

STL (stereo lithography) files form the basis of the 3D printing industry. An STL file consists simply of list of triangular facets. The facets define the surface of an object of any level of complexity. Each file represents an individual part of an assembly. STL files offer several advantages for 3D data transfer:

• The format is simple and immutable. Because the format is critical for an extensive base of expensive 3D printers, CAD vendors can not introduce modifications or proprietary features.
• Information exchange is highly efficient because the files carry essential geometrical information and nothing else.
• The importance of the 3D printing industry ensures that all 3D CAD programs include an STL export capability.
• A variety of third-party software is available for viewing, transforming and correcting STL objects.

The STL format is a perfect fit to MetaMesh. The mesh generation process involves fabrication of a 3D assembly from a summation of solid parts. The program requires only shape information. All physical data is introduced in the subsequent finite-element solution programs.

Generation of STL files from a CAD program like SolidWorks is straightforward. Export from the Assembly space gives absolute facet coordinates that define the position and orientation of multiple parts, with a separate file for each part. Graphical preview features allow the user to control the quality of the surface representation. Unnecessary details that do not play a role in the electromagnetic solution and even entire parts may be suppressed. The resulting STL objects may then be inserted in the mesh space in Geometer.

The Geometer/MetaMesh system has capabilities that extend beyond the literal import of a CAD assembly:

• Geometer includes tools to introduce reflections, translations and stretching directly into STL files. In addition, the program includes a full-featured STL viewer with three-dimensional and precision projection displays.
• STL objects may be combined with native fundamental solids defined by parametric models.
• Users can introduce shifts and rotations of individual STL parts to perform perturbation analyses without the need to regenerate the CAD model.
• MetaMesh script directives enable global translations and rotations of entire STL assemblies.

If you have MetaMesh 3.0, here are links to input files for the benchmark test in the figures:

new_stl_method.min

new_stl_method.stl

Facet display of typical STL object (Geometer STL Viewer)

STL object resolved in MetaMesh

Step 1
The critical thing to realize is that if you only record essential files, you can probably fit your entire professional life on one 8 GB USB Flash Drive. Get a good quality USB stick.

Step 2
The computers that you use must have the same data directory structure. For example, I keep all computer programs in a directory c:\progdev. This directory has the same structure on all my computers although individual files may change as I work on projects. To begin your data organization, pick one computer as the master.

Step 3
Use a text editor to create a file CDriveToUSB.bat in the root directory of the USB drive. Here is an example of the content:

REM Software backup: Disk C to USB
xcopy /S /D /F /Y C:\PROGDEV\*.f90 \PROGDEV\*.f90
xcopy /S /D /F /Y C:\PROGDEV\*.f \PROGDEV\*.f
xcopy /S /D /F /Y C:\PROGDEV\*.rc \PROGDEV\*.rc
xcopy /S /D /F /Y C:\PROGDEV\*.cur \PROGDEV\*.cur
xcopy /S /D /F /Y C:\PROGDEV\*.ico \PROGDEV\*.ico
xcopy /S /D /F /Y C:\PROGDEV\*.bmp \PROGDEV\*.bmp
xcopy /S /D /F /Y C:\PROGDEV\*.wpj \PROGDEV\*.wpj

The batch file invokes the DOS XCopy command, described at

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/xcopy.mspx?mfr=true

The first entry after the switches is the source directory and the final entry is the destination directory. The switches serve the following functions:

/S  → Copy from C:\PROGDEV and all its subdirectories
/D  → Copy only files that are newer than those in the destination directory
/F  → Display the file names while copying
/Y  → Suppress confirmation prompting

The key to a compact backup is to pick only the critical file types. In the example, the batch process saves files of source code, Windows resources, cursors, icons, toolbars and projects. Executables and compiled object files (which take up the most space) are not saved because they may be easily regenerated. With a batch file, you can customize the procedure to fit your data structure and to set the relative importance of material. You needn’t worry about getting everything perfect the first time. You can always add entries later.

To continue, run the batch file on the master computer.

Step 4
Create another file USBToCDrive.bat on the USB drive. This file is the inverse of the first one with an additional line:

REM Software restore: USB to Disk C
xcopy /S /D /F /Y \PROGDEV\*.f90 C:\PROGDEV\*.f90
xcopy /S /D /F /Y \PROGDEV\*.f C:\PROGDEV\*.f
xcopy /S /D /F /Y \PROGDEV\*.rc C:\PROGDEV\*.rc
xcopy /S /D /F /Y \PROGDEV\*.cur C:\PROGDEV\*.cur
xcopy /S /D /F /Y \PROGDEV\*.ico C:\PROGDEV\*.ico
xcopy /S /D /F /Y \PROGDEV\*.bmp C:\PROGDEV\*.bmp
xcopy /S /D /F /Y \PROGDEV\*.wpj C:\PROGDEV\*.wpj
REM Precaution against loss of the USB drive
xcopy /S /D /F /Y *.* C:\USBBACKUP\*.*

To be safe, rename your data directories on the slave computer(s) before doing anything else. Keep the old directories for a few weeks in case they contain a newer version of a task that you forgot. Then, insert the USB drive and run the restore batch file.

Here’s how the system works:

• When you begin work on a computer, insert the USB drive and run USBToCDrive.bat to make sure the computer is up to date. The process also makes a backup copy of the full content of the USB drive.
• When you are finished, run CDriveToUSB.bat.

It’s that simple!

Two final comments:

• It’s useful put shortcuts to the two batch files on the desktops to minimize work and to act as a reminder.
• Because the USB drives may be assigned different drive letters on different computers, the batch files must be on the USB drive and make no absolute reference to its location.

Compared to Vista, Windows 7 has just enough new features to irritate you. At some point, we’re going to admit that a new Windows version release has all the excitement of a BIOS update. The operating system eats somewhat less memory than Vista. With some effort to eliminate unnecessary background tasks with WinPatrol, the resting computer used 984 MB of RAM. The machine went bananas when I installed any software. Flashing screens asking me whether I really wanted to do that stacked up recursively and filled the whole task bar. Turning off all security features and deactivating the work-intensive window transparency effect seemed to calm things down.

When the computer got used to the unfamiliar environment of my office, it settled in and performed well, particularly with parallel programs. On a test run, my trusty old workstation (with dual Intel Xeon processors at 3.2 GHz) did a benchmark HiPhi solution in 365 seconds with both processors active. (The task took 443 seconds in a single-processor run.) In comparison, the new machine (1.6 GHz Intel Core i7) took only 138 seconds. The run time was reduced by a factor of 2.7!  The implication is that you can do almost three times as much number crunching on a compact laptop that they’re practically giving away compared to the workstations of a few years ago.

Task window: HiPhi on a multicore machine

• The current files in AVI format are large and take a long time to download. The new video files in MP4 format will be much smaller.
• The user will have the option to download individual files or to view a sequence of them directly on the site.
• The old files ran reliably only on Windows Media Player. The new videos will run under all media programs (like VLC) and on Macs as well as mobile devices.
• The web page to load and to view videos will be organized to show relationships between the resources and to lead the user through sequences for specific programs.
• Ultimately, the video set will cover the full range of applications for our programs.
• With smaller files, there is less pressure to keep the video lengths very short. There will be time to include useful tips on field and particle calculation techniques as well as step-by-step program instructions.
• With the new technology, we can add nice features like transitions and callouts. Furthermore, we will be able to edit the videos to correct errors or to incorporate user suggestions.
• Considering the possibility that finite-element tutorials could go viral, we will also post them on YouTube.

Developments at Field Precision proceed slowly but inexorably. The projection is that the new videos  will be completed in early summer of 2010. In the meantime, we will post them as available.

KB tables
The widely-distributed, unclassified Sesame tables from LANL are an excellent source of equation-of-state information at high density, temperature and pressure. When I began the project, the data for 140 materials were combined in a single binary file with a somewhat idiosyncratic format. The numbers could be accessed only with old-style FORTRAN routines supplied with the library. My first activity was to write programs to disassemble the Sesame library and to reconstruct in a more usable form. The resulting KB tables are in text format and therefore accessible through any computer language.  There is an individual file for each material, so it is easy to add to the library without special maintenance routines. Finally, all quantities have been converted to SI units.

Shock hydrodynamic parameters
For some simulations (e.g., detonations), it is sufficient to use the shock equation-of-state. Data are available for a broad range of materials. The shock velocity us is related to the material velocity up through an equation of the type

us = C0 + S1*up + S2*up^2.

I wrote a program to fit the function to the raw data listed in S.P.Marsh (ed.), LASL Shock Hugoniot Data (University of California Press, Berkeley, 1980) and created a spreadsheet with (C0,S1,S2) data for over 400 materials.

One-dimensional hydrodynamic code
KB1 is a 1D simulation code for planar, cylindrical or spherical geometries. It is a descendant of a much more complex code described in the reference Finite-element simulation code for high-power magnetohydrodynamics. The previouscode could handle magnetic acceleration with self-consistent magnetic diffusion and temperature-dependent conductivity. KB1 uses the element-based approach described in the reference. It handles the full range of material types including explosives. Shock processes can be initiated by collisions, prescribed pressure waveforms or detonations.

Two-dimensional hydrodynamic code
KB2, the centerpiece of the suite, is a 2D code that can handle planar and cylindrical geometries. It was built from the conformable triangular mesh technology developed for our TriComp programs. The element-based Lagrangian approach has drawbacks and advantages. The main limitation follows from the requirement of logical continuity of the mesh. All objects (i.e., regions of different material properties) must be contiguous in the initial state. There can be no disconnected objects or holes. The implication is that the code is useful for assemblies like shaped charges but not suitable for bullets striking a wall or milk drops. On the other hand, the approach has decided advantages:

• Because elements preserve a unique material identity, it is straightforward to apply sophisticated material models and to represent complex histories.
• The compression and expansion of expansion of elements gives automatic zone refinement (i.e.,  the density of elements increases in critical regions).
• The approach is ideal for strong compressions and explosions. The final state of the assembly may be hundreds of times smaller or larger than the initial state.

Constraining the physics
A temptation in writing computer-simulation programs is to add adjustable parameters to represent processes where the physics is fuzzy or even unknown. This practice is largely responsible for the dubious reputation of simulations, particularly of shocks and detonations. An adjustable code can replicate any experiment but has no predictive power. In developing the KB programs, I avoided user parameters as much as possible. The only instances are the artificial viscosity for hydrodynamics (required for numerical stability at shock fronts) and the element detonation pressure for explosives. I believe that disagreement between a code and an experiment is a valuable piece of information. It shows that something is going on that you hadn’t planned on, and that you’d better look for it.

State of KB
I had planned to retire KB, but I recently got a request from Vilem Petr at the Colorado School of Mines. Although the application is fairly specialized, I decided it would be a shame to loose some of the unque resources. For the educational release, I tuned up the program interfaces, corrected several bugs and created a snappier-looking icon. The biggest effort was to combine individual manuals, reports and benchmark tests into a unified instruction manual.  You can download the new manual at http://www.fieldp.com/manuals/kb.pdf.

An ideal parallel program would give a 50% reduction in run time on a dual-processor machine. In reality, there are some sections of programs that can not (or should not) be run in parallel:

• Disk operations (particularly with sequential files).
• Small blocks where it’s not worth the overhead to launch multiple threads.
• Calculations that use shared resources.

In Magnum, the major disk operations are mesh input, solution file output and generation of finite-element coefficients. Although the generation of coefficients uses a large, random-access file, only a single thread can address the file at any time. We found there was no benefit running this operation in parallel. One shared resource that would be unwieldy to replicate is the unit for lest-squares-fit field interpolations. Therefore, the adjustment of μr values in nonlinear solutions is performed by a single thread. Fortunately, it is straightforward to implement multiple threads in the matrix inversion that occupies most of the run time.

As a benchmark test, I used the SHIELD_SATURATION example included in the Magnum application library. The example models a magnetic shield with highly-saturated regions. The solution involved 15 cycles of permeability adjustment. The calculation was performed on a HP xw62000 computer with two Xeon processors at 3.2 GHz. The run time for the serial program was 1424 seconds while the time for the parallel version was 885 s. The run time reduction factor for the dual-processor system was Rf = 0.622.

To see the implication of the result, let fs be the fraction of operations in Magnum performed by a single thread and fp the fraction performed by N threads. Ignoring the overhead time for initiating threads, the run reduction factor is given by

Rf = fs + fp/N.

Taking fs + fs = 1 and solving for fp, we find that

fp = (1 - Rf)/(1 - 1/N).

For N=2 and Rf = 0.622, the fraction of parallel operations is fp = 0.76. This number is consistent with an inspection of the trace generated by the Windows task manager. Inverting the equation, the reduction factor for a quad-core system (N = 4) is predicted to be 0.432 (a speed increase of 2.31X). With a multiprocessor machine, the speed advantages of Magnum over competing products are even more impressive than those we previously described (Comparing Magnum to Maxwell3d and CST-EM Studio).

Monte Carlo calculations are often cited as the poster application for parallel processing. Ironically, GamBet represents our biggest challenge. Although individual primary particles are independent, there are intricate shared resources (such as the secondary particle stacks in the Penelope module). We are experimenting with a distributed-memory approach: assigning portions of a run to independent tasks and  accumulating statistical and dose data at the end. We anticipate that a parallel version of GamBet will be available in the June 1, 2010 update.

Several developments now provide a motivation to move forward:

• Microprocessor manufacturers hit a brick wall at 4 GHz. It is unlikely that higher clock speeds will lead to future gains in computational speed.
• 64 bit processors with 64 bit operating systems are becoming the norm. With the option to address large blocks of memory, users will invariably seek to construct larger meshes.
• Quad core processors are becoming available in conventional PCs.

On February 1, we will issue a major update of the 3D AMaze programs. A featured advance will be the option for multicore operation on 64-bit machines. With OpenMP technology, the programs will automatically optimize operation for a multicore environment. The programs can also run run in the sequential mode on an older computer with no penalty in performance. We will add multiprocessor support to the following classes of programs:

• Boundary-value solutions based on iterative matrix inversion (HiPhi, Magnum).
• Initial-value problems using offset difference methods (HeatWave, Aether).
• Monte-Carlo problems with independent shower calculations (GamBet).
• Charged-particle codes with independent orbit tracking and iterative matrix inversion for field adjustments (OmniTrak).

We have been testing a parallel version of HiPhi on a dual-processor machine. From the results, we expect a reduction in run time by a factor of 2-3 on a quad-core computer.