Specific Impulses

Android Fortran Step-by-Step Part 3: Bringing it All Together

2011-10-21T22:14:00.000-07:00

***UPDATED For NDK-r7***
Now that we have a working Fortran compiler for our Android hardware, it's time to show the NDK tools how to use it to build native applications. Be warned: I am not pretending to be a master of the GNU make system and I have done the minimum amount of hacking required so this will work for my own use... YMMV

If you haven't spent any time using the Android NDK then this will probably not be very informative. Still, I am guessing that anyone who has gotten this far probably has at least tried to build the example applications that come with the development kit. Specifically, I am referring to the Native Activity example, which is the only one I've seen so far that uses 0% Java and 100% native C code. My original plan was to gut most of the C and replace it with calls to Fortran routines packaged as a library with interfaces bound to the skeleton C code via ISO_C_BINDING. As I'm planning to demonstrate in the near future, this works well within reason.

I've also decided to avoid using Eclipse for the time being and stick to doing everything with text editors (gvim) and the command line. The main reasons for this is that the Fortran plugins for Eclipse are not great and the apk package refuses to rebuild when changes are made to the native source files... I've really tried to like Eclipse, but I just can't shake the opinion that it's difficult to install, bloated, buggy and really only meant for Java programming. I suppose if I was a computer science major in college then I would probably be hooked on some IDE or other, but I wasn't, so I'm not. Give me a text editor with decent syntax highlighting and a compiler that produces reasonable debugging information and I'm happy.

On with the show...

Step 1: Prep the new toolchain for the ndk-build script

The GNU Make based native build system needs a couple of things before it will recognize the new compiler. The first thing to do is to copy two files from the old toolchain directory into the new one:

Starting in the NDK toolchains directory; if you are following the previous instructions, that will be here:

/opt/Android/android-ndk-r7/toolchains

cp arm-linux-androideabi-4.4.3/config.mk arm-linux-androideabi-4.7.0/

cp arm-linux-androideabi-4.4.3/setup.mk arm-linux-androideabi-4.7.0/

Now, if you built the 64-bit versions of the compiler executables, you will need to fake out the build script by making a symbolic link from the (non-existant) 32-bit tools to the 64-bit ones.

cd arm-linux-androideabi-4.7.0/prebuilt

ln -s linux-x86_64 linux-x86

Step 2: Add gfortran support to ndk-build

This was by far the hardest part for me since I am not a shell scripting master and definitely not a Make system master, but the result works well enough, although it could be much better I'm certain. I would just make some diff patches, but I don't have a reliable way to post them here, so I'll just put the text of the changes in their entirety with instructions as to where to put them.

The first thing to do is to set an environment variable that tells the NDK which toolchain to use. Add the following to your ~/.bashrc file:

export NDK_TOOLCHAIN=arm-linux-androideabi-4.7.0

(remember that you need to start a new terminal for the variable to be used)

UPDATE: If you followed the new instructions in the previous post then skip the next section and go straight to the bottom.. you're done!

~~Edit this file:~~

~~/opt/Android/android-ndk-r6b/build/core/build-binary.mk~~

~~Change line 195 to this:~~

all_source_extensions := .c .s .S $(LOCAL_CPP_EXTENSION) .f .f90

~~Add these lines starting at line 223:~~

# handle free-form Fortran (.f90)

$(foreach src,$(filter %.f90,$(LOCAL_SRC_FILES)), $(call compile-f90-source,$(src)))

# handle fixed form Fortran (.f)

$(foreach src,$(filter %.f,$(LOCAL_SRC_FILES)), $(call compile-fc-source,$(src)))

~~Edit this file:~~

~~/opt/Android/android-ndk-r6b/build/core/default-build-commands.mk~~

~~Add these lines starting at line 93:~~

TARGET_FC       = $(TOOLCHAIN_PREFIX)gfortran

TARGET_FFLAGS   = 

~~Now for the big one...~~

~~Edit this file:~~

~~/opt/Android/android-ndk-r6b/build/core/definitions.mk~~

~~Add this chunk starting at line 1040:~~

~~# slightly modified version for Fortran source files~~
~~define ev-build-fc-file~~
~~$$(_OBJ): PRIVATE_SRC      := $$(_SRC)~~
~~$$(_OBJ): PRIVATE_OBJ      := $$(_OBJ)~~
~~$$(_OBJ): PRIVATE_DEPS     := $$(call host-path,$$(_OBJ).d)~~
~~$$(_OBJ): PRIVATE_MODULE   := $$(LOCAL_MODULE)~~
~~$$(_OBJ): PRIVATE_TEXT     := "$$(_TEXT)"~~
~~$$(_OBJ): PRIVATE_CC       := $$(_CC)~~
~~$$(_OBJ): PRIVATE_CFLAGS   := $$(_FLAGS)~~
~~$$(_OBJ): $$(_SRC) $$(LOCAL_MAKEFILE) $$(NDK_APP_APPLICATION_MK)~~
    ~~@mkdir -p $$(dir $$(PRIVATE_OBJ))~~
    ~~@echo "$$(PRIVATE_TEXT) : $$(PRIVATE_MODULE) <= $$(notdir $$(PRIVATE_SRC))"~~
    ~~$(hide) $$(PRIVATE_CC) $$(PRIVATE_CFLAGS) $$(call host-path,$$(PRIVATE_SRC)) -o $$(call host-path,$$(PRIVATE_OBJ))~~
~~endef~~

~~# This assumes the same things than ev-build-fc-file, but will handle~~
~~# the definition of LOCAL_FILTER_ASM as well.~~
~~define ev-build-fc-source-file~~
~~LOCAL_DEPENDENCY_DIRS += $$(dir $$(_OBJ))~~
~~ifndef LOCAL_FILTER_ASM~~
~~# Trivial case: Directly generate an object file~~
~~$$(eval $$(call ev-build-fc-file))~~
~~else~~
~~# This is where things get hairy, we first transform~~
~~# the source into an assembler file, send it to the~~
~~# filter, then generate a final object file from it.~~
#

~~# First, remember the original settings and compute~~
~~# the location of our temporary files.~~
#
~~_ORG_SRC := $$(_SRC)~~
~~_ORG_OBJ := $$(_OBJ)~~
~~_ORG_FLAGS := $$(_FLAGS)~~
~~_ORG_TEXT := $$(_TEXT)~~

~~_OBJ_ASM_ORIGINAL := $$(patsubst %.o,%.s,$$(_ORG_OBJ))~~
~~_OBJ_ASM_FILTERED := $$(patsubst %.o,%.filtered.s,$$(_ORG_OBJ))~~

~~# If the source file is a plain assembler file, we're going to~~
~~# use it directly in our filter.~~
~~ifneq (,$$(filter %.s,$$(_SRC)))~~
    ~~_OBJ_ASM_ORIGINAL := $$(_SRC)~~
~~endif~~

~~#$$(info SRC=$$(_SRC) OBJ=$$(_OBJ) OBJ_ORIGINAL=$$(_OBJ_ASM_ORIGINAL) OBJ_FILTERED=$$(_OBJ_ASM_FILTERED))~~

~~# We need to transform the source into an assembly file, instead of~~
~~# an object. The proper way to do that depends on the file extension.~~
#
~~# For C and C++ source files, simply replace the -c by an -S in the~~
~~# compilation command (this forces the compiler to generate an~~
~~# assembly file).~~
#
~~# For assembler templates (which end in .S), replace the -c with -E~~
~~# to send it to the preprocessor instead.~~
#
~~# Don't do anything for plain assembly files (which end in .s)~~
#
~~ifeq (,$$(filter %.s,$$(_SRC)))~~
    ~~_OBJ   := $$(_OBJ_ASM_ORIGINAL)~~
    ~~ifneq (,$$(filter %.S,$$(_SRC)))~~
      ~~_FLAGS := $$(patsubst -c,-E,$$(_ORG_FLAGS))~~
    ~~else~~
      ~~_FLAGS := $$(patsubst -c,-S,$$(_ORG_FLAGS))~~
    ~~endif~~
    ~~$$(eval $$(call ev-build-fc-file))~~
~~endif~~

~~# Next, process the assembly file with the filter~~
~~$$(_OBJ_ASM_FILTERED): PRIVATE_SRC    := $$(_OBJ_ASM_ORIGINAL)~~
~~$$(_OBJ_ASM_FILTERED): PRIVATE_DST    := $$(_OBJ_ASM_FILTERED)~~
~~$$(_OBJ_ASM_FILTERED): PRIVATE_FILTER := $$(LOCAL_FILTER_ASM)~~
~~$$(_OBJ_ASM_FILTERED): PRIVATE_MODULE := $$(LOCAL_MODULE)~~
~~$$(_OBJ_ASM_FILTERED): $$(_OBJ_ASM_ORIGINAL)~~
    ~~@echo "AsmFilter      : $$(PRIVATE_MODULE) <= $$(notdir $$(PRIVATE_SRC))"~~
    ~~$(hide) $$(PRIVATE_FILTER) $$(PRIVATE_SRC) $$(PRIVATE_DST)~~

~~# Then, generate the final object, we need to keep assembler-specific~~
~~# flags which look like -Wa,~~
~~_SRC   := $$(_OBJ_ASM_FILTERED)~~
~~_OBJ   := $$(_ORG_OBJ)~~
~~_FLAGS := $$(filter -Wa%,$$(_ORG_FLAGS)) -c~~
~~_TEXT := "Assembly     "~~
~~$$(eval $$(call ev-build-fc-file))~~
~~endif~~
~~endef~~

~~...And this chunk at line 1213:~~

~~# -----------------------------------------------------------------------------~~
~~# Template : ev-compile-fc-source~~
~~# Arguments : 1: single Fortran source file name (relative to LOCAL_PATH)~~
~~#             2: target object file (without path)~~
~~# Returns   : None~~
~~# Usage     : $(eval $(call ev-compile-fc-source,,)~~
~~# Rationale : Internal template evaluated by compile-fc-source~~
~~# -----------------------------------------------------------------------------~~

