Code.DavidDoolin.com

More than 15 years of coding are scattered across repositories ranging from raw RCS files to the latest version of Git.

Many of the repositories are corporate, where the code was work for hire. Others are privately hosted, but there is still a lot which is publicly hosted. Links to everything publicly available will be given as necessary.

The story really starts with the projects. Most of this code has been written to support, or implement a variety of applications and software systems.

In the following, each project will be summarized, and the technology explained in plain English, as much as possible.



hRecipe - Semantic recipes for WordPress

Summary: hRecipe provides WordPress site owners the ability to both format recipes and increase search relevance using semantic hrecipe markup. Semantic metadata is a key aspect of information discovery on the web. Over 10,000 downloads (5/16/2010) of the plugin, over a dozen languages and over 1000 trackbacks from published recipes.

Problem space

Finding and getting found on the web seems to get no easier even as technology advances. Semantic markup is one way to help search engines understand the relevance of words and data on a web page, and hrecipe is one of many semantic markup proposals, called microformats, which are approaching standardized definitions.

From a blogger's perspective, the main difficulty with microformats is adding the required markup to the elements of recipe.

The Hrecipe plugin for WordPress solves the user interface problem by presenting a set of form fields to the user, who enters the recipe directly into the form fields. The fields are processed by the plugin, then the correct markup for hrecipe placed on the WordPress post or page.

Technology

WordPress plugin development leverages standard, off-the-shelf development technology for LAMP-driven web applications. For hRecipe, development proceeds on a localhost WordPress installation, with releases to the WordPress plugin repository as appropriate.

Translations have been provided from members of the hRecipe community. The current user interface was written by an hRecipe user and donated to the project. Other users have contributed to bug reports through the hrecipe web page.

Trackbacks to the recipe home page were eventually disabled. Somewhere around the 1000 comment mark, WordPress refused to serve that web page.

Toolchain

PHP, MySQL, WordPress, Jasmine, JQuery.

Source code

Get the source code for hrecipe at the WordPress plugin repository.

Visit the hRecipe.com website for more information.



Parametric building generation

Summary: Users of simulation require realistic objects for training. Rapidly populating a simulation environment with objects modeled from the real world helps planning agencies respond quickly and accurately. The Real World Building Editor went on to form the basis of Total Immersion's Object Builder, now based on Google's SketchUp product.

Problem space

Total Immersion brought me on in March 2006 to help define a way to simulate real buildings in their RealWorld platform. Starting from general guidelines, I scoped out requirements, then designed and built the RealWorld Building Editor. The goal of this application was to allow an untrained user to create a model of a real building for use in a simulation, in about 45 minutes.

Technology

The design of the RealWorld Building editor lay in an intersection between game level editing and computer aided design, neither of which was an adequate paradigm.

Game designers think in terms of meshes, and planes limiting movement.

Buildings modeled using traditional CAD tools require extensive training.

The middle ground is applying simple 2D CAD to the regular geometry of most common buildings. For example, since drawing a floor plan is easy, the floor plan was used to "extrude" building walls into 3D, whence the structure could be exported to the RealWorld simulation engine.

Toolchain

GCC, MS Studio, C/C++, Lua, OpenFlight, Gamebryo, Qt, EXPRESS, IFC.



Mine monitoring wireless sensor network

Summary: Sensors can help miners evaluate and monitor working conditions underground, leading to a safer mine. Since wireless sensors are line-of-site constrained, establishing a baseline, proof-of-concept implementation is necessary before committing to industrial production. We found that wireless sensors work quite well for monitoring temperature, barometric pressure and humidity in Black Diamond Mine, when appropriate care is taken during installation to establish line-of-site communication.

Problem space

Working in an underground mine requires a number of skills beyond software development. For example, everyone on the project was required to undergo mine safety briefing. Parts of the mine suffer from spalling, with occasional rock falls significant enough to threaten safety. Mote installation required using a number of power tools to both fabricate mounts and attached the mounted mote to mine walls.

Technology

The Black Diamond Mines sensor network presented challenges on several fronts. High technology included sensor mote hardware and software, and data collection. Low technology included getting the actual motes installed in the mine. In addition, Black Diamond Mines is a State of California Historical Preserve. Access to the mine required coordinating with park staff.

Two different sensors were deployed in separate networks. One network was built using an early version of Dust Networks SmartMesh, the other network used motes purchased from Crossbow Technology, Inc.

Building a sensor mote network in a mine required distributing motes on a line of site network through the mine, because radio at GHz frequencies does not transmit through rock. The motes were attached to mount made from common building materials purchased at a building supply store, then manufactured using a machine shop within the mine itself. After manufacturing, the mounts were bolted into holes drilled in precise locations for relaying data packets transmitted by each sensor.

