Biographical Information.
Home Page
- July 1,1963
- I graduated from the University of Utah with a degree in physics
and went to work for General Electric at the
Hanford Atomic Energy Site
in Richland, WA
. This was a goal from the sixth grade. I reported to work on July 1, 1963.
I was married to my first wife and was moving outside of Utah for the first
time. There was a lot to do. They were very heavy into developing peaceful
uses for the atom and everyone worked weeks straight from the Microsoft Urban
Legend stories, i.e., 60 hours and just starting. We went from keeping our
own cross section library to using the National ENDF/B set. For a long time,
ours was better because it had just enough data where as the ENDF/B set had
too much. The side effect of having too much data was a bad prediction of
when a container would go critical and a really bad prediction of burn up
characteristics. Computers kept getting better. You probably can't imagine
the difference between the computer we started with (IBM-7090) and the one
we finally ended up with (CDC-7600). I think the processors on the hard drives
are faster in 2000, than the cpu's were for some of these old "Supercomputers".
These changes provided many opportunities to improve the equations used to
predict a systems behavior. It was a challenging time for all. It didn't
pay to use the most detailed mathematical models when you could not wait
that long for your first solution. The people were what I called practical
perfectionists. Just as soon as we had access to a new, faster computer,
they would improve the equations. The problems ended up using the same amount
of CPU time but were doing much more.
-
- Each new system would add capabilities that could introduce awesome
performance increases. You didn't always know how much of a boost certain
features would provide and this always provided a few surprises. For example,
about the time the first Univac 1108 came in, we suddenly had access to a
computer system that really supported direct access of data on a rotating
mass storage device. The really fast Univac drums rotated around 3600 rpm
and had 432 floating heads. A typical access time was around 8 ms, which
was pretty awesome in 1966. The problems was their size, which was around
256K words. Many modern disks have more on board cache. The average access
time was something that fast disks didn't match until the late 1990's. In
order to take advantage of the new hardware, I developed a KISS simple database
that permitted data to be stored on magnetic tape, large, slow drum storage,
or small, fast drum storage. Dr. John Carter added my database to a program
called HRG and it suddenly ran 20 times faster. If the data was on tape or
slow drum, everything that was read was stored on fast drum. You never rewound
the tape. In order to read a record, you would set a flag and the system
would read the data record directly off of the fast drum. It was random
access I/O at it simplest. A typical problem would run for 90 to 135 seconds.
We discovered at a later point that all but 5 to 15 seconds of the time you
were billed for was manipulating the data from the magnetic tape. This was
long before multi-tasking OS'es were introduced and you were charged for
wall clock time. When he ran his first full set of verification test cases,
he thought something was broken because he was able to run all 20 of them
in a little more than 2 minutes. He checked everything and all of his problems
had run successfully. We figured that we had REALLY learned something that
day.
-
- April 14, 1981
- I had not been married for some time and I figured it was
time for a change. Funding was changing and the projects I was working on
were not as consuming as the earlier ones were. There was one singularity
in there and that was the Hanford Cancer Mortality Study. I did the programming
on the first major statistical report published by Battelle. It was very
interesting to watch an honest statistician develop data. By honest, I mean
someone without an agenda to prove something. For example, if you want to
prove that radiation is harmful, all you have to do is look at local deaths.
No one dies from cancer on a business trip and this spikes the death rate
for the local area. When you add the deaths from the complete work force,
the death rates for long term illnesses drops significantly. In the case
of the first report generated by the Battelle Statistician the calculated
death rate was 0.8 of normal. This caused some concern until the Harvard
Professor that wrote the program was contacted. He stated that a pre-employment
physical was used. Because of the pre-employment physical, the other 0.2
portion of the population was never hired resulting in a much lower death
rate. Since that time, there are people that were routinely exposed to radiation
that are developing cancer. What is different between them and the down winders
is the occurrence of leukemia. The down winders were developing cancer but
not leukemia, which seems to be a precursor of radiation induced cancer.
There are cancer belts in the USA's corn belt, which people assume to be
chemically caused. There is a chemical for everything and especially pesticides.
It wouldn't surprise me to find the down winder's cancer's are associated
with their long time exposure to farm chemicals.
-
- I resigned from my job with the Battelle Northwest
Laboratories and went to work for a company called University Computing Co.
(UCC). I was now a full time computer type and was no longer a research scientist.
The best part of this job was spending a week every other month in Dallas,
Texas on an expense account. I'm too light skinned to live there. The heat
also bothers me because I am insulated for a cooler climate located away
from the Equator. It doesn't matter which direction I go as long as
I move at least 45 degrees. I have to wear sunglasses outside and I sunburn
easily.
-
- 1983
- This is the year that I stopped working for UCC
and went to work for Exxon Nuclear Co. They had been my customer but there
was an advantage in working for them and I took advantage of the offer.
-
- 1992
- The year my brother and my late Aunt Norma
talked me into adding our genealogy on to my computer. My life hasn't been
the same ever since. They are still smiling. My brother even bought me PAF
for a Christmas present. Norma died in January 1997 and should know all of
the missing pieces but she hasn't provided the answers to me <grin>.
-
- October 31, 1997
- The date I retired from Siemens Power
Corporation. My position was McKensie'd; however, I had been preparing for
the situation, if it occurred, for at least three years. I had been happily
unemployed until the weekend before Christmas. I bumped into an old friend
and for some strange reason told him about being unemployed. I didn't usually
do that and I had bumped into him before. I listed all of the things I wanted
to do such as develop Windows programming skills. The next day his computer
person turned in his notice and I received this phone call. I didn't have
to go back to work and I was really amazed at how easily he talked me into
going to work for him.
- 1999
- I am retired again. I have been
spending an awful lot of time on setting up a heterogeneous computing environment
involving a cluster of Windows 2000 machines and a FreeBSD server. The W2K
machines all multi-boot Windows 98 system, which I only use when I have to.
Windows 2000 at beta 2 was more robust than the release versions of Windows
98. One of the contributor's to ZDnet has an article with W2K containing
63,000 bugs. I had to agree with comment someone made and they stated that
may be true but he wasn't seeing them. I'm not either. I have more problems
getting Win98se to shutdown properly than I am having software problems with
W2K. There are some programs such as Adobe's GoLive 4.0 that need to be upgraded
but they mostly all work. The major exception is Creative's DVD ROM stuff.
They had problems adjusting to Win95 and they appear to be having similar
problems with W2K. Their special stuff mostly doesn't work and, from past
experience, it could be July to October before they get their first attempt
out the door. Only one system is currently running the OS FreeBSD. The rising
costs of Windows programs is driving me into the Open Source Unix environment
and one or more of my Windows 2000 systems could be converted to multi-boot
FreeBSD. A 20GB hard drive opens the possibilities for multiple choices.
I recently started using KDE as my x-window manager and don't have any problems
dealing with that environment. The greatest problem is correctly using the
new terminology.
-
- The remaining question is
whether the old Micron may be converted to running FreeBSD where it can still
effectively be used to do computing or upgraded. I still have to remove the
Windows 98 programs before I can convert it to a stand alone FreeBSD system.
It has been upgraded to Windows 98 2nd Edition. One of my NT Workstations
could conceivably be converted to FreeBSD but I would have to really come
up with an environment that I don't know about. We aren't talking about major
changes but bits and pieces that are missing. Right now, I am trying Code
Forge 1.5, which for the most part looks like MS Visual Studio 6.0 but doesn't
cost $1300 for a professional developer upgrade.
- 2000
- One of the computer programs
that I converted in my early days to the Univac 1108 was called MONK. This
was a Monte Carlo Neutronics program that calculated a number of parameters.
One of these parameters was the "k-effective" of an array. The "k-effective"
is a measure of how close the arrays were to being critical, which is the
point at which a sustained nuclear reaction can occur. This is important
when you are trying to store material. A recent example of a k-effective>=1
is the criticality that occurred in the Japanese fuel processing plant.
When you don't calculate the arrays properly, people can die. If you don't
follow procedures when you are handling nuclear material, people can die.
There is only one way and that is "getting it right". Monk was one of the
programs that you could use to calculate how close you were to a k-effective=1.
Monk was written for the British ICL computers. The American computers are
fairly compatible with each other. The ICL computers in those days had a
tendency to be a little bit different and the program required a lot of work
on my part in order to make it run on an American computer. I was taking
a memory dump home every night for what seemed like weeks. At night, after
everyone was in bed, was the only time it was quiet enough to figure out
what caused the computer error, which produced the memory dump. I have access
to a slightly older version of Monk-6.4b from a Cray. The UK people are
now marketing the current version at $35,000 US/year. It hasn't been that
long since I made it run on a PC. I used the Compaq DEC Visual Fortran as
the compiler and it required about a year to convert. It wasn't a man year
but more like 3 man months of work. I would go in spurts. I would think about
what it was doing and then try something new. It would let me past the current
error. Then, I got to a point that I couldn't make any progress. I think
what was happening was memory was being overwritten because of differences
in how the ancient compilers worked. Well, last week the things I tried worked
and it ran through to a successful termination. Now the problem is to get
someone to pay for the work :). It wasn't too much later that I was able
to make Monk to run on my FreeBSD system using the GNU g77 compiler. I'm
not sure everything works but the long sample problems all run.. The major
problem was getting as much debug information from ddd/gdb as MS Visual Debugger
provides. They are close. Unfortunately, close doesn't count. I have to
point out one fact and that is without access to both systems, I would not
have made it run. Each of the debugger's had a weak areas and the other debugger
provided the information I needed to solve the problem. Without access to
both of them I would have given up.
-
- It is 22 June 2000
and I currently have three computers running FreeBSD most of the time. It
won't be too long until I replace the Micron. FreeBSD 4.0 requires a long
time for a buildworld to complete. I'm looking at a dual P-III 600Mhz based
system to come in at the top. The Celeron (ruby) will replace the Micron
(nomad) and one of the P-II 400's (probably jade) will replace the Celeron
as "ruby". I also didn't renew my MSDN Enterprise subscription. The next
project will involve either Beowulf or PVM where I will have 5 cpu's running
as a parallel virtual machine.
Home Page
Last revised: Monday, February 25, 2002