~~define ev-compile-fc-source~~
~~_SRC:=$$(LOCAL_PATH)/$(1)~~
~~_OBJ:=$$(LOCAL_OBJS_DIR)/$(2)~~
~~_FLAGS := $$($$(my)FFLAGS) \~~
          ~~$$(call get-src-file-target-cflags,$(1)) \~~
          ~~$$(call host-c-includes, $$(LOCAL_C_INCLUDES) $$(LOCAL_PATH)) \~~
                     ~~$$(LOCAL_CFLAGS) \~~
                    ~~$$(NDK_APP_CFLAGS) \~~
          ~~$$(LOCAL_FFLAGS) \~~
          ~~$$(NDK_APP_FFLAGS) \~~
          ~~$$(call host-c-includes,$$($(my)C_INCLUDES)) \~~
          ~~-c \~~

~~_CC   := $$(TARGET_FC)~~
~~_TEXT := "Compile-fortran $$(call get-src-file-text,$1)"~~

~~$$(eval $$(call ev-build-fc-source-file))~~
~~endef~~

~~# -----------------------------------------------------------------------------~~
~~# Function : compile-fc-source~~
~~# Arguments : 1: single Fortran source file name (relative to LOCAL_PATH)~~
~~# Returns   : None~~
~~# Usage     : $(call compile-fc-source,)~~
~~# Rationale : Setup everything required to build a single Fortran source file~~
~~# -----------------------------------------------------------------------------~~
~~compile-fc-source = $(eval $(call ev-compile-fc-source,$1,$(1:%.f=%.o)))~~
~~compile-f90-source = $(eval $(call ev-compile-fc-source,$1,$(1:%.f90=%.o)))~~

These are just slightly modified versions of the functions that handle C/C++ source code. Once this is done, you should be able to put fixed form (.f) and free-form (.f90) Fortran source files in the jni folder of your native application, add them to LOCAL_SRC_FILES in ./jni/Android.mk, and then run ndk-build like normal to compile your Fortran into the shared library for your Android application. If you are using Eclipse you should be able to build and deploy directly to your device, but remember that it will not regenerate the apk if you make changes to the source code (at least that's what happened to me). If you are on the command line then you can use ant to build the apk and deploy it from within the project folder:

ndk-build -B V=1

ant release

ant install

When I find some more time, I'll put up an example of a working native application that demonstrates how to package some assets, move them to the device SD card and then use them to do something fun in Fortran using OpenGLES and the device sensors.

Android Fortran Step-by-Step Part 2: Building a Custom GCC Toolchain

2011-10-20T06:47:00.000-07:00

***Updated for NDK-r7***
This part is relatively tricky. I would never have gotten this far without the help of another clever person who needed a newer GCC toolchain for Android, but for a completely different set of reasons.

Thank you: http://glandium.org/blog/?p=2146

There are a lot of steps here, so I'll try not to clutter it up with jabber. If you have completed Part 1, then you should be ready to dive right in and start cutting and pasting the following commands. Maybe if I find some time, I'll make this into a shell or Python script that will automate the process, maybe not.

Step 0: Get a few more required packages

sudo yum install subversion ncurses-devel flex bison texinfo

Step 1: Get the NDK build package

This would normally be installed by the ./build/tools/download-toolchain-sources.sh script included with the NDK, ~~but since kernel.org was hacked a couple of months ago that doesn't seem to be working. Luckily it is available from the glandium.org post, so get it here:~~

~~https://bugzilla.mozilla.org/attachment.cgi?id=549787~~

~~Copy the ndk-build-r6.tar.gz2 file into /opt/Android/android-ndk-r6b and extract it there:~~

~~tar jxvf ndk-build-r6.tar.bz2~~

~~You should now have a directory called:~~

~~/opt/Android/android-ndk-r6b/src/build~~

UPDATE: The google source repositories are back, so you don't need to use the download-toolchain-sources.sh script. Simply use git (yum install git if you don't have it already):

mkdir src
git clone https://android.googlesource.com/toolchain/build src/build

Step 2: Put the GCC sources into your Android NDK install

cd /opt/Android/android-ndk-r7

mkdir -p src/gcc

svn export -r182917 svn://gcc.gnu.org/svn/gcc/trunk src/gcc/gcc-4.7.0

This will give you the exact set of sources that I used. Depending on your connection speed this could also take some time to finish. If you want to be adventurous, you can get the bleeding edge sources by omitting the -r182917 from the command above. You can also use checkout instead of export if you want to be able to keep your sources up-to-date via 'svn update'. Of course, as of the date of this post, this version IS the bleeding edge ;)

~~Step 3: Patch the GCC sources~~

There is an anoying 'bug' in the GCC gfortran configure process when building a cross-compiler (at least this one anyway). Fortunately, this is much easier with the latest sources than it was the first time I tried it, but it still is a bit of a hack.

~~Open this file:~~

~~/opt/Android/android-ndk-r6b/src/gcc/gcc-4.7.0/libgfortran/configure~~

~~Change 'exit $1' on lines 279 and 26306 to 'echo $1'~~

~~This will keep the configure script from crashing because of a link test that can't be done for the cross-compiler. If anyone has a more elegant solution to this then please post it in the comments!~~

~~Now open this file:~~

~~/opt/Android/android-ndk-r6b/src/gcc/gcc-4.7.0/libgfortran/io/unix.c~~

~~Add the following starting on line 1113:~~

~~#if !defined(S_IREAD) && defined(S_IRUSR)~~

~~#define S_IREAD S_IRUSR~~

~~#define S_IWRITE S_IRUSR~~

~~#endif~~

~~This fixes a file permission issue when linking against the Android Bionic C library instead of the normal glibc.~~

Step 4: Get all of the extra sources you will need

There are a number of extra packages that are required in order to build a fully functional GCC cross-compiler. These also need to be put in the right location for the Android helper script to use. Note that the sources for gcc binutils and gdb need to be extracted, the others can stay packed up.

cd src

mkdir binutils

cd binutils
wget http://sourceware.mirrors.tds.net/pub/sourceware.org/binutils/snapshots/binutils-2.22.51.tar.bz2

tar -jxvf binutils-2.22.51.tar.bz2

cd ..

mkdir gmp

cd gmp

wget http://ftp.gnu.org/gnu/gmp/gmp-5.0.2.tar.bz2

cd ..

mkdir mpfr

cd mpfr

wget http://ftp.gnu.org/gnu/mpfr/mpfr-3.0.1.tar.bz2

cd ..

mkdir mpc

cd mpc

wget http://www.multiprecision.org/mpc/download/mpc-0.9.tar.gz

cd ..

mkdir gdb

cd gdb

wget http://ftp.gnu.org/gnu/gdb/gdb-7.3a.tar.bz2

tar -jxvf gdb-7.3a.tar.bz2

cd ..

!!!IMPORTANT!!!

Use the exact versions of each of the above that are shown. There is a problem building with mpfr-3.1 and it will make it a lot harder for me to help you if you are using other versions!

You should now have a directory structure like this:

/opt/Android/android-ndk-r7/src:

ls *

src/binutils:
binutils-2.22.51 binutils-2.22.51.tar.bz2

src/build:
build-sysroot.sh config.guess configure COPYING dejagnu Makefile.in
clear_header.sh config.sub configure.ac COPYING.LIB install-sh README

src/gcc:
gcc-4.7.0

src/gdb:
gdb-7.3 gdb-7.3a.tar.bz2

src/gmp:
gmp-5.0.2.tar.bz2

src/mpc:
mpc-0.9.tar.gz

src/mpfr:
mpfr-3.0.1.tar.bz2

Step 5: Setting up the NDK helper script

The Android NDK comes with a nice script that takes care of most of the build process, as long as it knows where to find what it needs. That requires a little bit of editing...

~~Open up:~~

~~/opt/Android/android-ndk-r6b/build/tools/build-gcc.sh~~

~~and make the following changes:~~

GDB_VERSION=7.3

BINUTILS_VERSION=2.22.51

GMP_VERSION=5.0.2

MPFR_VERSION=3.0.1

~~Add a new definition for MPC just below the one for GDB:~~

MPC_VERSION=0.9

register_var_option "--mpc-version=<version>" MPC_VERSION "Specify mpc version"

Add a new option to control the languages that are to be built. This can be placed anywhere in the upper portion of the script. I placed it right under the line that starts: register_var_option "--keep-libstdcxx"

~~ENABLE_LANGUAGES="c,c++,fortran"~~

~~register_var_option "--enable-languages=<name>" ENABLE_LANGUAGES "Experimental: specify which languages to build"~~

~~Now add the new definitions to the configure command about 2/3rds down in the script:~~

mkdir -p $BUILD_OUT && cd $BUILD_OUT && run \

$BUILD_SRCDIR/configure --target=$ABI_CONFIGURE_TARGET \

                        --enable-initfini-array \

                        --host=$ABI_CONFIGURE_HOST \

                        --build=$ABI_CONFIGURE_BUILD \

                        --disable-nls \

                        --prefix=$TOOLCHAIN_PATH \

                        --with-sysroot=$TOOLCHAIN_SYSROOT \

                        --with-binutils-version=$BINUTILS_VERSION \

                        --with-mpfr-version=$MPFR_VERSION \

                        --with-gmp-version=$GMP_VERSION \

                        --with-mpc-version=$MPC_VERSION \

                        --with-gcc-version=$GCC_VERSION \

                        --with-gdb-version=$GDB_VERSION \

                        --enable-languages=$ENABLE_LANGUAGES \

                        $ABI_CONFIGURE_EXTRA_FLAGS

UPDATE:
Since makefiles are notorious for crapping out due to invisible typos, I've decided to post a patch that should get your ndk-r7 directory all fixed up.

http://www.scientific-sims.com/files/blog/ndk-r7-fortran.patch

Copy the above patch into your android-ndk-r7 directory and then patch as follows:

patch -p1 -i ndk-r7-fortran.patch

If it patches five files successfully then you should be ready to start the build...

Make sure you are in the NDK base directory:

cd /opt/Android/android-ndk-r7

Start the script and go to bed.. :)

./build/tools/build-gcc.sh --try-64 $PWD/src $PWD arm-linux-androideabi-4.7.0

If everything goes ok, this will take quite a while, possibly an hour or more. When it finishes, your shiny new Fortran enabled compiler suite will be here:

/opt/Android/android-ndk-r7/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86_64/bin

Now you can remove the old compiler from your ~/.bashrc file and replace it with the new one (see the last post).

[mike@fedorocks bin]$ arm-linux-androideabi-gfortran --version

GNU Fortran (GCC) 4.7.0 20111019 (experimental)
Copyright (C) 2011 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

If you've made it this far then congratulations! You can now use your shiny new Arm enabled Fortran compiler just as you would your regular Fortran compiler. I've already tested this with the Linpack benchmark as well as several other codes, so I am confident that it works. While that is all well and good, our ultimate goal is to fix up the Android build system so we can put Fortran native code in our Android applications and pack them up for distribution on the Android Market.

Stay tuned...

Android Fortran Step-by-Step Part 1: Preparing Your Build Machine

2011-10-17T22:07:00.000-07:00

***Updated for NDK-r7***
I'm going to keep these next few posts light on the humor if that's alright.. being funny takes too much time and effort.. :(

In case this is your first visit to this blog, you might want to have a look at some background..

here..
and here..
This is nice too if your into that sort of thing.

So, if you're still with me, lets start by assuming that you are using a Windows computer. If not, then good for you, and I'll try to keep this as neutral as possible. As much as I like to endorse a Microsoft free lifestyle (well, they do make good mice), I am not so much of a Linux snob that I believe there aren't people out there who have a good reason to run Windows. So, if that is you, go ahead and log out of Call of Duty, stand up, stretch, focus on an object across the room for a moment, then head over to www.virtualbox.org and install the latest version. Let's just pretend that VirtualBox isn't owned by Oracle for a little while.

I'm going to let someone else show you how to get Fedora 15 installed.. I'm sure that those of you who prefer Ubuntu or another Linux version could make most of this work as well, but lets stick to Fedora for the moment, OK?

Come back when you have something that looks like this:

Now here's a little short-cut that should help you get all of the necessary 32-bit junk installed to support the Android development tools. Open a terminal and type this:

sudo yum install wine wine-devel wget

If you are running 64 bit Fedora then this is the quickest way I know to setup the machine for 32 bit applications, plus you'll be able to run quite a few Windows programs with wine if you feel the need to. There are actually a lot of Windows 95/98 games that run better under wine than under Windows XP (haven't tried any in Win7, but can't imagine it would be better). Notice I also included the wget package, we'll need that soon enough.

Now install Java (the horror!)

sudo yum install java java-devel

This should install openjdk by default, which has been working fine for me.

Now you should have everything you need to install the Android SDK and NDK. I usually put this kind of thing under /opt and I recomment you do the same for now...

sudo mkdir /opt/Android

sudo chmod 777 /opt/Android

Those commands should be all you need to make a place for your Android stuff to live that will have the right permissions for you to work without needing root privileges. So, without further ado:

cd /opt/Android

wget http://dl.google.com/android/android-sdk_r16-linux.tgz

wget http://dl.google.com/android/ndk/android-ndk-r7-linux-x86.tar.bz2

Isn't that wget handy?

Now unpack the SDK and NDK:

tar -zxvf android-sdk_r16-linux.tgz

tar -jxvf android-ndk-r7-linux-x86.tar.bz2

Notice the -z and -j above.. Google appears to have warring internal factions over the preferred compression scheme for tar archives. I'll let history decide which is better, bzip or gzip.. nah, just kidding, it's bzip ;)

Almost ready for the fun stuff.. just have to add a couple of things to our environment.. open .bashrc in your home directory and add these two lines:

UPDATE: I forgot to include the SDK platform-tools directory, where the android debug bridge (adb) lives.. can't get far without that!

PATH=/opt/Android/android-sdk-linux/tools:/opt/Android/android-sdk-linux/platform-tools:/opt/Android/android-ndk-r7:$PATH

export PATH

As an alternative to monkeying around with .bashrc, I highly recommend using environment modules, especially if you use a lot of different development tools like I do on a daily basis. For now, let's stick with the simplest approach.

So, you should now be ready to fire up the Android SDK.. just open a new terminal and type:

android

If your environment is configured correctly then you should see this:

Now you need to install the android packages that are required for a basic development platform. I've been working with 2.3, so I recommend starting there as well. I think there is a good chance that the newer platforms will work also (maybe even better), but my phone is 2.3, so that's what I'm targeting.

I have to admit I like Windows 7's snip tool, and no, my handwriting isn't much better when I'm not trying to write with a mouse! When the install is done, you should see something like this:

DO NOT push that innocent looking Update All button... unless you want every available package installed! This is also a good time to set up an AVD (virtual device) if you don't have a real device to develop on. Let me know in the comments if you need help with that.

We're almost done with this part... In order to build our fancy new Fortran enabled tool chain, we need to temporarily add the crusty old one to the shell environment path. So, open your .bashrc file again and add this line above the export PATH line from before:

PATH=/opt/Android/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin:$PATH

Now if you open a new terminal, you should have the native Android compilers available:

At this point, you have everything you need to start working with native code in C and C++. In the next post, I'll get to the good stuff... adding gfortran to the mix and telling the Android build system how to use it!

Almost there...

Fortran pining for the Fjords? Not even close!

2011-10-05T15:37:00.000-07:00

Since I've started down this rabbit hole, I may as well keep digging until I reach bedrock. It's been interesting to me that I've gotten more feedback on this subject than any of the rocket related stuff. Well, when I say feedback, I don't just mean comments on the posts, but include e-mails that I've received from people with questions about how to get it to work for them. Not that I mind fielding these questions, but I think in the future I'd like to keep as much of these discussions public as possible. By that I mean, if you have a question or comment, don't be shy... post it in the comments and I'll do my best to respond there quickly.

It would be a shame if something you or I learned together wasn't available for other people to benefit from!

So, where to begin... One of the reasons I haven't put anything out here for so long is that I've been making such steady progress that I couldn't find a good stopping point. I would get a little further along and then say 'hmm.. it would be so cool if I could just get that one thing working and then people would REALLY be impressed'. Well, as a German flight test engineer friend of mine once said, it's time for a 'Full Stop'. Pack up the equipment, go home, forget about it for a long weekend and start sorting through the data with a clear head on Monday.

That is the spirit that I've decided to adopt with this project. Since I'm calling it a 'project' now, there probably should be a set of goals:

Help Fortran become a viable companion to C and C++ for developing native applications for the Android OS.
Make it easier for other people to get in on the fun.
Convince Google to abandon the Dalvik virtual machine altogether.

That last point deserves a little expansion. If Android is to ever really compete with iOS in responsiveness and stability, they are going to have to drop the extra layer. Android has all the right ingredients: a Linux kernel, a decent C runtime, OpenGL, OpenSL and, let's not forget, the backing of a giant corporation with almost limitless resources. Unfortunately, that last item carries with it a level of institutional inertia that gives it the maneuverability of an ocean liner sitting on top of an aircraft carrier. Still, what do I know? As someone who has no formal computer science education and no real programming credentials to speak of, I accept that my opinion probably has approximately zero weight, but I can dream, can't I?

That's about it. I wish I could come up with something funny to say here, but there really is nothing funny about working with the Android development tools, so I'll just fall back on my old standby.

JAVA SUCKS™

Really.

No, seriously.

I should devote an entire post to the time that I've spent trying to do anything useful with Java and C++ and contrast that with the one long weekend it took me to go from zero to comfortable with Python. Unfortunately, if I did that, I would be wasting even more of my time, so it's not too likely. Not to worry though, Java is now owned by the one company in the world most likely to drive it toward extinction.. and, amazingly enough, that's NOT Microsoft. Seriously, though, time will tell, but I'm just getting this out there so I can link back to this post 20 years from now and say CALLED IT!

Sadly, I believe we are stuck with C++. In the giant ball of mess that the language is, there are a handful of things that make it useful for people who are already comfortable with C. That's not me, but I can envision a future where it is.

Before anyone jumps on a high horse and starts quoting the tiobe index or saying that Fortran is dying, dead, buried and/or in some other way not relevant today, I say..

Why are you reading this in the first place?
If you Fortran, you know.
See item #1

There is a saying that is part of Fortran lore that I've seen a number of variations on over the years and it goes something like this:

"Letter O considered harmful"

Oh wait, it was this one:

"I don't know what the syntax or features of the preferred programming language of scientists and engineers will be in the future, but I know that it will be called Fortran"

Next up.. getting your Android on.. or.. Learning Linux for fun and profit!

Short Update.. Android Fortran Linpack

2011-05-04T22:46:00.000-07:00

Sorry I haven't had much time for blogging lately, hopefully I will be able to make some soon. Until then, I wanted to put some more information on the Fortran compiler that I hacked together for android and the modified Linpack benchmark. I've gotten several e-mails from people with comments about the procedure and questions about how to make it work for themselves. Some of the comments might even allow me to make the compiler work correctly without the ugly hacks, but alas, it works ok right now, so my motivation is low.

Anyway, a couple of days ago, I dug all of it back out and verified that it still worked. Then I made a couple of small changes to the code to make it easier to install and pushed it back out to my phone and tried it out. It was a bit frustrating since my phone had lost it's ability to give me superuser access after the last update from Verizon. Technically, it wasn't entirely necessary for me to root the phone for this, but I decided I wanted to re-root it before I installed the new version of the benchmark, just in case I ran into any trouble. Eventually, I'd like to pack all this up nicely in a signed apk and drop it for free on the android market, but that is really low on my priority list right now.