As a result of monitoring over periods ranging from days to several weeks, we found the sensors were well capable of recording diurnal fluctuations in temperature, humidity and barometric pressure within the mine tunnels.

Toolchain

Nesc, C/C++, ARM, Wireless sensors, HTML, CSS, MySQL, PHP, Linux, Google Maps, Tablet computers, Cygwin



Wireless wildland fire sensor network

Summary: Firefighting is one the highest risk activities in the modern world. Getting information about environmental conditions occurring during wildland fires helps reduce risk by allowing more accurate prediction of fire evolution. We found that wireless sensor technology is a viable means for monitoring wildland fires, and that minor changes (±1° C) in environmental conditions could be measured, and correlated to the physical behavior of the flame front.

Problem space

Deploying sensors for wildfire monitoring requires immediately confronting the issue of sensor survival. That is, the sensors must have enough exposure to environmental conditions to accurately measure those conditions, yet the environment may destroy the sensor. Given relativaly low cost sensors, protecting the sensors would have increased the cost without clear benefits.

Technology

The main sensing unit is composed of a TinyOS-based Crossbow mote, with a "Fireboard" attached. The Fireboard consists of an Analog Devices ADXL202JE accelarometer, an Sensirion SHT11 combined temperature and humidity sensor, an Intersema 5534AP combined barometric pressure and temperature sensor a Taos 250RD light sensor, and a LeadTek 9546 GPS unit.

The Fireboard was programmed using the Nesc language, which compiles to a runtime appropriate for the AVR-based cpu on the mote. The application has the ability to control which sensors are working at a given time, and separates the data collection from the senors driver such that changes in the data collection are supportable without changing lower level driver code.

Toolchain

Nesc, C/C++, ARM, Wireless sensors, HTML, CSS, MySQL, PHP, Linux, Google Maps, Tablet computers, Cygwin, GPS, TinyOS, Crossbow





Discrete element modeling

Summary: Discontinuous deformation analysis, a discrete element method, provided engineers working with fractured rocks masses an MS Windows application for better understanding the nature of the engineering problem, leading to safer, more reliable design. This application extended earlier work to provide an easy-to-use CAD system for modeling fractured rock masses, and extended mathematical model to incorporate rock bolts.

Problem space

Succinctly, you can't put a landslide in a laboratory, but you can put a landslide in a computer.

Simulating the motion of large rock masses is an interesting and difficult problem. As stated, the scale of the is far too large for laboratory investigation, but it's not always clear how best to simulate motion mathematically. The problem being that 1. rock masses such as mountains and landslides contain fractures, 2. the properties of the mass often vary in different directions, and 3. the properties of the mass are often different in different places. Sort of like a fruit cake, where sometimes you have cake, and sometimes you have not-cake.

Variability in direction and location can be handled mathematically without too much trouble. Fractures add a lot more complexity, because rock on each side of the fracture may move independently, and the interaction across the fracture is discontinuous in time as well as space. These discontinuities render finite element models inapplicable, as finite elements are based on continuous media.

Thus, discrete element modeling. Each element - rock block - is free to move independently, interacting with each other across fracture boundaries. The tool used in this project was an MS Windows implementation of discontinuous deformation analysis.

The difference between discontinuous deformation analysis and the particle mechanics that you might see in video games is crucial: discontinuous deformation analysis is based on the physics of rock blocks and rock block interaction.

Simulations in video game engines may look real (and may result in being very close to real behavior), but physics-based systems are necessary for engineering practice.

Technology

The Discontinuous Deformation Analysis numerical kernel consists of several thousand lines of terse C code, which in the nature of all such applications, prefers to use as much RAM as possible. This makes sense for these kinds of problems.

However, a critical aspect of maintaining the physical viability of a discrete element simulation require at least intermittent monitoring of the particle system during the time marching. That is, watching an analysis proceed on the computer screen can help ensure the results are useful. While visual inspection can't prove an analysis is correct, it can instantly determine when an analysis is grossly incorrect, which is very difficult to algorithmically.

Since most practical engineering analysis is conducted on desktop-based MS Windows computers, the numerical kernel was wrapped with a thin layer to transmit data to MS Windows, and analysis commands to the kernel.

To facilitate data modeling, DDAML, an XML-derived markup language was defined and implemented. The self-describing, forward- and backward-compatible aspects of XML-derived markup allowed continuous feature development of the Windows-based application, without having to keep existing (and well-proven) test cases up to date.

Toolchain

C/C++, Win32 API, Unit testing, Gnuplot, LaTeX, BLAS/LAPACK, Matlab, Octave, Bash, Cygwin, XML, DDAML

More project details and Discontinuous Deformation Analysis source code available at Sourceforge.



Compiling Fortran to Java

Summary: Fortran remains a powerful tool for numerical computation, and more important, Fortran libraries provide a vast repository of proven algorithms implemented in well-tested code. Yet languages such as Java are more appropriate for developing user-friendly modeling and analysis applications which leverage these libraries. For many applications, having these algorithms available as Java source code is highly convenient, and we were able to translate BLAS levels 1, 2 and 3, and most of LAPACK from Fortran to Java.

Problem space

Technology

The University of Tennessee hosts the Innovative Computing Laboratory, which is a world-class repository of numerical and scientific software. Much of this software is based on the Basic Linear Algebra Subroutines (BLAS), and the Linear Algebra Packages (LAPACK). Both BLAS and LAPACK are written in Fortran 77. Using BLAS and LAPACK with other languages requires either having a wrapper around the driver functions such that the calling program can link, or having BLAS and LAPACK as native source.

The Fortran-to-Java project, started in the Spring of 1997, chose to take the BLAS and LAPACK Fortran source directly to Java source code.

At this time, there were no Fortran compilers targeting Java. The f2c project translated a subset of Fortran 77 to the C programming language. The GNU f77 compiler was a moving target. Thus, we decided design and build an in-house compiler, f2j.

ICL's f2j is based on the Flex and Bison lexer and parser. While Fortran is known to be difficult to lexically analyze, by limiting our scope to the BLAS and LAPACK coding standards, we were able to generate an LR1 grammar and successfully parse the entire code base.

Once parsed into an abstract syntax tree, the goto statements in the original Fortran code were reduced to an appropriate combination of break and continue statements in Java.

Because Java doesn't allow internal access to array elements by pointer, indices were generated to pass into Fortran routines requiring internal array access.

Toolchain

Toolchain: C, Flex, Bison, JVM, Jasmin, Javap and the usual assortment of Unix utilities and build scripts.



Fracture flow modeling

Summary: Groundwater contamination on the Oak Ridge Reservation occurs in fractured rock masses, and is difficult to accurately characterize for remediation. The probabilistic model developed in this study exploits the nature of regularly fractured rocks to allow predictive modeling of groundwater flow. The model was successfully verified numerically. Comparison with field results was good.

Problem space

  • Fracture flow:

    "Solid rock" is a misnomer. It doesn't exist.

    Nearly all rock is fractured at some scale, and these fractures allow fluids such as water and oil to move through rock masses.

    Because it's easier to see quasars at the edge of the universe than it is to see 1 meter beneath our feet, understanding how water moves through fractured rock requires building and validating mathematical models.

    Such models help understand where groundwater is going, when it's going to get there, and what it might be carrying with it in terms of contaminants.

Technology

Toolchain

C, Matlab, Gnuplot, SunOs4,5, GCC, Meschach.



Fracture toughness testing

Summary: As part of an ongoing environmental study at Oak Ridge National Laboratory, limestone and sandstone specimens with known fracture toughness were fractured using the Modified Ring Test. Testing results indicated the Modified Ring Test measured toughness appropriately and could be used on rocks outcropping on the Oak Ridge Reservation.

Problem space

Measuring the resistance or propensity of a rock to fracture has important real world application. Rock is the basis for most industrial activity. We mine it and we crush it with gross mechanical systems. Large drills. Tons of explosives. Huge metal crushing machines.

Everything about rock is energy inefficient. Because we as an industrial society use so much rock, even small fractions of 1% energy improvement can save a lot of money.

One common measure is fracture toughness, which can be thought of as a sort of brittleness index distinct from hardness. For example, cast iron is quite hard, but brittle, while many steels are softer, but much tougher.

In this project, Indiana limestone gathering from a quarry south of Bloomington, Indiana was cored into specimens for Modified Ring Testing.

Technology

The geometry processing for quarter-ring cross-sections of the ring specimens was computed using an RPL program on an HP48-SX scientific calculator. The initial parameters were extracted on a Sun4 workstation, loaded to the calculator using Kermit protocol, the geometries calculated, then downloaded into the Macintosh computer running the Cornell FRANC2D code.

Later, these analyses were ported to Abaqus running on Sparc 20 workstations.

Other tools included shell scripting with tsch, awk, sed and the usual assortment of Unix tools appropriate to the task.

Output was plotted to jgraph.

Toolchain

Toolchain: Sun4, Kermit, HP48, FRANC2D, JGraph, MTS fracture testing machine, machine tools such as rock saw, drill press, etc.




blog comments powered by Disqus


Copyright © 1994-2013 David M. Doolin All Rights Reserved.

dool.in