So, I've made the source code and the pre-compiled arm-android executables available here:

http://aeromonkey.homeip.net/public/android

There isn't too much to say about the code that you won't learn by looking at it. The makefile is probably the most useful thing, since it handles the linking step that gave me so much trouble before. Installing the executable is easy enough if you have the adb bridge set up. You just need to put it where it can be executed.. in my case:

adb push linpack_d /data/local/

Then it can be run using a terminal app (or the adb shell). Once you have a terminal open, just go to where you put it and run it.

cd /data/local
./linpack_d {Matrix-Size} {Results-File}

or more specifically,

./linpack_d 500 /mnt/sdcard/tmp/linpack.results

There is a definite bug in the compiler right now that makes it fail when trying to overwrite an existing results file, so it's best to remove the file manually before running the benchmark if you want to save the results.

I've also included the python script I wrote that lets the benchmark be run in a more interactive way. This requires the Scripting Layer for Android and is left as an exercise for the reader. (Hint: put it in /mnt/sdcard/sl4a/scripts)

I hope some industrious people out there can get this to work on a few other phones.. my Droid 1 seems to top out at just under 25 MFlops using the best compiler options I could find for the cortex-a8. I ran it on a friend's Droid 2 a while ago and got about 40 (if I remember right).

It would be fun to hear how it runs on some newer hardware, so let me know in the comments section below!

DISCLAIMER: if you break your phone it ain't my fault.. and besides, you really shouldn't be installing random apps you downloaded from some guy's blog anyway.

My Android speaks Fortran.. yours can too!

2011-01-14T22:37:00.000-08:00

UPDATE: This is inferior technology... see here for the new way!

Ok.. this is WAY off-topic, even more so than my last couple of posts. I promise that I'll get back to the rocket business eventually, but I just think this is too cool not to share. Plus I wanted to record what I did somewhere so I don't forget about it. Not to mention the amount of nerd street cred that something like this is worth...

In a nutshell, I've managed, through sheer bullheadedness, to get something that is completely useless to 99.44% of android phone owners. Something that seemed perfectly reasonable to me that was just absent... a Fortran compiler.

A little backgroud...

When I got my shiny new Verizon Droid back in June of last year, I was really excited by the possibilities that the platform presented to me with its open source Linux based Android goodness under the hood. Unfortunately, I quickly discovered that while google has indeed released the source for the Android platform, that platform is lacking some of the things that make life on planet Unix so fun and portable. Most notable of these are the X11 windowing system and the full GNU Compiler Collection, lovingly referred to as GCC. Those two major omissions, along with their decision to use a non-standard c library, mean that it is far from trivial to get applications ported over. Ironically, this is exactly what makes the far less open Apple mobile iOS much easier to develop for (from what I've read anyway), since most of the facilities from the desktop (OSX) are available in some fashion or other and everything is standardized and collected neatly together under the Xcode IDE. The google answer to this was to add a bunch of features to the venerable Eclipse IDE, declare that Java will be the language of choice for the platform and called it good.

Now as someone who has sworn off Java for life on the grounds (small pun intended) that it is a language with all the complexities of C++ and none of the speed, I just refuse to stand by while the company that will one day bring us Skynet attempts to keep me from using my phone the way I want. I actually had high hopes for the so-called scripting layer for android, which makes it possible to run Python (my second favorite computer language) on the phone. But once again, google has seen fit to hamstring developers by only providing bindings to a handful of the phone's low level functions, relegating Python and friends to second class citizens in the Android kingdom.

This is where my Odyssey began, a simple desire to do what I wanted on my phone in a language that I understand.. that language being Fortran. Now you might ask me, "Mike, what place does the oldest surviving computer language have on my shiny new personal communication device?". Well, my answer to that is maybe it doesn't, but I think it should get a chance, don't you? Fortran is still the undisputed heavyweight number crunching champion of the world, so why not try to take advantage of that to write some smoking fast applications for the little black phone that could. You might also say, "What's the point since the android API is not accessible from Fortran at all so it's even less useful than Python?". To that, my answer is the magical Fortran fairy dust called "iso_c_binding". Since the Android NDK provides interfaces to most of the phone's functions via C, then I should be able to, at least in theory, access those functions from Fortran by wrapping them in C.

So, with this knowledge in hand, I proceeded to download the latest GCC 4.6 pre-release source code and started looking online for information that I needed to build a cross compiler for the ARM CPU in my phone... two weeks and a few gray hairs later, I marveled at the wonder of 'Hello World' in three lines of Fortran running in a terminal on my droid.

Here's how I did it... but be warned, what follows is full of dirty hacks, workarounds and generally poor execution, so don't expect it to work for you the first time if you attempt to duplicate it. I will, however, try to re-create the process as faithfully as possible.

The first thing you will need is a computer running Linux, in my case I am using Fedora 13, but most other distributions should work without major changes. Don't even think about asking me how to do this under Windows unless you want to be taunted mercilessly until you have no choice but to abandon this blog altogether... seriously. It won't work under Windows so don't try it.

The next thing you need is a functional Android SDK and NDK environment with the system ABI resources for your phone. I leave installation of that as an exercise for the reader. Once you have that, there is a handy script in the NDK under {ndk-root}/build/tools called make-standalone-toolchain.sh that does just what its title implies, which is to create a "standalone" compiler for the desired Android ABI level, in my case, level 8, which corresponds to Android 2.2, yummy, yummy, Froyo. After running the script, add the new compilers to your path, and then congratulate yourself on having a fully functional Android C compiler and a somewhat less functional C++ compiler.

The remaining steps I'll just lay out by example because that will hopefully make it easier to follow and it's getting late and I want to go to bed.

Make one small change to the linux headers in the Android NDK. In the file {path-to}/android-ndk-r5/platforms/android-8/arch-arm/usr/include/linux/stat.h
Add the following two lines:
#define S_IREAD S_IRUSR
#define S_IWRITE S_IWUSR

just below the line that says:
#define S_IWUSR 00200

This fixes a dependency that gfortran has on a couple of deprecated symbols that have been removed in the NDK header files.

Make a directory to build all of the pieces:
(you can skip building gmp, mpfr and mpc if you have the devel packages for your platform installed already)
mkdir /opt/compilers/gcc/build
cd /opt/compilers/gcc/build

#Download and build GMP
wget http://ftp.gnu.org/gnu/gmp/gmp-4.3.2.tar.gz
tar zxvf gmp-4.3.2.tar.gz
mkdir gmp-build
cd gmp-build
../gmp-4.3.2/configure --prefix=/opt/compilers/gcc/android-8 --enable-cxx
make && make install

#Download and build MPFR

wget http://ftp.gnu.org/gnu/mpfr/mpfr-2.4.2.tar.gz
tar zxvf mpfr-2.4.2.tar.gz
mkdir mpfr-build
cd mpfr-build
../mpfr-2.4.2/configure --prefix=/opt/compilers/gcc/android-8 --with-gmp=/opt/compilers/gcc/android-8
make && make install

#Download and build MPC
wget http://www.multiprecision.org/mpc/download/mpc-0.8.1.tar.gz
tar zxvf mpc-0.8.1.tar.gz
mkdir mpc-build
cd mpc-build
../mpc-0.8.1/configure --prefix=/opt/compilers/gcc/android-8 --with-gmp=/opt/compilers/gcc/android-8 --with-mpfr=/opt/compilers/gcc/android-8
make && make install

#Download and build GNU Binutils 2.19.1 for the android target machine (newer versions will probably work just fine, maybe better)
wget http://ftp.gnu.org/gnu/binutils/binutils-2.19.1.tar.gz
tar zxvf binutils-2.19.1.tar.gz
mkdir binutils-build
cd binutils-build
../binutils-2.19.1/configure --prefix=/opt/compilers/gcc/android-8 --with-gmp=/opt/compilers/gcc/android-8 --with-mpfr=/opt/compilers/gcc/android-8 --with-mpc=/opt/compilers/gcc/android-8 --target=arm-android-eabi --with-sysroot={path-to}/android-ndk-r5/platforms/android-8/arch-arm
make && make install

Download the EXACT version of the GCC source that I used:

svn co svn://gcc.gnu.org/svn/gcc/trunk@168097 gcc-trunk

Download this patch and apply it to the gcc-trunk...

http://aeromonkey.homeip.net/public/ugly_gfortran_hacks.patch

cp ugly_gfortan_hacks.patch gcc-trunk/.
cd gcc-trunk
patch -p0 < ugly_gfortran_hacks.patch

With any luck this should get your GCC source tree into the same sad state that mine is.. sad, but functional!

Now move back out of the GCC source directory and create a new directory in which to build the compilers. If you've ever built GCC before, you know it is a very bad idea to build it in it's own source tree.

cd ..
mkdir build-android-8
cd build-android-8

Now you need to configure and build the compiler suite. This is the part that really took a lot of head scratching and googling since I had never built a 'cross' compiler before. I'll save you the pain of trying to explain what all of this means, so just copy and paste these lines, fix the {path-to} your Android NDK and you should be off to the races.

../gcc-trunk/configure --prefix=/opt/compilers/gcc/android-8 --disable-libquadmath --target=arm-android-eabi --with-gnu-as --with-gnu-ld --enable-languages=c,fortran --with-mpfr=/opt/compilers/gcc/android-8 --with-gmp=/opt/compilers/gcc/android-8 --with-mpc=/opt/compilers/gcc/android-8 --disable-libssp --enable-threads --disable-nls --disable-libgomp --disable-shared --disable-tls --with-float=soft --with-fpu=vfp --with-arch=armv5te --enable-target-optspace --disable-nls --with-sysroot={path-to}/android-ndk-r5/platforms/android-8/arch-arm

make && make install

This could take an hour or more to complete, but you can speed things along in the typical 'make' fashion by using a parallel build (assuming you are on a multicore box).. i.e.. on a quad machine..

make -j 4 && make install

Assuming you get this far, you can now compile and assemble code for Android, but sadly it will not run on the phone quite yet. This is where I nearly threw in the towel since I could get Fortran code to build, but it would segfault immediately if I tried to run it.. and when I say immediately, I mean before executing even a single line. After a great deal of effort I was ready to accept that I'm more of a code plumber than a trained programmer and that some tiny piece of the puzzle was beyond my grasp. That's when the engineer in me spoke up and said.. hold on, just take a step back, leave it alone for a day and try again tomorrow.

That next day I decided to try to get a better handle on what was going on behind the scenes with the compiler. To do this, I found a simple c program on the internet (btw.. it's amazing how many ways you can calculate the value of pi) and proceeded to build it with both the Android supplied and my newly minted c compilers and push it to the phone.

NDK compiler = success. New compiler = squat.

Now I broke things down a little further. I'm by no means an authority on compilers, but I did know that there are a number of stages that code goes through on it's journey from human readable (some languages less than others) to machine readable. These steps being:

Compile
Assemble
Link

I also knew that while all of these steps often appear to be taken by the single compiler executable (gcc, g++, gfortran, etc.), in reality, the compiler hands off the latter two steps to the 'assembler' and the 'linker'... sneaky little basterd.

This is where things get interesting... Not really expecting to get anywhere, I decided to start mixing and matching the components from the NDK with my new compiler...

NDK compiler + NDK assembler + NDK Linker ==> works.
New compiler + New assembler + New Linker ==> no good.
NDK compiler + NDK assembler + New Linker ==> no good.
NDK compiler + New assembler + New Linker ==> no good.
New compiler + New assembler + NDK Linker ==> WORKS!

Ok.. so that's the key. For some reason, the new linker is the weak.. uh. link.

After spending some time trying to reverse engineer the linker script used by the NDK linker, I just said forget it, I have something that works. Luckily, GNU 'makes' (wow, the puns just keep coming..) it really easy to use any linker you want when building code.. so, without further ado...

No, I didn't do the interface bits in Fortran, that's one thing Python IS good for on Android, at least for simple things like this... that and making it talk. FYI.. the Linpack for Android app available on the market only gets about 8 million floating point operations per second on my phone, which is close to what I got with the default compiler options. The 25 MFLOPS shown in the video was after optimizing for the Neon floating point unit in the Droid's Cortex-A8 processor. Makes me wonder how many other applications out there are not making very good use of the hardware.

Well. There's that then.

Longest post ever.

Meet Elmer, Part 2 .. or .. Everything's a Noodle

2010-09-24T23:23:00.000-07:00

Ok, so if you read my last post, you know already that I did something a little off of the beaten path for me by dabbling in a little thermodynamics with the Elmer multiphysics package. Now I'm going to get out the machette and really start hacking a new analytical trail for myself.

One of the most basic things that you learn in engineering school is that every solid thing that exists in the universe is flexible and that there are specifically two things that determine the amount of flexibility that a given thing will have. The first is the mechanical properties of the material that the item is made out of. The second and far more interesting is the cross sectional shape of said item. This is the reason I-Beams exist. It's certainly easier to manufacture and transport a hunk of steel as a solid bar, but you definitely don't want to build a bridge or sky scraper out of it. Even though the tensile strength of the bar and the beam are the same if they have the same cross-sectional area, the beam is much stiffer in bending. The engineering term is 'second moment of area' and I can tell you that calculating the stiffness of an arbitrary beam by manually summing moment areas is certainly fun and easy for simple shapes, but becomes not much fun quickly in the real world.

Even less fun than calculating the stiffness of a beam, but arguably even more important, is determining the vibrational modes of the beam. This is something that is nearly impossible to do by hand except for very basic shapes (like musical instrument strings), but is critical to understanding the ways in which structural deflections can become destructively coupled to external forces, like say, aerodynamic loads. One of the most famous examples of this, which most every engineering sophmore has probably seen, is the collapse of the Tacoma Narrows Bridge in 1940.

The engineers in the 1940's didn't have multi-gigaflop personal computers, but they were smart enough to design the replacement bridge well enough that it is still in use today.

Now that the history lesson is over, let's take my multi-gigaflop (about six I think) personal computer and see what we can do with it. As a first attempt to do this kind of thing with Elmer, I sketched up a 3D model of a simple wing or maybe a rotor blade depending on how you hold it. After a couple of attempts I got what looks to me to be a decent grid on the thing and put it through the linear elastic solver in Elmer to get the mode shapes, which took less than an hour of compute time on two processor cores.

The first four mode shapes for the structure when held rigidly at one end are shown with the surfaces colored by the displacement magnitude to help highlight where the biggest deformations occur. Fortunately, Elmer makes it fairly easy to animate the modes, making it much easier to see what is happening...

As you can see, the first mode is simple bending, while the higher modes start to represent more complicated deformations. It's funny to think that a seemingly solid object can take on such strange shapes, but it's very real.. and very scary...

Kind of looks like mode #3 to me, what do you think?

Meet my friend Elmer...

2010-09-20T16:10:00.000-07:00

One of the questions that I've been asked fairly regularly over the years is "Can you do thermal analysis?", and slightly less frequently, "Can you do structural analysis?". Both of these questions I've always answered with sort of a shrug and a non-answer, something like this:

"Well, I've had those classes in school, and I've worked with plenty of people in those fields... I guess a lot of the skills I've developed for Computational Fluid Dynamics should be portable to those problems."

Then I just sort of stand there reflecting on that until the person walks away scratching their head. After that, I usually feel motivated for a week or two to dig out my favorite non-CFD code, a 'multiphysics' package from Finland called Elmer.

As a multiphysics package, Elmer takes what I am going to refer to as a 'shotgun' approach to computational physics, by which I mean that they've implemented a couple of generic linear equation solvers for unstructured grids and then added the appropriate equation sets for different classes of problems, specifically fluids, structures, thermodynamics, electro-magnetics, and maybe a few others that I can't think of right now. This approach allows them to do some very cool things, like providing a common interface for all problem types and letting the user string solvers together to do multidisciplinary studies fairly easily. The downside is that since there are so MANY things that can be done with it, there is a correspondingly small amount of validation to go along with all of that capability. Fortunately for me, I've got a lot of work to do to validate myself for thermal and structural analysis, so it suites me just fine.. :)

Round 1: Thermal

I had done some rudimentary heat transfer in Elmer a few years ago, so this time around I wanted to do something a little more complex. I build the CAD model below with the express intention of making Elmer choke on some geometry with things like thin surfaces, intersected fillets and generally just odd shapes.

I think I pulled something like this out of a lawn mower when I was a kid.

Amazingly, the NETGEN plugin for Elmer didn't even break a sweat on this thing and I had a usable grid with only a couple of tweaks to the gridding parameters.

Setting up the thermal solver and applying boundary conditions was similarly pain free.

The steady state solver ran almost instantaneously on my laptop.

The transient (time accurate) solver took about twenty minutes.

Based on the results from the steady state run, I didn't let the transient case go long enough, but you get the idea.

All in all, I was amazed at how easy it was to get this done. I used to work with a guy who did finite element thermal analysis BY HAND USING GRAPH PAPER AND A CALCULATOR! I remember trying to help him get up to speed on one of the commercial 3D thermal codes and feeling sort of bad for him that the world seemed to be making his skill set obsolete faster than he could keep up with it.

Makes me genuinely happy to have grown up in the Atari generation.

Coming up in Round 2, I'll try to talk my friend Elmer into doing a structural mode shape analysis for me...

Down the Armadillo Hole

2010-09-13T16:00:00.000-07:00

Several months ago I asked Russ at Armadillo if it would be OK if I dropped by to check out the operation down there in Texas since it was not too far of a drive from central Oklahoma. He said anytime would probably be fine, so two months later the planets were all lined up and it was finally a good time to head down.

After backing up all the data on my laptop, I hopped in the family Jeep at about 7:30am and headed south down I-35 out of Norman. Not wanting to make things too easy for myself, I didn't do any real travel planning whatsoever, so my first challenge came when I attempted to figure out exactly what to do once I hit 35-E north of Dallas. About thirty minutes south I selected the navigation function on the nifty new Motorola Droid that I had suction cupped to the windshield and then waited for it to get a GPS signal. After five minutes of waiting I decided to just re-boot the phone and see if that helped, which it did, getting GPS immediately.

At first I attempted to use the 'Speak Destination' function that looked so cool in all the Android marketing demos..

me: "Navigate to Armadillo Aerospace"

droid: (searching for destination)...
droid: "Finding directions to Amarillo Airport"

me: "Umm..." (re-pushing search key)
me: "Navigate to ARMADILLO AEROSPACE"

droid: (searching for destination)...
droid: "Finding directions to Armadillo near Aerodrome Road, Barnet, UK"

me: "Are you for real?" (pushing type destination key)
me: (entering destination with on-screen keyboard)

droid: (searching for destination)
droid: "Did you mean: Entek Corporation, Norman, OK"

me: "..."
me: "No, I did not." (turning off navigation)

At this point, I decided it would be safest to stop for breakfast and enter the address manually. Ten minutes later, Egg McMuffin in hand, I was on my way. Luckily I had verified the address the day before since the address listed on the Armadillo web page is for their business office, not the hangar, which is where all the fun is.

Three hours later I was driving east on I-30 out of Dallas (which has a very scenic stretch for several miles across lake Ray Hubbard) when my phone disabled it's navigation feature to inform me that there was a phone call incoming. After releasing the phone from it's cradle I held it to my ear to find Russ calling to make sure I had the directions and was still on schedule. When I mentioned that I was using GPS he informed me that most people who come in that way end up at the sky diving school on the other side of the airport. After hanging up I looked a little closer at the route and it appeared that I was going to the correct hangar, so I kept on that route.

At this point the Okie in me can't help but complain about the way Texas dispenses with the apparently dreadful task of coming up with creative names for large portions of it's roadway system. If I had to find Farm to Market Road 1565, between County Road 2620 and County Road 2624 without GPS, I would probably still be wondering around out there right now.

View Larger Map

As I pulled up to the open hangar, I immediately knew I was in the right place when I saw the giant crane truck parked inside. Anyone who has spend much time reading the Armadillo status updates should know that truck well!

After parking the Jeep next to some other cars on what I thought was the front side of the hangar, I pocketed my phone, grabbed the laptop bag and walked into the hangar fully expecting to be met at the door by Russ or some of the other guys working there. Instead, as I walked in, I got the distinct impression that no one was home. There was plenty of hardware stacked in various places, along with the crane truck and a small single engine airplane, but not a person in sight.. and it was eerily quite as well. So, after stepping in a few feet, I noticed a nondescript door just to the left that I had not seen when I walked in. Without a clearly marked door bell or a sign saying 'Visitors please check in with security', my only real option was to open that door and peek inside. When I did, I immediately noticed Pixel, one of their lunar lander contenders, sitting directly in front of me. Encouraged by that, I walked in a little more and then turned right, following some tape lines on the floor. At this point I finally saw two people busy working on the base of what could only be a heavily modified Super Mod. They were so busy in fact, that I walked right up to them and stood their for a minute before one of them even noticed me. When he did notice, it was obvious that he had no idea who I was or why I was there, but he was nice about it and asked if there was anything he could do to help me, so I introduced myself and he goes, 'oh yeah, the aero guy... Russ should be down in a minute.', after which he did exactly what I would have done in that situation and went right back to work.

As promised, Russ came down to the shop floor after a minute or two and made the introductions for me to the fellows working on the Mod, James and Joe, along with Phil, who had come down to the shop as well. After a quick discussion about the changes to the Mod, Russ invited me upstairs to tour the office section of the facility and to meet the rest of the crew. Upon entering the office area, I was immediately impressed by the spartan furnishings and no nonsense appearance of the place. The feeling of 'organized chaos' that I was getting on the shop floor definitely continued into the offices... and believe me, this is a good thing. I've spent quite a bit of time on the shop floor at larger aerospace companies and I can tell you that while I understand many of the reasons why big companies operate the way that they do... multiple management layers, design reviews, drawing checkers, quality assurance specialists, union rules, etc... seeing an operation without all of that really highlights the sheer overhead and operational inertia that all of those things bring. I sincerely hope they can find a way to preserve as much of that agility as possible as the organization grows!

After lunch (Chicken Fried Steak!), we went back down to the shop and talked a little more about the things that are in their pipeline right now. I'd love to share some of those projects here, but most of that will end up on the AA site at some point in the future, so I won't steal their thunder except to say that there is a lot more happening than I was aware of and I'm excited to see where it all goes. One thing I will mention is that I had a nice conversation with Russ about Pixel. Some time ago they delivered Pixel to NASA as a test platform for some of the technology that was being developed for 'Project M' which included JSC's Autonomous Landing and Hazard Avoidance Technology (ALHAT) package, which itself included components that had flown on the Space Shuttle, so that was interesting to see. I am just guessing here, but I would bet that Pixel has more flight time than any other rocket powered vehicle that's ever been built. It was great fun hearing Russ talk about how well they've gotten to know that one machine and how much of a 'personality' it has developed.

I think it is worthwhile to mention that these guys obviously care a great deal about their hardware and that is probably one of the biggest keys to their current success. Before going down there, it seemed reasonable to me to assume that their build-fly-break-rebuild design cycle meant that the things they built were essentially designed to be disposable and that they probably didn't care too much when one of their vehicles bit the dust. I now know that could not be further from the truth!

Anyway, I could probably write several more pages, but I think this is running a little long already. All in all, I had a great time, learned a lot, hopefully contributed a little, and I am looking for ward to seeing what they come up with next.

Left to right: Recent Masten Space Defectee Ben Brockert, Me, Joseph LaGrave,

Pixel, Russell Blink, James Bauer and Phil Eaton

Scorpius Part 2

2010-07-16T17:38:00.000-07:00

I actually feel sort of bad about this, since my last post was a bit of a teaser, promising something that I probably could have just written up the next day and been done with, but instead, I put it away until today and now it doesn't seem nearly as interesting to me. Anyway, here is my attempt to address some of the aerodynamic problems with the Scorpius module. Pop on a nosecone, tuck in the helium tanks, streamline the landing gear and add a basic boat tail fairing and you get something like this...

Now this is really just a sketch. If I put in some serious effort, the end result would probably be quite a bit different. That's the way I like to work. Given a reasonably clean simulation workflow, it doesn't make a lot of sense to spend a great deal of time upfront doing hand calculations when you can just build a model, run the simulation and then use that as the basis for the next iteration. This is actually what Armadillo has been doing all these years with real hardware and is why they are where they are today.

With that in mind, let's see how the new design stacks up. One assumption that I'm making here is that the dry mass of the design is unchanged. I don't think this is actually a bad assumption, since the new landing gear would be significantly lighter (and more delicate). Keeping the mass the same also makes it an apples to apples performance comparison with only the aerodynamics being different.

So, we've gone from the original 44,000 feet to a respectable 56,000 feet with the first cut at reducing the drag of the vehicle... That's a 27% improvement, not too shabby I say.

If we look at the calculated drag coefficient over the flight it looks like this..

We did good for most of the flight, but at least on the surface it looks like the original design isn't so bad over the portion of the flight between about 50 and 70 seconds. As Paul Harvey was fond of saying, here's the rest of the story...

In reality the drag reduction is substantial over the entire range of flight Mach numbers, with the orignal design stubbornly refusing to cross the sound barrier, while the revised design manages to get to nearly Mach 1.2. The reason the drag seems similar or somewhat higher for portions of the trajectory is that the new rocket is traveling faster (and higher) at the same moment in the flight and is seeing higher Mach numbers earlier in the flight. Fortunately, the higher velocity translates into higher altitude at engine cut off and an extra 10 seconds or so of coast to apogee.

Some might say that this is just a computer model, so I could probably turn knobs to get whatever numbers I want. To those I people I say... well, um, yes, there are plenty of knobs to turn, but in this case I made sure I didn't touch any of them when I set up the new simulation. Seriously though, talk to anyone who does any sort of analysis or testing, whether it is in a lab, wind tunnel, or on a computer... and if they are being **brutally** honest, they will admit that there is a lot more uncertainty in life than anything less than life can capture.

There is not an airplane on the planet that has an absolutely known drag coefficient, or a structure that has an absolutely known ultimate failure load, or a Twinkie with an absolutely know shelf life. In practice, it is the deltas that are the most important... and a good engineer is one who can nail those deltas, no matter what their tool of choice happens to be.

So, before I break off those knobs and push my work out into the world, I'm going to be as sure as I can be that the deltas are right.

Pedal to the Metal for Scorpius

2010-05-03T14:51:00.000-07:00

I've decided to start as many posts as possible with a nice picture..

Now that I know I'm not going to get that awesome machine from AMD, I'm ready to get back to business. By that I mean putting my Scorpius 'mock-up' model through it's paces for a complete trajectory analysis. In the process of pulling together all of information that I needed to move forward, I contacted Russ Blink over at Armadillo about possibly sharing some more details on the design. Happily for me, he graciously agreed to help me out.

Here are the final numbers that I put into the trajectory solver:

Vehicle parameters:

Empty mass : 550 lbm
Payload mass : 0 lbm
Propellant mass : 1250 lbm
Reserve Propellant : 200 lbm
Engine Vacuum Thrust : 3800 lbf
Engine Vacuum ISP : 210 seconds
Engine Chamber Total Pressure : 240 psia
Engine Chamber Total Temperature : 5500R
Engine Chamber Gamma : 1.23
Engine Nozzle Expansion Ratio : 4.0:1

Trajectory parameters:

Starting altitude : 0 ft msl
Starting velocity : 0 ft/sec
Atmospheric model : 1976 Standard Day

Flow solver parameters:

Solver : NASA FUN3D v10.8.0
Model size : 770,000 nodes
Turbulence : Spallart-Almaras 1-equation model
Iterations per solution : 800

I admit that I was a little surprised at how heavy the Scorpius mod was. If you've read my previous post on the trajectory for the six-pack then you'll notice that my estimate for the dry weight was probably way too low. I was also very generous on the engine performance, so I'll go ahead and state that 150kft for that design is probably not too realistic. Still, it was a nice excercise.

Running on 16 processor cores, this trajectory took about a week. It also helped me identify a serious side effect of putting a video card with a passive heat sink right next to a gigabit ethernet card. On a couple of occasions, the tx transmitter on the card locked up (at least that's what the linux kernel logs reported) and caused the solver to abort. Since this didn't happen before the new video card was installed, I'm guessing that the network card doesn't like being blasted with infrared radiation for long periods. I've since replaced that card with a similar model sporting a fan, so hopefully the problem will not resurface. The passive card with it's offensive heat sink is currently overheating components in my wife's Ubuntu PC, which I can now use to finally finish playing the Linux port of Doom 3.(update.. the problem persists, now we're going to try swapping that network card with one from a slave node, ugh.)

The highlights from the trajectory are:

The altitude at apogee is 44,000 ft
The maximum Mach number is 0.98 at engine cut-off at 36770 ft
The maximum drag force of 2807 lbf occurs at 34,000 ft at Mach 0.95
Total engine delivered delta-V = 6028 ft/sec
Total gravity delta-V loss = 2847 ft/sec
Total aero drag delta-V loss = 3181 ft/sec

The first thing that jumps out at me is that the delta-V lost to drag is significantly higher than the gravity loss. Surely there is some room for improvement there!

I feel like I should re-iterate that this is a 'mock-up' of the Scorpius design and while I am using the best information available to me, there are plenty of places where this model deviates from the actual hardware and where the computational model needs refinement. That being said, I would bet this is much closer than what could be done with Datcom type analysis or by using existing drag data, no offense Dr. Hoerner..
Now, I'll freely admit that Missile Datcom is much faster, more refined and can provide far more design data (especially stability and control inputs) than I am currently mining from my own simulation. However, this is really only true for relatively simple, 'conventional' shapes. If I thought that those methods were sufficient for the wide range of designs being tossed about for sub-orbital vehicles, I probably wouldn't have bothered with all of this.. ;)

Another interesting plot from the trajectory is the 'sensed' acceleration on the vehicle. This is what would be felt by a passenger, in this case we'll assume a mosquito stowed away in the avionics bay.

Now the acceleration is fairly mild while the engine is on during the boost phase, with the increasing aero drag keeping pace with the dwindling mass of the rocket and actually causing a net reduction in the total acceleration as burnout is approached. Unfortunately for our little stowaway, when the engine shuts off the drag force slams on the brakes with an instantaneous, eye-popping, 5g reversal. In reality the engine could be brought down gradually to reduce the jarring nature of the shut-down, but this would still be an unpleasant experience for most anyone (or possibly the highlight of the ride for some I suppose).

If anyone is interested, I've also broken the drag coefficient down per component at Mach 0.98, right at engine cut-off:

Nosecone : 0.1154 (11.1%)
Fuel Tank (fwd) : 0.4354 (41.6%)
Oxidizer Tank (aft) : 0.0308 (3.0%)
Helium Tanks : 0.0915 (8.8%)
Engine Cover : 0.0365 (3.5%)
Chamber/Nozzle : 0.0032 (0.3%)
Landing Gear Feet : 0.0678 (6.5%)
Landing Gear Struts : 0.2634 (25.2%)
Total : 1.0440 (100%)

It should be obvious where the attention needs to be paid as this design is refined to improve it's aerodynamics, with the nose cone and upper tank bearing more than 50% of the total force. The landing gear are also working hard to keep the rocket firmly planted on the ground, contributing over 30% of the drag.

That's about all I have time for right now... Here's a little sneak peak at an image that will start off a future post.

I'm not sure if it will be the next post since I still have a few things to say about the current design, but I'm getting far enough along on some modifications that I am itching to share those soon.

Also.. the NASA Global Reference Atmospheric Model just showed up in my mailbox, so I'm sure I'll have some things to say about that as I work to wrap it in a cozy blanket of Python so it can called from the trajectory solver. When that is done, I'll be able to include seasonally accurate winds aloft for just about anywhere on the planet, which is nice.

What Would I Do With 48 Cores?

2010-03-24T20:31:00.000-07:00

I happened upon this AMD contest a couple of weeks ago and decided to have a go at it. The gist of the thing is to promote AMD's as yet unreleased 12-core monstrosities by having people describe some of the nifty things that they would do with that kind of number crunching horsepower. Since my current computational cluster grinds away with 18 AMD cores, I think the additional 48 would find themselves right at home helping me put virtual rockets into sub-orbital space.

I've been using mostly AMD processors for my personal machines since I bought my first motherboard with a 40Mhz Am386 and 1MB of RAM around 1993 or so. Through the years I've built K-5's, K6's and K6-II's.. I've over-clocked (and ruined) K6-II+ and K6-III's... I literally cried at the end of Socket 7... and then cried some more at the introduction of slot processors, then abruptly stopped crying again when Socket A came along, after which I ... over-clocked a Duron 600 to 850MHz (or so) using the 'pencil trick', under-clocked a faulty 1Ghz Thunderbird to 800Mhz.. soldered a variable resistor onto the Thunderbird's motherboard voltage regulator so I could jack up the voltage, after which it was solid as a rock at 1Ghz for years after... and then made a 1.8Ghz Thoroughbred my primary home processor for more than five years.

Not to mention the cluster, of course.. :)

This gives me what I think is a reasonably complete understanding of what has put AMD where they are today.

In addition, the literally thousands of Computational Fluid Dynamics simulations that I've run over the last dozen years or so gives me a reasonably complete understanding as to why the scientific computing community has leaned so heavily on their hardware. I've run simulations and benchmarked machines with one core, all the way into the thousands, with interconnects from IP stack bypass ethernet to Myrinet to Infiniband, using commercial, government, and open-source flow solvers built with both commercial and open source compilers...

The truth is, I'm a tuner at heart and I love pushing hardware past it's limits, whether that hardware burns gas or electrons... and I'd like nothing better than to find (and surpass) the limits of this new AMD beast.

Finally, here is a bulleted list of reasons AMD should hand over the hardware with all speed:

I'm getting 65% of ~~theoretical maximum~~ ideal linear speedup with 8 dual core Athlons on single motherboards with gigabit Ethernet using the MPICH-2 Nemesis channel.
I tested a 16 core (quad-quad) machine last year and could only get a little better than 50%, with shared memory MPI on HyperTransport!
I'm skeptical that I will see much better than 50% on a 48-core single board machine, even with more and faster HyperTransport links.

Not much of a list really.

Bottom line..

Give me that machine and let me prove myself wrong!

... now if I can just find someone to pay for 48 gigs of DDR3 ... ;)

Me (top right) with Dad (Mike Sr.) and brother Matt

I only want to do this once... per simulation.

2010-02-27T17:25:00.000-08:00

Charts, graphs, spreadsheets, databases... those are the primary tools that an engineering analyst uses to communicate their work with the people who need the information. As useful as those things are, they don't provide the impact of a good visualization...

There is also often a legitimate need to dig into the solution to find sources of error, or to adjust the model to capture physical features that might not be resolved without some attention.

Getting a good visualization can be an extremely challenging problem in it's own right, so that is why I have put most of my efforts over the last few weeks into adding an automated visualization capability to the trajectory solver. The key to this effort has been the excellent open source visualization package ParaView, which has been my primary visualization tool since I stumbled upon it several years ago while spending some time with the OpenFoam package (that's a story for another time).

One of the great things about ParaView is the fact that it was designed from the ground up to run under Linux, which is something that makes me very, very happy, since Linux has historically received fairly short shrift from the 3D graphics community, and there are precious few apps that you can reference when trying to convince your friends that hardware accelerated 3D is alive and well in the open source community.

Unfortunately for me, the head node on my CFD cluster is currently making due with integrated ATI Radeon HD3200 graphics, unlike my laptop, which sports a much better supported (and, like it or not, proprietary) Nvidia 9700M graphics card. Even though I built ParaView from the same source on both machines, I am getting a very impolite segfault on the ATI hardware when I use certain rendering functions. This means that until I upgrade the graphics card in the head node (sometime in the next couple of weeks), I can't get the set of images that I would like to have for the entire trajectory.

The good news is that, once that minor glitch is resolved, then, through the magic of ParaView+Python, I will be able to define any arbitrary view that I want, save the ParaView state file, and then feed a stack of those to the post-processor and get a nice bunch of images to show off later.

One more small step toward the master plan...

Ground Control... we have a solution, for a six-pack.

2010-02-05T21:41:00.000-08:00

This has been a long time in the making, so without further ado...

Tada!

Almost looks too simple considering all that went into it:

Over a year of (admittedly low priority) labor
2000+ lines of Python
Many, many false starts
106 Flow solver runs
1200+ CPU hours

Of course, that's not the whole story. For the whole story I need to violate my previous declaration that I wouldn't post any actual rocket performance data out here in the wild. The reason I'm comfortable violating that declaration is that this isn't an 'actual' rocket and it certainly wouldn't make a very efficient weapon in any case. Not to mention the fact that all of the data that went into the trajectory calculation was fabricated completely by me without much effort at all, so is more than likely not even close to what Armadillo Aerospace is actually building... and, while I'm not mentioning that fact, I'll also not mention that this design isn't even on their drawing board anymore as far as I know.

So here are the raw materials:

Vehicle parameters:

Empty mass : 670 lb
Payload mass : 200 lb
Propellant mass : 6500 lb
Reserve Propellant : 500 lb
Engine Vacuum Thrust : 1800 lb * 6 Engines = 10800 lb
Engine Vacuum ISP : 250 seconds
Engine Chamber Total Pressure : 165 psi
Engine Chamber Total Temperature : 5500R
Engine Chamber Gamma : 1.25
Engine Nozzle Expansion Ratio : 2.5:1

Trajectory parameters:

Planet : Earth (seriously, the earth is now a Python module)
Starting altitude : 0 ft msl
Starting velocity : 0 ft/sec
Atmospheric model : 1976 Standard Day
Integration time step : 0.01 seconds
Plotting output time step : 0.25 seconds

Flow solver parameters:

Solver : NASA FUN3D v10.8.0
Model size : ~ 1 million nodes
Turbulence : Spallart-Almaras 1-equation model
Iterations per solution : 500-800

As your reward for reading all those numbers, here are a few more charts...

Yeah, I know... charts are sweet.

Before you take out your ruler and start trying to pull numbers, I'll save you some trouble:

====================================

T-plus at engine cut-off = 138.89 sec

Altitude at engine cut-off = 96824.6 ft

Mach number at engine cut-off = 2.46

T-plus at apogee = 194.37 sec

Altitude at apogee = 149988.8 ft

Max q = 252.3 psf : T-plus = 87.22 sec : 32480.7 ft

Take-off weight = 7366.7 lbm

Take-off thrust/weight = 1.25

Total dV delivered by engines = 12893.6 fps

Total dV lost to gravity = 6227.5 fps

Total dV lost to aero drag = 6666.5 fps

====================================

Here is a rendering of the flow field just before engine cutoff when the exhaust plume is at it's widest.

And because ParaView kicks ass, here it is again... IN 3D!!!

So there it is... 150k feet, nearly half way to space, and I promise I didn't have any idea going in that is where it would end up.

That's the whole point of this exercise anyway, to develop a tool that can produce accurate trajectories for sub-orbital vehicles without all of the empirical guesswork and expensive wind tunnel testing that is needed right now. Of course there is still plenty more to do, but the core is there and looks to be functioning correctly.

...more to come

What the bleep is a SSTSO!?!?

2009-10-03T22:16:00.000-07:00

Ok... I was having a conversation with a friend about the best way to waste loads of time while simultaneously not enjoy one's self in the slightest. After some discussion we came to the conclusion that a perfectly sensible way to accomplish this would be to build a proof-of-concept rocket using as much off-the-shelf hardware as possible. Mind you, we're talking about some pretty hard to reach shelves.. you know, the ones that have those little signs that read "please ask a sales associate for assistance with items on this shelf"...

Ultimately the shelf that I ended up dangling with my pinkie fingers from while the store manager makes a frantic call to the company lawyer is a shelf with a jet engine on it. "A jet engine?" you ask, not really caring to hear why, but knowing that I'm going to tell you anyway. Yes, a jet engine, because the concept that our proof-of-concept vehicle aims to prove is the "Single Stage To Sub-Orbit". There it is.. the SSTSO in the flesh, or more likely, in the graphite and phenolic honeycomb.

If you read much SSTO literature, you are bound to come across the idea of taking a portion of your oxidizer for free from the atmosphere. The goal of course is to take advantage of the (in rocket terms) obscenely high Specific Impulse (ha!.. I said it!) of air breathing engines to get off the ground and up to a reasonable altitude before firing conventional rockets for the boost out to apogee, theoretically getting the job done with a much cheaper, safer, sexier vehicle that you might even be able to fly home in, gas back up and make a return trip to the space station to grab that iPod you accidentally left in the Japanese science module.

When compared to conventional staged rockets you get bogged down in the reality of the problem almost immediately:

You are carrying useless air breathing engines for 90% of your flight
You now have to design both an airplane and a rocket
You are carrying substantial additional structural weight
Re-usable does not always equal cheaper

That last point is a big one for orbital launchers. I like to think of cigarette lighters as a pretty good analogy. Imagine a $20 mail ordered Zippo playing the part of the Space Shuttle and a $2 Bic disposable playing the part of say, any other operational launcher. The Zippo features excellent craftsmanship, let's you re-fill it and replace the flint, and it lights even when it's windy. All your friends admire the nifty titanium nitride coating and the eagle's head laser etched into the side. Now imagine if you had to re-fill the fuel and replace the flint every time you used it. Not only that, but you can't re-fill it until you clean the soot off of it, not just around the flame holder, but everywhere, even around the pin that holds the flint wheel... and that requires a special tool to replace. Not only that, but those replacement flints that were supposed to come from multiple suppliers for pennies now cost dollars because Zippo didn't make enough of that particular model for there to be a competitive aftermarket.

That Bic is starting to look pretty good!

Of course that brings me back to the "SSTSO", which is much more attainable in a re-usable platform. Suddenly you are talking about a vehicle that can meet it's mission objectives with a much lower propellant mass fraction. This opens up various avenues for using that additional weight... You didn't think I would get into that now did you?... well, suffice it to say I've got a couple of friends who are smarter than the average bear. At least I think so. We've got an idea or two, and I'm going to be sharing one of those ideas with you soon...

Mike

Rise of the Scorpius...

2009-09-24T13:42:00.000-07:00

In case you haven't heard, Armadillo Aerospace recently qualified to win the 'Level 2' Northrop Grumman Lunar Lander Challenge, worth a cool million to them if no other team can produce a better flight before the end of October. They did this with an upgraded modular platform that they are calling the Scorpius Super Mod, which among other things sports lighter landing gear, lighter helium pressurization tanks and a few engine tweaks. Video of the full flight is on the AA blog here:

http://www.armadilloaerospace.com/n.x/Armadillo/Home/News?news_id=368

Here's a screen grab I took from one of the videos...

Naturally, when I saw this, I had to build a model of it and run it through my simulation tools...

Before anyone complains about how rudimentary the geometry is... I only put about an hour into creating the CAD model for this thing. It's really just a sketch based on what I've gleaned from AA's blog postings and a little guestimation from looking at the pictures. No, I didn't take calipers to any of their images, which should be obvious from the landing gear splay angle.

Seriously though, it was about three hours from when I picked up my mouse to when I had the flow field meshed and ready to run in the solver. The next morning I had a nice set of plots at engine pressure ratios up to 6000 and speeds up to Mach 2...

Of course, I'm not expecting them to fly this thing to Mach 2 or to an engine pressure ratio that corresponds to well over 100,000 feet altitude, but it's easy enough to turn these knobs, so I usually crank them as far as they'll go :) .. incidentally, the solver did crash when I tried to raise the engine pressure even higher. I didn't look too closely at the solution, but we'll just assume that the engine plume reached the downstream boundary where the simple supersonic extrapolation broke down... I'll ding both NASA for the robustness of their boundary condtions and myself for not extending the flow field further downstream.

In case anyone is wondering, this is a fully 3D, viscous, compressible solution on an unstructured mesh. The solver is finite-volume, node centered, second order accurate and is using the Spallart-Almaras one equation turbulence model with no wall functions. I'll buy a moon pie for whoever can guess which NASA flow solver I'm using... (Some exclusions apply. NASA employees and their immediate family members may not participate. See back of package for full contest rules.)

On the down side, the solver is using a single perfect gas model throughout the entire flow field, potentially introducing inaccuracies in the exhaust plume shape, temperature and engine mass flow. Michael Aftosmis at NASA Ames has put together a nice discussion on modelling rocket plumes with his inviscid Cartesian mesh code, Cart3D, that touches on some of these issues. I've looked into the mass flow error in the past and it seems to fall in the 10-15% range when using a working fluid with a gamma of 1.4 for the engine where the actual gamma is going to be in the 1.2-1.3 range depending on the propellants and engine design.

After I got back the initial solutions, I wanted to have a better look at the Mach diamonds in the plume at sea level ambient conditions, so I re-meshed the model, putting a lot more resolution downstream of the engine nozzle.

How very nice!

Unfortunately even with the increased mesh resolution, dissipation of the plume occurs more quickly than it should. To my knowledge this is unavoidable with low order solvers, especially on tetrahedral meshes. More refinement would definitely help, but isn't really worth the extra effort at the moment. I'll have to make a note to post some of my experiences with the mesh-budget/solution-time/solution-accuracy trade space, but for now suffice-it-to-say that given my computational resources, I don't have the luxury of putting the kind of resolution around the whole vehicle that I would like.

That's all for now.. thank you for your time!

Blast Off!

2009-04-01T10:10:00.000-07:00

Here is something I've been working on for a while in my spare time... The video here shows the results of a simulation that I've been working on using software that is freely available to U.S. Citizens, along with a simulation framework that I'm developing to automate most of the tricky stuff. For what are hopefully obvious reasons, I won't be including any hard vehicle performance data on my blog, seeing as there are so many uses for rocket design simulations that don't involve communications satellites and space tourists.

The vehicle in the video is my interpretation of one of the rockets being designed at Armadillo Aerospace. The reason I chose this vehicle is that Armadillo has been extremely open and transparent about their efforts out in the Dallas suburbs so there was enough publicly available information for me to construct a reasonable model for the simulation.

Thank you John Carmack!

The ultimate goal of this work is to tie a high resolution aerodynamic model to a sub-orbital trajectory integrator (that I am also writing), allowing rapid performance estimation and vehicle force and moment calculations for these kinds of launch vehicles in the preliminary design stages, before a large investment is made building and testing actual hardware.

Why am I doing this?.. great question seeing as I'm no longer employed in the rocket industry and my current work is squarely centered around aircraft.

Well, I really like rockets.

Honestly, there aren't too many other fields where you are almost certainly going to witness the fruits of your labor go down in a fiery heap in the desert somewhere. As an engineer, that is a powerful thing, playing against the odds that you've managed to build something that can harness such massive amounts of energy to produce a controlled movement of a heavy object from Point A to Point B, or in the case of the sub-orbital crowd, Point A to Point A with a short period of weightlessness in between .

After the X-Prize competition was won by Scaled Composites with Spaceship One there was a huge flurry of activity in the space tourism field, or at least what was considered a fledgling field at the time in 2004. Unfortunately, that initial enthusiasm has waned and the participants have either abandoned their efforts or been severely curtailed by the realities of the problem or in the case of Scaled Composites a tragic accident at their rocket test facility. My sincere hope is that some of these efforts will eventually bear fruit and with any luck I'll have found a way to make my mark on one or more of them.

And no, no-one is paying me to do this, atleast not yet.. ;)

I've just seen, in the course of my work, a really interesting problem that I believe I have access to the tools to solve and this is the result of that effort. It is certainly possible that I will pursue some sort of commercialization in the future if there is sufficient interest in the community, but for now, it's going to serve as a back burner distraction that I will do my best to make sure doesn't interfere with my other obligations as a father, husband and engineer.

btw.. I know what day it is.

Where the Beefalo roam...

2009-01-13T21:55:00.000-08:00

A couple of years ago, I was sitting at my desk thinking about where I was in my career as an aerospace engineer and how I managed to get there. What seemingly small decisions or temporally insignificant movements had put me into the situation in which I had found myself... nearly 10 years out of school, in my fourth job since graduation, happy that I was doing something interesting, but worried that it was not going to last nearly as long as I wanted it to. At the time I didn't really reach any kind of conclusion as to what sort of internal motivational forces were acting on me and why I couldn't seem to stay in one place for more than a few years at a time.

You see... in the past, I've never been too concerned about how I got to a particular place, I'd just be enjoying the ride. Now I am in my mid-to-late (..cough..) thirties with a wonderful, beautiful wife and another wonderful, beautiful little baby girl, so yes, I suppose I have good reason to be concerned about a resume that is starting to look far too fragmented and not nearly what I had thought it would be at this point in my career.

So, here I am, in sunny, windy Ooooooklahoma, trying to find some greater purpose in the last four years that I've spend helping design a rocket that will probably never be built and trying to chart a course for my budding little family into an uncertain future... stick around if you'd like to see how it turns out.. ;)