XXXXXXX

Links from the Show

Classes and Training

• HVE Forum 2027

• EDC Reconstruction Course

• EDC Simulations Course

• Northwestern University Center for Public Safety – Crash Investigation & Reconstruction
  

Software and Tools

• HVE

• SIMON

• DyMESH

• HVE Tools Add-on for Blender

• The EDC Story
  

Organizations

• UMTRI (formerly HSRI) – History

• NHTSA Crash Investigation Sampling System

• Calspan Tire Performance Testing

Timeline of Topics

00:00:00 - Teaching by Hand and Knowing Your Software

00:03:18 - Early Life, Education, and Graduate School at Michigan

00:12:07 - NHTSA and the Origins of SMAC and CRASH

00:28:39 - From Mainframes to the PC and Founding EDC

00:54:39 - Early Customers, Manuals, and Building Credibility

01:10:43 - Developing HVE, SIMON, and DyMESH

01:40:20 - The Simulation Workflow and What Makes a Good Match

02:00:44 - Model Selection, Parameters, and Testifying to a Range

02:19:28 - The Future: Tire Models and AI

02:27:28 - Retirement, Succession, and Advice for Young Recons

Rough Transcript

Please find a rough transcript of the show below. This transcript has not been thoroughly reviewed or edited, so some errors may be present.

Lou (00:00:00):

I thought I'd actually start with something very light and entertaining. I was tasked with teaching my boys seventh grade math last year, and inspired by you, I just got the giant post-its into my wall and went to town with a Sharpie. And anyone who's ever taken your simulations class knows that that is the method of relaying information in that class. And it's really welcome because it gives you more time as the student to process the information and to take your own notes and understand a little bit more what's going on as opposed to somebody quickly flashing through the slides. And obviously there's just something about that hand-brain connection that's valuable.

Terry (00:00:47):

Yeah. For me, the big difference is that if you do a PowerPoint presentation, you know that there's going to be a large fraction of the people who just sit back and eat popcorn and watch, and then as soon as there's a break, they leave and then they come back when they have to. And the difference between doing that and actually having to take notes is astronomical. It's huge, I think. And it also helps me pace my lecture, which I like to use just the writing to pace my lecture because I figure it takes a student a certain amount of time to do the same amount of writing.

Lou (00:01:28):

I was looking at my notes. I took 38 pages of handwritten notes in four days during that class. And the pacing, it was great. I have degrees in engineering and that's a lot of what was being discussed there, but I still felt like it was kind of really balancing how quickly I could learn and still understand things. And I did feel like I got a tremendous amount out of that class. It's kind of one of the ones where you see other recons on the street and at inspections and stuff and you talk about the simulations class and everybody has something unique to...That's a unique class I think for a lot of recons because it's a little bit more intense and you get to peek all the way under the hood. It's not just here's how to use the program. It's here's how the program works.

Terry (00:02:16):

One of the things we talk about when people ask about testifying, what's the key to testifying? And the answer is, to me, it's really simple and that is understand exactly the way the program works, understand the physics models that are being used, their applications, their limitations. And if you know that well, which is the goal of the class, then you'll be good to go. If you don't understand the program, you're in trouble.

Lou (00:02:48):

Yeah. Yeah, because a lot of the attorneys always want to accuse you of garbage in, garbage out. But like you said, if you know the effect of every parameter, or even if those parameters are involved in the simulation that you're running and a lot more than that. Yeah, I agree. That first principle's thinking, that's what it was. It was a lot of first principles thinking. Let's go all the way back to F equals MA to summing moments and how does that relate? And then we are just going to do it step by step.

Terry (00:03:17):

Exactly.

Lou (00:03:18):

So going back, way back, where did you grow up? Did you grow up in Portland?

Terry (00:03:23):

Nope. I'm a native Oregonian. I grew up in a town on the Oregon coast called Cous Bay. I was a contemporary of Steve Prefontaine, if that name means anything to you. Steve and I went to school together. He was a distance runner who went to the University of Oregon and he was Nike's first test subject. He was also in the 68 Olympics and was in the lead as a 22-year-old, was in the lead for up until about the last hundred yards. He never had a kick and he got passed by three people, so he did not get a medal. But anyway, he's kind of a legend in Cous Bay.

Lou (00:04:06):

So your parents, were they technical or what were their careers? How did you get into something so technical? Is it just kind of innate in you or were you exposed to it?

Terry (00:04:18):

So my parents weren't technical. My dad was a ship chandler. A ship chandler, that's actually a British term, but basically Cous Bay was, when I was growing up, was the world's largest exporter of sawn lumber. It's at a town of 15,000 people and it's nine sawmills working twenty four seven and so forth. So ships would come into Coos Bay from all over the world and they'd come in empty and they'd leave full of sawn lumber. And so the ships would come in and they would need to be serviced. Basically a ship has got two pieces to it. It's got the part that moves the product from point A to point B. That's basically the ship's haul that gets filled up with wood. And then it's got this floating hotel back in the '60s and '70s when I was growing up in Coos Bay, the floating hotel took about 30 people.

(00:05:19):

Now it takes about five, but at the time it took 30 people and a ship chandler takes care of that floating hotel. My dad was a chief steward during the Second World War, and so he knew how to service a ship. So he ended up in Coos Bay and became a ship chandler. So I grew up in Coos Bay and he was not mechanical, I would say. He didn't know anything about cars, but when I was a kid, my older brother was downstairs helping my dad box things up and so forth, and I was in the garage building go-karts. So it was pretty clear that my brother was going to take over the business and I was going to do something else. And so I ended up going to Oregon State and getting a couple of engineering degrees focusing first on automotive engineering and then on metallurgical engineering.

Lou (00:06:15):

Were those the two degrees, automotive and metallurgical?

Terry (00:06:17):

Yeah. Actually, they're both mechanical engineering degrees, but automotive focus and metallurgical focus. And so that's how everything started. After my first degree, I ended up in Portland. I moved to Portland and went to work for a suspension manufacturer for a short period of time. The suspension manufacturer had a consultant, being an engineer in training, I needed to work under a PE. And the consultant worked for this company that did failure analysis amongst other things. And so I became interested in what they were doing. They did accident reconstruction as part of the failure analysis piece. And so I ended up being invited to go to work for them. And so that's where I got started in my accident reconstruction career.

Lou (00:07:06):

Okay. So you got the two degrees. How long did that take for the two? Because for most people, just the one is hard and takes five years.

Terry (00:07:15):

Well, actually, I could go back to the drawing board. I was so ill-prepared for college, it wasn't funny. My guidance counselor in high school must have had a brain fart or something when he said I should be an engineer. Aptitude-wise, I was an engineer in waiting, but in high school I never took the math classes or the physics classes or any of that to prepare me for an engineering curriculum. So I went to engineering school at Oregon State and learned exactly what I didn't know. And then I said, "Well, I've got to do something else here." So I ended up going down to the University of Oregon, which does not have an engineering program, but they have good math and good chemistry and good couple of other things. So I was kind of trying to figure out what I wanted to do, and I realized, no, I really do want to be an engineer.

(00:08:08):

So I started taking math classes at the University of Oregon and got all that behind me, and I went back to Oregon State. So when I say it took six years, that's the reason I had a two-year sabbatical at the University of Oregon.

Lou (00:08:22):

Wow. Just to beef up that math so that you could start the engineering calculus then.

Terry (00:08:26):

Yeah, exactly.

Lou (00:08:28):

I remember that being a rough transition. And I had pretty good high school curriculum and it was still. I did take physics. I took regular math all the way through. And when I got to Calc I, I realized, "Oh man, this is a different thing. I'm going to really have to button up." So six years for both degrees or the first one?

Terry (00:08:46):

No, six years for my first degree. And then I went to work for the suspension manufacturer and then moved over to the failure analysis to the consulting engineering company and just really, really fell in love with failure analysis and in particular accident reconstruction. But part of the failure analysis part is studying broken metal and things like that. I thought it'd be interesting to go back and get a second degree in metallurgy, be useful in my failure analysis work. So when I'm looking at a broken tie rod, I can say, "Oh, that's fatigue," or, "Oh, that's an overload failure of the first magnitude." So I went back and got a second degree at Oregon State, and then went back to the consulting firm and was there for another almost a year. And my boss told me, he says, "You're obviously interested in this stuff.

(00:09:43):

If you really want to succeed as a consultant, then you're going to be testifying in court. You should have a master's degree." And I think he thought that I was going to just go to Portland State and do it at night. But I figured, well, if I'm going to get a master's degree, I'm not going to blow all that time on something that's just pretty pictures. I want to really focus on my work. So my major professor at Oregon State, his name was Professor Mingle, and he was my automotive prof, and he and I had a great relationship. And so I went down to visit him and I told him, I said, "My boss says I should get a master's degree, and so I'm here to talk to you about that." And game-changing moment in my life occurred during that conversation. He rolls out his drawer and he says, "Terry, I'd love to have you as a student." And he's kind of filtering through his stuff in his drawer, and he comes up with a card, he says, "But you should contact this person." It was David Cole at the University of Michigan who worked at the Highway Safety Research Institute, and now it's called the Transportation Research Institute, but at the time it was HSRI.

(00:11:01):

So I wrote him a letter and I got a reply saying, "This sounds really interesting." And so basically I ended up at the University of Michigan and they basically put together a master's program for me that focused on accident reconstruction. And specifically my interest was the computer codes that had been coming out that were totally inaccessible to people that worked in the company that I worked at that didn't have a mainframe computer that the University of Michigan had a huge computing system with all these computing codes that had been developed, which we can talk about. So I basically spent my master's program, which is one year long, focusing on these computer codes that have been developed for the Department of Transportation, National Highway Traffic Safety Administration. Anyway, that was my first exposure to the computer codes, and that's what I focused on when I was in graduate school at

Lou (00:12:07):

Michigan. A lot of people probably know it now as UMTRE, but like I said, the Highway Safety Research Institute was prior to that. And doing a little research, it looks like that was started in 65 from this huge grant from Ford and GM and the Automotive Manufacturers Association. So they were very well equipped to guide you on that mission. So what were the programs that they were. When you first showed up, first of all, I don't even know. I know the term mainframe computer, but I'm not sure that I fully understand what that is. So what is a mainframe computer and what kind of code are they running when you show up?

Terry (00:12:49):

Okay, so a mainframe computer is basically just a computer that fills a room as opposed to. And has about 100th of the computing power that my laptop in front of me has, but that's the way it was back in 1979. And you would have a remote terminal and you would create a batch file and you would submit it using some job control language, JCL. You'd submit it to the computer center, and at some point they would run your program and you'd wait to get a message that you had results and you'd go in and get your results. That's a mainframe computer here. The interaction with a mainframe computer is the major drawback actually.

Lou (00:13:39):

Yeah, takes a long time. You have to wait in a queue for everybody else's program to run.

Terry (00:13:44):

Exactly.

Lou (00:13:45):

So the language that you're speaking to it in, is that like Fortran or?

Terry (00:13:50):

So the programming, there's an operating system and I have no idea what the exact language of the operating system was, but the programs were all written for engineering. They were all written in Fortran, Fortran four at the time, Fortran 77 had just come out. If you were working for a bank, you also used a maintran computer and you probably used COBOL or one of the other languages, which there were a lot of different languages back in the day.

Lou (00:14:25):

Fortran stuck around is interesting because I think my second year in undergrad, they tortured us with Fortran 77, and it was kind of like a weed out course. They're like, "If you can handle this, then you can proceed with the program. And if you can't, then tata and we'll see you in the arts." Okay, so some of the programs had been developed by the NHTSA. Was that crash at that point that you were dealing with primarily or was it simulation already?

Terry (00:14:51):

So no, they had both been developed. So timeline, so let me go back to the formation of NHTSA, which it was, I think 1966. It was originally called something that was close to the National Transportation Safety Agency or something, but NTSB got all upset about that because they wanted a name change. So they changed the name to NHTSA, National Highway Traffic Safety Administration. So NHTSA was tasked with figuring out basically for the first time the government got involved in trying to identify the cause of highway death and injury, and that was NHTSA's purpose in life. And so this was back in the mid to late '60s, and the mainframe computer had just become popular. All the big research institutes and colleges and so forth, they had mainframe computers. So NHTSA set out some contracts to various research institutes to help design and develop some computer programs that NHTSA would use in their statistical analyses to try to figure out how highway death and injury was occurring.

(00:16:13):

Stepping back one step, I always like to explain NHTSA's approach to solving their question to serving the goal was to do the same thing that the CDC would do, for example, to study heart disease or cancer. They would basically take a look at. They would basically study a large volume, a large population sample of people with heart disease that died from heart disease or cancer and so forth, and then they would try to draw conclusions. NHTSA said, "We should be doing the same thing. We need to look at a huge population of crashes across the United States, and from that population of car crashes, we should be able to draw some conclusions about what's happening out there." And from a QA standpoint, back before all of this, there were researchers who worked as engineers. There were professors, physics professors, engineering professors, and so forth, that knew enough about the laws of physics to realize, "Well, cars do crash according to the laws of physics, so we can use physics to help us figure out what was going on." So these researchers would just use pencil paper and a slide rule and go through the laws of energy and momentum and try to figure out what was going on.

(00:17:45):

And it was kind of up to every individual to figure out their own little path. There was no common group of people that was overseeing the process, really. When NHTSA came along, they realized, "Well, we can't have all these people all over the United States using their own technique. We have to have it for QA purposes in order for our statistics to be any good, we have to have all of our researchers using the same tools." So stepping forward now, NHTSA let out some requests for proposals to CalSPAN, Cornell Aeronautical Lab that had researchers that have been developing aerodynamics models for years and decades, in fact. In the '60s, they'd moved over from airplanes to vehicles, and they started developing models for vehicles. So they really had a head start on everybody, and they had an engineer working for them named Ray McHenry, who was an ex-Ford engineer, a vehicle dynamics guy, and he was placed in charge of the programs, developing a set of programs for NHTSA to help NHTSA, computer programs for NHTSA to help NHTSA study this large population of crashes.

(00:19:17):

NHTSA was going to set up what they called zone centers. I think they started with eight zone centers located throughout the United States, and all these zone centers would be using the same tools, and McHenry was in charge of proposing and then developing those tools for NHTSA. The first program that McHenry had developed, even before NHTSA actually, was a program called the Highway Safety Highway Vehicle Object Simulation Model, H-V-O-S-M. And that was originally developed back in the mid, I think 1966, but it had been undergoing changes and evolving, you might say, just getting more and more meat on the bones.

(00:20:06):

And that was being used by Federal Highway, the Federal Highway Administration, to try to help highway design. It wasn't really used for safety at that point, but that was the first program that McHenry had that he could show NHTSA. NHTSA said, "Well, that's a really decent program, but it's way too complicated for our needs, and also we need to study car crashes, and that's a single vehicle simulation model that you've created." So between 70 and 74, CalSPAN created a program called the Simulation Model of Automobile Collisions or SMAC, and handed that off to NHTSA. NHTSA started using that in some prototype studies at the zone center level to see how well that program would work, and it was doing a good job, but it was costing them a lot of money. It was a simulation program, which we'll get into later, I'm sure, but as a simulation program, it's an initial value problem.

(00:21:22):

You have to guess at the initial conditions and push the go button in the simulation will try to predict what will happen based on those initial conditions and so forth.

Lou (00:21:35):

And I imagine at that time, just a five-second simulation must have taken an eternity to run.

Terry (00:21:41):

I honestly couldn't tell you on a mainframe computer. Boy, it's been too long. I can't remember. I do know. Well, that's kind of jumping ahead. I do know that it would take over an hour on a PC in the mid - 80s.

Lou (00:21:57):

Okay.

Terry (00:21:58):

Yeah.

Lou (00:21:59):

Longer than that.

Terry (00:22:00):

Yeah. It was also costing money. Oddly enough, NHTSA didn't have its own mainframe computer that was dedicated to the people doing this statistical analysis stuff. The zone centers were actually contracting with McDonnell Douglas Automation, which was McDonnell Douglas Aircraft Company in St. Louis, Missouri. They had a huge mainframe computer, and NHTSA zone centers were contracting with Mercado, sending basically, as I described earlier, in a batch mode, sending the data to Mercado, and Mercado would run it through the computers and send the results back. The zone centers took a huge step forward where they had these vehicles that had terminals on board that they could connect with the zone centers while they were at the crash site. And so they did some pretty cool stuff with the SMAC program, but it was still taking a lot of runs, and Mercado was charging them an arm and a leg for every single run.

(00:23:06):

So lots of runs, lots of cost per run. NHTSA was looking at their budget saying, "Wow, this is costing us a fortune." So they go back to McHenry and they say, "This was a great program, but man, we're getting killed here. Can you help us figure out how to do this cheaper?" And McHenry basically said, and I'm actually making some assumptions here, but it's kind of obvious from the track record of all these things that are going on. McHenry says, "Well, all you need is a pre-processor to help calculate initial conditions so that you can put those into SMAC and then everything you'll greatly reduce the number of runs." Well, that pre-processor was a crash program, CALSPAN reconstruction of accident speeds on the highway.

(00:23:56):

So McHenry and his crew spent from, let's say, 74 to 76 developing the first crash program and showed that to NHTSA, and NHTSA says, "Yeah, it's pretty good, but need a few changes here." CalSPAN came out with CRASH two in 1978, and NHTSA's thinking, "Okay, this is getting really, really close." Just a few more tweaks. Ultimately, 1981, they had CRASH three, and by that time they said, "Wow, this CRASH three program is really doing what we need. We don't need the SMAC program at all." So the CRASH program was, instead of being an open loop simulation, it was closed loop reconstruction style program where it used lots of momentum and energy and closed form calculation, one shot through it takes a second or so instead of minutes or longer. And so they saved a lot of money and also discovered in the process, sometimes you just didn't know what question to ask, and I think NHTSA was in that position initially.

(00:25:16):

They didn't really know what they wanted. They had an idea, but they didn't know how to get there, and they stumbled into the CRASH program as a secondary effect of trying to help them get better at the SMAC program. But once they had the CRASH program and ultimately CRASH three, NHTSA pretty much abandoned the SMAC side of things and just used CRASH3. And they're still using CRASH3, the fundamentals of CRASH3 to help them to populate what they call their national automotive sampling system, which is the statistics that they had developed from all this large population of crashes. They have a set of statistics for every year since 1981.

Lou (00:26:07):

Yeah, and they call it wind smash now or something when you look up into that database, and I didn't even realize that until you just mentioned it. I can't even imagine trying to do that kind of volume with SMAC. Imagine an investigator trying to do a few hundred cases a year and simulate each one to get a match. So they're just like, "Hey, we're pretty darn close with CRASH three. We're getting initial speeds. We know what's going on." So what did they do with SMAC? Or did it just go to the wayside and that's when you started taking over and saying, "Well, I get that if you're trying to reconstruct 20, 30,000 cases a year, it's not really valuable for your purposes, but for purposes of the suspension manufacturer who's trying to understand more detail driver inputs and have a little bit more sophistication and can spend a week or two running the SIM, it's good for them." So did the NHTSA just put it in the background and that's where you saw the opportunity to take it forward?

Terry (00:27:12):

Ultimately, yes. I think 1981 was the last time NHTSA or McHenry did anything with the SMAC program at the behest of NHTSA. After that, all the work was on the crash program. And you're absolutely right about ultimately simulation, although it's really incredibly useful for the reconstruction world, it has absolutely revolutionized, vehicle simulation has absolutely revolutionized vehicle dynamics at the manufacturer level where they're able to match spring rates and shock rates and down to the materials that they use in the suspension bushings. I mean, all of those things. If you drive a 1980 vehicle and then the same make model, but six years later, 1986 vehicle, you'll notice a drastic change. And those are the years during which the manufacturers had started to adopt simulation and the design of their vehicles. So huge, huge benefit to simulation as far as the manufacturers are concerned, and it's only gotten better.

Lou (00:28:39):

How long did you stay out in Michigan? Were you there just for that year and then back to Portland?

Terry (00:28:43):

Yep.

Lou (00:28:44):

Okay. So then you're out there in Portland, the way I'm making up my story, putting all the pieces together, but it's like, okay, you're out there, you see all these tools, you get exposed to them, you're working on them, you're helping to analyze. Did you write a thesis there or what were you doing with those programs there at University of Michigan?

Terry (00:29:05):

Ultimately, and one of the amazing things that happened to me, the head of HSRI was a guy named Robert Hess, and Robert Hess happened to be just absolutely enamored with the crash program. Among other things, I had a reading and conference with him where basically we just together, we would meet once a week and go through the crash program and talk about it and look at the code and figure out what the models were like, and then I would write some sort of a report or an analysis of a particular feature of the program. Ultimately, I wrote an unofficial thesis. There was not a thesis requirement, it was all classwork for my master's degree, but I wrote sort of an unofficial thesis for My main professor whose name was Lin Siegel. And if Lin Siegel was just another man, did I ever fall into the right place?

(00:30:11):

He worked at CASBAN back in the 50s. He was the first person to develop a simulation model. And he's the reason - Of any sort? For vehicles. For vehicles. Okay. Yeah. He developed the simulation model for a Buick. And this is really going back. I'm trying to remember the details. I remember it was a Buick and it was doing some sort of maneuver and he simulated that maneuver.

(00:30:39):

And anyway, and he came across the need for it. H says, "Well, we can do the mechanical design of a vehicle just this mechanical engineering until you get to the tires. But the tires do not behave in a way that you can just throw F equals MA at it and you're done." It's a major modeling task to figure out how tires produce forces. And so CALSPAN developed built the first flatbed tire test machine, which would measure tire forces and camber forces and so forth based on the environment that the tire was operating in. And that was called the Turf Machine, Tire Research Facility, but TRF Tire. And it's a huge flatbed tire test machine. And they still have that machine at Calspan. It's been a while. I've seen it. I'm guessing it was like 30 feet long, call it. That tells you if I'm off by a few feet, you get the point.

(00:31:56):

It's a big machine. Yeah.

Lou (00:31:58):

So Len Siegel was from Cornell. Robert Irvin was also from Cornell and was in there with you. So sounds like, yeah, there was a bunch. Well, obviously U of M is a huge auto school for obvious reasons. It's right among all of the manufacturers.

Terry (00:32:13):

I like to think of, if you think of Stanford as being the heart of Silicon Valley, Michigan is the heart of the auto industry.

Lou (00:32:21):

Yeah. The

Terry (00:32:22):

Perfect analogy.

Lou (00:32:24):

Yeah, amazing. So was that when your undergrad advisor was rifling through those files? Whose name did he come upon and did he know about Robert Irvin and Len Siegel?

Terry (00:32:34):

I don't think he knew about them. No. He had met David Cole at some point and he had his business card and that's what I had. David Cole, by the way, is the son of Edward N. Cole, who was the chairman of General Motors back in the 50s.

Lou (00:32:49):

Man, that's really cool. Yeah, it's amazing how all of that comes together. It's kind of like you hear the origin stories of a rock band and you're like, "Well, if they just didn't grow up in the same neighborhood or know this guy, then how could they ever get together and become one of the best bands of all time?" Yeah, I was lucky. There's some of that going on here. You went back to Oregon pretty quickly, Portland now. How far away is Portland from Coots Bay?

Terry (00:33:17):

About 225 miles.

Lou (00:33:19):

Okay. So you're pretty far away from home at that point.

Terry (00:33:21):

Yeah. Well,

Lou (00:33:22):

Yeah. Did you start EDC right after U of M?

Terry (00:33:29):

Not exactly. So getting back to the idea of a mainframe computer, everything that I had learned was all mainframe software, mainframe models. I knew that I could take those. So all of these mainframe models that I'm describing were developed under public domain, which means that public funding was used to develop them. And there was a public domain act, which at the time of the 80s, well, up until the 80s, the end of the 80s, which basically said projects that are developed with public funding are available to the public. And the idea is that you'll maybe create something useful beyond what the government needs. And so that's how we got our start. So I could take nine-track tapes of all of these models that were written in Fortran and brought them back to Portland and then sent them up to Boeing Computer Services up in Renton, Washington, which Boeing aircraft has a big mainframe capacity just like Mercado had for McDonnell Douglas in Missouri.

(00:34:49):

So I sent these tapes up of the CRASH program, which was CRASH three at the time, SMAC program, the HVOSM program, and a couple of Michigan programs, phase four, which was a tractor trailer simulator up to three trailers. There were also two 2D programs called the TBST and TBSTT, which is kind of a worthless set of letters, but basically they were a single vehicle simulation model and a vehicle trailer, one trailer simulation model. And so that was the starting point for us.

(00:35:36):

I just basically took all those ninetrack tapes and sent them up to Renton, Washington, and then I got a timesharing account and I started converting those for my use. We would basically log in remotely and use those programs, but they had to be converted. That was another thing about mainframe computers. There were IBM mainframes, there was CDC mainframes or AMDAL mainframes. They were all different and they all had different syntax, like whether they used one set of quotes or two around text strings, things like that it was crazy.

(00:36:11):

They didn't have any graphics capability to speak of. So there would be after add-on graphics programs that would work with Tektronix oscilloscope screens to do just really, really primal types of graphics. Anyway, but that was the starting point, but I quickly ran into budgetary problems. I think my first time sharing charge from Boeing Computer Services for one month was like 2,500 bucks. He was my biggest advocate. He was all over what I was doing. H says, "Oh man, this is going to be great stuff."

Lou (00:36:57):

Is that the suspension company again?

Terry (00:36:59):

No, no, this is the head of the consulting firm where I work. So by this time I'm working as a reconstructionist and wanting to use these tools, these programs in my reconstruction work at the consulting firm and also expose them to all the other engineers at the consulting firm. The guy that owned it, his name was Jack Talbot. Jack was totally in my corner, but he kind of threw his proverbial arm over my shoulder and he says, "Terry, we can't afford

Lou (00:37:38):

This." That's got to be the equivalent today of whatever, it's 20 or 30 grand.

Terry (00:37:42):

Yeah,

(00:37:43):

It was terrible. So this is 1981 - ish, 1981, 1982. And so we needed to figure out something else. And a friend of mine that I had known since my high school days back in Coos Bay, his name was Randy Hargens. Randy went to school at Oregon State and got his degree in computer science, and Randy and I were good friends. And so I'm telling Randy over a beer saying, "Man, I've got all these programs and they'd be so useful, but we just can't afford the mainframe." There was another player, even before Sun and Silicon Graphics, they had introduced something called a mini computer, which had a lot of power, but they were called workstations and it would fit in a closet instead of an entire office.

(00:38:51):

I'd wrote a proposal to buy one of those machines. They cost about a hundred thousand bucks at the time. Then we would convert all these programs for use on that machine, and that proposal was still considered too expensive. So Randy and I are talking and I said, "Man, I'm at the end of my rope." I've said this. If anybody who's attended any of my classes, I always tell this story because I'm a guy who grew up under his car. I would say my simile would be just imagine having this beautiful bright red box, huge bright red box of snap-on tools in your garage and you don't have the key, couldn't open them.

Lou (00:39:41):

Right, right. Every case you see an opportunity.

Terry (00:39:44):

Yeah. If I just had the key, I could open that thing up and man, I could really, really make hay. So anyway, well, falling under the category of timing is everything, this was 1981, early 1982. In August of 1981, IBM introduced the PC, and the PC was about 10 times bigger than the previous versions of personal computers, the Apple and some of the others. Instead of having 64K, it had 640K of random access memory, which is, oh my God, that's huge. Your own mainframe.

Lou (00:40:23):

What was a mainframe? Do you know what kind of random

Terry (00:40:25):

Mainframe then? Oh gosh, I really don't know, but it was unlimited compared to a microcomputer. So we thought, "Well, maybe we can get these programs to run on an IBM PC." So this was in late 82, and so we decided, "Well, let's try it." So we took the programs and just basically started hand coding from all of the Fortran. We just basically converted into basic, which the IBM PC had a Fortran compiler and a basic compiler. The Fortran compiler was very primitive and buggy and hadn't been fleshed out. It just hadn't been around long enough. Basic, on the other hand, had been around for years and years, and they had a compiler and it also had graphics capabilities, which the Fortran didn't have.

Lou (00:41:28):

What are those like? Yeah, so are the graphics capabilities there just for a user interface or could you see a car moving on a prescribed path?

Terry (00:41:37):

You'd see a rectangle moving along. Oh, you

Lou (00:41:41):

Could. Okay.

Terry (00:41:41):

Yeah, that's all you would get.

Lou (00:41:43):

But still, that's huge compared. Had you seen that before or was it all just tabular results when you're trying to get a match from a mainframe?

Terry (00:41:50):

There was one famous scene that McHenry had actually done for the movie Man with a Golden Gun, which was a James Bond movie. And there's a scene in which this car, which was an Austin Martin, approaches a river, but the bridge is out, bridge is broken and you could see the front end of the bridge, but there's nothing over the wire. It's gone, been washed away or something. So James Bond pulls up and he says, "Oh, this is not good." And he looks on the other side and he says, "Well, let's give it a shot." So he turns around and he takes a run at it, and he goes over the ramp. Well, the film crew had created a structural ramp using the HVOSM model and McHenry's simulations to figure out how to build the ramp in order to get this Austin Martin across the river and have it come down on its wheels.

(00:42:56):

McHenry did that simulation using his HVOSM program, and there's a wire frame of that simulation. That was the most sophisticated simulation that had ever been produced at that time. That was, I'm going to guess, somewhere in the late '60s maybe.

Lou (00:43:13):

So when you're trying to match evidence or the NHTSA was trying to match evidence with SMAC on the mainframe, they did get some visual feedback. It wasn't just like, here are the XYZ coordinates of the car or X, Y.

Terry (00:43:25):

There was a very primitive two-dimensional graphic of the car, of the rectangle viewed in helicopter.

Lou (00:43:34):

Now you're recreating that with this much smaller. So is this thing like the Windows, I guess it's not Windows, the Microsoft machine, is it kind of the size of a desk or how big is this thing?

Terry (00:43:46):

It's pretty much the same size as if you have a desktop computer or a floor computer. It's pretty much. I mean, I've got one sitting over

Lou (00:43:57):

There. So

Terry (00:43:57):

They

Lou (00:43:58):

Really got it down small at that point, granted 640K, but.

Terry (00:44:02):

They also had hard drives that allowed you to. 10 megabyte hard drives, which we had to pay $5,000 for a 10-megabyte hard drive that one year later was a boat anchor that wouldn't go when Windows went from DOS 1.0 to 2.0. That hard drive that we just paid 5,000 bucks for became a boat anchor. We had just useless.

Lou (00:44:32):

So your friend Randy, is he now at the consulting firm with you or is this when EDC started? No,

Terry (00:44:37):

This is when EDC started. So we're sitting there saying, "Well, we should try to see if we can use a PC to duplicate what the mainframes are doing." So we formed EDC in December of 82, the purpose of which was to take these mainframe computers and mainframe codes and see if we could get them to run on a PC. And that's essentially what we did. And we spent until April of 84, we introduced our first program, which was EDCRASH, our version of CRASH three.

Lou (00:45:13):

That's wild. How many lines of code?

Terry (00:45:16):

Oh, boy.

Lou (00:45:17):

Yeah, because it sounds like you're looking at the Fortran and then rewriting it in basic.

Terry (00:45:23):

Yeah. Thousands. Thousands of lines.

Lou (00:45:26):

I was wondering, so where did you learn. Obviously, Randy's got the Seaside background, which is great, but you'd already been doing a lot of programming. Were you just kind of thrown to the wolves with that, or did you take some classes?

Terry (00:45:38):

I had taken programming classes in college and not really though too much about them and didn't really float my boat, but suddenly I had an incredibly serious need to learn how to program. And Randy was a programmer, and so basically I just learned as on-the-job training, converting these programs from Fortran to basic.

Lou (00:46:05):

Yeah, there's nothing to teach you quickly like a goal in the same way. I was motivated. With programming, it's like, "Hey, if I don't need to do anything with it, I don't really care about this class." But then the moment you have an idea where you're like, "Huh, programming is the way -

Terry (00:46:17):

Completely different. Yeah.

Lou (00:46:19):

Yep. EDCRASH was the first one out, the closed loop, and that took, what, two to three years, it sounds like?

Terry (00:46:28):

So yeah, we basically did some preliminary prototype stuff that we were just trying to find out if it was going to be possible for these programs to run on a PC before we really rolled up our sleeves and invested the effort. And we decided that it looked like it was probably going to work. So we created an overall program design, which we called EDVAP, E-D-V-A-P, Engineering Dynamics Vehicle Analysis Package, which was basically an overall program design that. So basically we took the mainframe computer programs and we would extract from the programs all the physics, and then we'd throw the rest away. And then we would write an input module and an output module and a graphics module that ran on the PC, and then convert the physics from Fortran to basic. All of this was in basic, including the input modules that I described, input and output and graphics is all in basic.

(00:47:50):

So anyway, that was our approach, and we called the overall program design, we called it EDVAP, and that EDVAP suite of programs or that overall suite of programs, I guess, had EDCRASH first, then in April of 84, and then in August of 84, we created what we called the single vehicle simulator, ED SVS, and that was based on the Michigan 2D program that I mentioned earlier, and then ED VTS, which was the vehicle trailer simulator, again from the Michigan model. And those were introduced, as I said, I think in August of 84. And then we introduced Ed Smack in May of 85, and that was our version of the SMAC program. So at that point, we had four of the six physics programs that we had wanted to convert.

(00:49:01):

And then we took a right turn and we decided to develop a graphics program that could be used, that integrated with these physics programs so that you could watch in a nicer environment, for lack of a better word. You could create a diagram. It was a CAD program, and we called it EDCAD, Engineering Dynamics CAD. The idea was that you could draw a crash site, the scale diagram of the crash site, and then superimpose over that, the scaled rectangles representing the vehicles, and you could watch them go around the corner and so forth, and hit each other and bounce off.

Lou (00:49:51):

So what year was that,

Terry (00:49:52):

EDCAD? 88.

Lou (00:49:54):

Okay. That sounds like a major. The amount of coffee fueled late nights must have been extreme between 81 and 85, really all the way to 88, it sounds like.

Terry (00:50:07):

Yeah, actually, so we had the proverbial day job. I was working at the Talbot Engineers working as a consultant, as I've mentioned, and Randy was working as a management consultant at one of the management consulting firms. We would meet every Monday morning at this place called Fat City Cafe. We'd open up the place at six o'clock and sit down and have our bacon and eggs, and we would go through code and develop, basically working slowly through the code. We did that for probably roughly a year plus for sure before we had anything that we could see on a computer.

(00:50:55):

That was the year of 1982 through this first part of 1983. Then we said, "Well, this is going to work." So we went ahead and developed the input and output and graphics modules that I mentioned earlier, and then integrated the physics into those. And so that's what these four programs that I just described, they shared the same style of input. They're all menu driven, so Windows had never even been dreamed of by that time. So they were all menu driven, question and answer type stuff, which was great compared to the original mainframe program where you create a card image file and send it off to the computer center with a bunch of JCL, job control language, and hoping it came back without errors.

(00:51:54):

The classic is you send this thing off, you pray to the east, and you come back with one page that says syntax error. Oh, geez. Yeah. So line seven in your input deck has a comma missing or something, but you had to figure out where that was. So obviously having an interactive input session where you'd be asked a question and you'd type in the answer, and if you had a syntax error, you knew right away if you've entered three numbers and it wanted four or something like that, or you entered a value that was ridiculous. So that was all part of the input session, the input module that we developed.

Lou (00:52:37):

I can only imagine what it felt like seeing that all come together for the first time when you're translating these thousands of lines of code and you're pulling the physics, it sounds like, and then basically rewriting everything else so that it'll work on the IBM machine. And then you start to see it come together and you start to get the graphical output and it's making sense and it's aligning with. That must have been really exciting.

Terry (00:53:02):

That was overwhelmingly positive reinforcement. Yeah, the same is true. It was huge when we did the same thing years later when we had HVE and we had three-dimensional images of the vehicles and you actually saw a wheel turning. You actually see the upcap rotating as the. I mean, things like that. Or I remember it was a Sunday afternoon that I had developed the code to read the elevation of the surface, and this is HVE. So I'm jumping ahead now. I apologize if that messes things up, but talking about moments that you remember, I remember developing the code, which is called Get Surface Info, where a tire model would find the elevation of the surface below the tire and know, well, I'm climbing a curve, and so the tire model would react accordingly, and then the vehicle would react accordingly. And I remember that Sunday afternoon where I created a curb and drove on it, and I watched the car do exactly what it was supposed to do, and I think I probably started crying.

(00:54:09):

It was so amazing. Yeah,

Lou (00:54:11):

It blows my hair back just to use it, nevermind developing it. For a reconstructionist, when you're putting your scene info into the simulation and seeing the car behave and interact with the terrain that you know exists, and the car starting to behave in a manner that aligns with the physical evidence, that still blows my hair back, and that's got to be a tiny little percent of the excitement that you felt when you're developing it.

Terry (00:54:37):

It was cool. Yeah.

Lou (00:54:39):

I don't know what the consulting scene looked like at that point, but you have this commercially available product now. How do you spread the word and who has the technical chops to use it?

Terry (00:54:50):

I'm glad you asked me that because there's a name that I just though of in preparation for our conversation here, a name that I hadn't though of forever. His name is Tom Noga. Tom worked at NHTSA. He was in their National Center for Statistics and Analysis, NCSA, which oversaw the use of the CRASH program for developing their NAS data sets. When NHTSA started using the CRASH program, there were published reports that it was being used, and Tom would talk to these people and tell them, "We have this program, it's a mainframe program. We're working with McDonnell Douglas Automation. You can talk to them and maybe run it through them." Well, somewhere along the line, and I don't remember who contacted, it must have been Tom contacting me because I wouldn't have even known about him ahead of time.

(00:55:57):

But Tom learned that we were developing the CRASH three program, and as I'd mentioned, even though the CRASH program was a whole lot less expensive to operate than the SMAC program, they were still timesharing with Mercado, and they were paying a lot of money to Mercado every month. When he learned that we were developing a PC version, he was like, "Oh my goodness." So basically, and it's been too long, I don't remember the details of the conversations, but the gist of it is, "Wow, you guys are going to save us a bunch of money here. When you get that program finished, let us know." Oh, gladly. I started to think, "Oh my goodness, this is pretty good."

Lou (00:56:43):

Perfect first customer.

Terry (00:56:45):

Yeah. Yeah. But then the other thing that would happen is those people who were calling Tom about the CRASH three program, he'd say, "Oh, you need to know about Terry Day and about engineering dynamics." And he would give them our phone number. So our phone started ringing. We had a phone and we had our own phone number and everything, and it started ringing.

Lou (00:57:04):

When your product is good enough, it takes care of the marketing.

Terry (00:57:07):

I mean, it's classic. We were the first people in the market to bring something that didn't exist before that was useful, and I'm very proud of that. But anyway, I digress. So we realized, well, we actually have a viable product here, so not only is this going to be usable by me in my reconstruction work at Talbot Engineers, but there are other people who are going to want this. So we kind of changed our mindset from focusing on my use to focusing on a commercial product that other people could use. And of course, me being a reconstructionist, I knew what those other people were like, and I knew what they needed. That's kind of how the bulk got rolling, I guess.

Lou (00:57:51):

That's wild. Eric Dial sent me this question. He said, "Well, then was Terry the first recon to develop commercial software products to analyze crashes?"

Terry (00:58:01):

No, I would say that Ray McHenry was. I was the first one to do it on a PC.

Lou (00:58:05):

Okay. So now you have these customers, the NHTSA, I imagine big egghead recons, because the average recon at that point, I can't imagine they would've been able to use it, but you eventually obviously did educate a widespread community to be able to use it. And every HVE user has the manuals, the pink and gray manuals stacked on their shelves somewhere. So is that when that first started happening where you're like, okay, well, I have to write manuals that I can pass off. How did you train people to use this stuff?

Terry (00:58:42):

I want to go back one step. You'd mentioned the NHTSA as a customer. That didn't really work out. What happened was, unfortunately, Tom decided to leave NHTSA and pursue a degree in psychology. I mean, he went from engineering to psychology. Interesting person, really. Anyway, so I've lost contact with him, but his successor was a guy named Joe Kenny Anthra, and so I talked with Joe and said, "Yeah, Tom and I have been having these conversations and really excited." Joe says, "We're really not interested. We'll just stay with the mainframe." So that kind of went by the wayside.

Lou (00:59:27):

Roller coaster, classic entrepreneurial rollercoaster.

Terry (00:59:30):

Here's a little bit of history that kind of irritating working with the government. Joe said, "We're just going to keep going with the mainframe." Well, about two years later, they came out with their own PC version, and there had been so many conversations between me and Tom Noga, and then me and Kenny Anthra about And how it could be used by NHTSA and save them a bucket load of money. And instead they created their own contract and spent a bunch of money developing their own. And that kind of made us a little more than angry, you might say.

Lou (01:00:17):

Yeah. So is that Windsmash? Is that when they developed that?

Terry (01:00:21):

Pretty much, probably.

(01:00:24):

But what happened next is I got all upset and went to our congressman and explained what had happened. And so I had a meeting, my congressman set up a meeting with everybody at NHTSA. I mean, it was a high level meeting. The head of NHTSA was there and everybody was there. And they authorized, they said, "You've been wronged here and I wish that we had done what you originally had proposed because you've been wronged here. Do you want to have..." There's a name for it. There's a congressional where Congress goes in and does it. Basically it's the version of 60 Minutes showing up at your door and you know you're in trouble. So a congressional oversight committee goes in and basically chews them out. And they asked me if I wanted to authorize that and I said, no, we've got to work with these people in the long run.

(01:01:23):

That's not going to work. So anyway, we sort of came up with a nice little nibble, but certainly wasn't the outcome we'd hoped for. Anyway, so NHTSA is still using, well, basically the physics code, which they had created a standalone physics code and I think it might've been called WinSmash, something like that. And then over time, they actually did what we did. They threw away the input and output and all that and integrated that program directly into their automated process that their statistics people were using to develop their national accidents, national automotive sampling system, statistical data sets. So anyway, so I guess the point is that the idea of using EDCRASH never really materialized.

Lou (01:02:30):

Yeah. So then you got it, as opposed to potentially getting this big government contract that's going to put a lot of wind in your sails and allow you to further develop, now you've got to go after the practitioners, which I imagine at that point in time are primarily solo shops. There's not a lot of exponents and Rimkuses back then.

Terry (01:02:49):

There weren't a lot of them, but there were a few. And I'm going to go back to one more thing that you had mentioned about writing manuals and so forth. We actually, we saw the need to have a pretty decent set of manuals right away. So when we introduced EDCRASH in 84, it came with a full set of manuals and it had five chapters. Let me think about this now. Five chapters was an overview and there was a discussion of inputs, a discussion of outputs, a discussion of graphics, a chapter on the technical portion of the program, basically an overview of how the program worked. And we had those for all the physics programs and we spent a lot of time putting the manuals together.

Lou (01:03:39):

I can't imagine. What was worse, the code or that?

Terry (01:03:41):

Well, I think they were both fun. I mean, it was fun writing the manuals because it was fun describing things. Anyway, yeah.

Lou (01:03:51):

They're so detailed as a user, I really appreciate them because it's again, similar to your simulations class, it's not like you're looking through the manual and it tells you enter the coefficient of restitution here and do this or whatever it is. It's more in depth than that where it's telling you the why and going to the first principle. So it's like a combination of a user's manual and a physics manual. And a

Terry (01:04:18):

Technical manual. Yeah.

Lou (01:04:19):

It's really telling you how to understand what's going on.

Terry (01:04:22):

Yeah. And also in 85, we connected with the Northwestern University Traffic Institute to teach a course on EDCRASH. And so we were teaching at that point, we were teaching it to police officers and some engineers who would take Northwestern Traffic Institute classes. So from that standpoint, we ended up putting together a one week long seminar on EDCRASH, which we called EDC Reconstruction. We ended up teaching that once a year, but then we also had our own version of that seminar that we taught. We took on the road. We'd go to various places throughout the United States and teach it to our customers, specifically to our customers. There was a lot of not just physics programming, but also writing essay technical papers, getting -

Lou (01:05:34):

Oh my gosh. Yeah. I downloaded some in preparation for this and there was a lot. I think I downloaded 30 or 40 of them just to look at over. It's an amazing amount of work that you guys have put out there.

Terry (01:05:47):

Yeah. I think that educating your user base is crucial in terms of the long-term vision of your company's success. The better our users are at using the software, the more likely we are to be successful as a company.

Lou (01:06:06):

So in that vein, when did the HVE forum start?

Terry (01:06:12):

The first forum was, I think 1996. It was actually called the HVE Developers Conference. It was held in San Francisco, downtown San Francisco. I think there were six attendees. Then the next year we changed it to the HVE forum and we had 20 attendees then, so that shot up pretty quickly.

Lou (01:06:38):

Even nowadays with the internet and the conferences which are pretty large, I still find that it takes a long time for certain information to propagate through the community. I'm imagining that the ramp up was, for EdVab say, before we get to HVE, was kind of slow. Did it take a long time for the awareness of that program and how to use it to reach a critical mass? What did that look like at first?

Terry (01:07:10):

Well, I think things happened pretty quickly from between 1984 and 1986 when we introduced EDCRASH in April of 84. I guess our first technical paper was an overview of the way EDCRASH. No, no, it was actually differences between EDCRAH and CRASH three. That was our first technical paper. And that actually might've been published in 84. 85. Was it 85? Okay. So we felt that it was necessary to publish in the technical literature as a means of being credible. One of the things that we foresaw as a potential issue was that when we were developing these programs on a PC, a personal computer was still considered a toy. It was not contaminated. You can't do what a mainframe computer does, if you get my point. The

Lou (01:08:15):

Mainframe

Terry (01:08:15):

Computer, I've got a mainframe computer behind me. Don't throw that toy at me.

Lou (01:08:20):

It'd be like the equivalent of running some sort of simulation on your iPhone nowadays probably. We're like, "Hey, come on. Are you coming with an app?" But obviously that is now a thing.

Terry (01:08:28):

So we paid a lot of attention towards making two things, making sure that, for example, when you looked at EDCRASH output and you looked at CRASH three output, they were basically identical. I think we used asterisks to form the boxes and they used lines or something like that. But other than that, all of the inputs used the same questions, formatted in the same way. All of the outputs looked the same. CRASH didn't have any graphics actually. So when we introduced EDCRASH with some graphics, that was a nice new add-on. But we saw it in terms of being important to the overall credibility of the program that number one, we were well documented in the technical literature, and number two, that the results that the inputs and the outputs for the two programs matched. So we did a lot of validations showing that that was the case.

(01:09:26):

And we published our validations also, which I think was also crucially important back in the early days. Still important, but even more so back when you're fighting the credibility of not just your program, but the hardware that it's running on.

Lou (01:09:41):

Yeah. And I imagine that gave you a lot of peace of mind with respect to all of that code that you had translated to make sure there weren't any mistakes in there. It's like, okay, we've now the Rixact tests, it sounds like, were the main foundation for jumping off and doing the validation, but I imagine that brought you a lot of peace when you start entering all the speeds that you know exist and you're seeing similar help.

Terry (01:10:03):

I would say confidence. Peace, yes. Confidence might be a better word. We're confident that this program is working the way it's supposed to. We actually, in the CRASH three program, we actually discovered some problems with CRASH three that we immediately called Kenny Athra and his group and said, "Hey, you might take a look at this line. I think that it's using the same coefficient of friction for both vehicles." So if you put in two different coefficients of friction, it was using the same friction for both vehicles. That's one little thing that I remember finding. So yeah, that was - You

Lou (01:10:39):

Have thousands of lines of code, something like that's inevitable.

Terry (01:10:43):

Yeah.

Lou (01:10:43):

So then after that, then in 91, you start developing HVE. And I guess just for the audience, what's the biggest difference between EDVAP and HVE and what allows you or inspires you to start marching toward down that path?

Terry (01:11:04):

I guess the biggest difference is the level of visualization and the fact that HVE was a three-dimensional model versus a two-dimensional model also rendered objects as opposed to just wire frames. And I'd mentioned earlier, or I'd mentioned just now the difference being two-dimensional versus three-dimensional, there was really no way that we were going to be able to develop three-dimensional programs like HVOSM. We had one of the six that we had out there ready to go, ready to develop was an NVAP version of HVOSM. But we realized that with a two-dimensional menu-driven user interface, that even if I could use it, the chances of a user being successful using that approach to entering the data and looking at the results was low. That was going to be a problem. At about the same time you had mentioned Exponent, the Exponent's original company name was Failure Analysis Associates.

(01:12:30):

They were located in Menlo Park, California, and they were some of our premier users. And they had begun taking the results from, in particular, from EdSmack, and they would download what we call the output tracks. They would download the output tracks and use that to feed into a Silicon Graphics workstation that was running a piece of software, rendering software that was called Alias Wavefront.

(01:13:04):

Those might be two separate programs, but they were animation programs that you could use, that they were using EdSmack to generate the motion tracks that they would then visualize the motion. So they were doing that on a silicon graphics workstation. So we saw that happening and realized that that was something that we should be doing as part of our move into the third dimension. We came up with a functional specification for a program that would do both the user interface of entering the data for reconstruction or simulation programs, and then tying that directly in the same program directly to the visualization of the motion so that you didn't have to export from a PC to a separate computer. You just do it all on the same computer.

(01:14:06):

We decided to call that HVE, and that was basically something that we came up with a framework, and I went down and talked with the guys in Menlo Park, Steve Warner, who I think he still might be at. It's now Exponent, and he headed their vehicle division in Phoenix. But Steve and a guy named Gary Knox. Ooh, I feel terrible. It's been too long. It's probably been 20 years since I've thought about his name. Anyway, Gary was the head of the engineering group in Menlo Park, and I shared with him what we were looking at, the functional specification in a framework, and they said, "Yeah, that sounds pretty interesting." They were encouraging enough for us to go ahead and develop a full-blown functional specification for HVE. And so I spent a year doing that.

(01:15:10):

Our functional spec for EDVAP was on a whiteboard in bedroom number two of the house that I was renting, and it was basically a flow chart that showed how the input and the graphics and input in the physics and the output and the graphic sessions all talked to each other and so forth. That was the whole functional spec for EDVAP. The functional spec for HVE was actually a user's manual. I just sat down and wrote the entire user's manual for HVE before any keystroke had ever been pushed. The idea being that this was a huge program compared to EDVAP, and it was going to run on the Silicon Graphics workstation. It was going to be written in C or probably C++ new language, so that means another language porting process.

(01:16:07):

So I wrote a functional spec and created all. And also, instead of being, this is a huge difference between EDVAP and HVE. EDVAP, as I've mentioned, is a menu-driven program, whereas HVE would be using a Silicon Graphics workstation, which is a 3D, we call it Windows now, but they would use that term back in those days, in the late 80s and early 90s. They would call it a scientific visualization workstation. And the Windows model that they used was called Motif and had been developed at Silicon Graphics, but basically it was Windows on a very, very high-end computer.

Lou (01:16:58):

Yeah. How much were those workstations? They must have been really expensive at that point.

Terry (01:17:03):

We bought two of them when we started coding. The first two that we bought were roughly 30,000 bucks. Yeah.

Lou (01:17:16):

1990 money too.

Terry (01:17:19):

Yeah. At various times, we had between four and 12 programmers working as opposed to just Randy and me. This was much, much bigger project. It was supposed to take two years, and it ended up taking, well, from April of 91 to February of 96, so almost five years. Five

Lou (01:17:46):

Years with five or six developers going at it.

Terry (01:17:49):

Yeah. Average, something like that. Yeah.

Lou (01:17:51):

Yeah. And then so the people who bought HV at that point in say 96 when it was released, did they also have to have that Silicon Graphics workstation? So they had to spend the 30 grand and then buy the software.

Terry (01:18:03):

So one of the good things that happened between 91 when we started coding, so I started the functional spec in 1990, and I finished the functional spec and started programming right away in 1991, April of 1991. And at that point, we had to buy a couple of these $30,000 workstations, Silicon Graphics workstations. By 96, when we introduced the program, Silicon Graphics had introduced a $8,000 version of the program of the hardware that was probably at least five times faster and six times less, four times less expensive. So that helped a little bit, but it was still a challenge to tell somebody, "Okay, here's the software, but you also have to buy a new computer and you have to learn how to use this computer. And oh, by the way, it doesn't run Excel or Word or any of those other things. It's going to be good for HVE," and that's about it.

Lou (01:19:12):

Dedicated work. Yeah, so it was really, at that point, just going to very high-end users who had higher end clients in more sophisticated cases.

Terry (01:19:21):

I mean, we had some smaller companies that were, I would call them the leaders of the industry who they were making enough money, they were successful, and they were just basically say, "I'm going to buy this thing. I don't care how much it costs. I'm going to buy it." That's probably kind of overstating it a little bit, but we did have some smaller dedicated users who were willing to pull the trigger on a. Basically, at the time, it was about a $35,000 investment, including the workstation, $10,000. And HV at the time was 25,000, maybe 18,000 for the HVE user interface and the physics programs are 25, 3000 bucks a piece. So yeah, it was a lot of money.

Lou (01:20:06):

The sophistication of the tools that it gave them and the ability to answer questions that are really difficult to answer otherwise without that simulation is huge. There's so many questions that simulation can help answer, and we'll get into some of that stuff that is very difficult, if not impossible, to answer in another way.

Terry (01:20:29):

Agreed, because you're solving a nonlinear problem. I mean, pure and simple, you're solving a problem that is not amenable to calculation. It's amenable to simulation, to repeated F equals MA. You just keep doing that until the car stops. Pretty straightforward, really.

Lou (01:20:47):

Yeah. Isn't that funny? Yeah, it is straightforward and it can take weeks sometimes. Not so much anymore, but I imagine back then that. So okay, in 96, how long would it take to run a simulation at that point on that machine? Is it hours or -

Terry (01:21:03):

No, no, no. It was low minutes.

Lou (01:21:08):

Oh, wow.

Terry (01:21:08):

Okay. Yeah. Including the visualization.

Lou (01:21:12):

That's impressive.

Terry (01:21:13):

Yeah.

Lou (01:21:14):

So they made huge leaps then, and that, I guess, justifies that giant price tag on the Silicon Graphics machine.

Terry (01:21:20):

Here's the other thing that happened between 91 and 96. The gaming industry caught hold, and it went from. Oh, what was the puck where you move the puck around?

Lou (01:21:36):

Not pong or pong?

Terry (01:21:37):

Yeah, pong. Yeah. It's

(01:21:38):

Pink, something pong. Maybe it was just pong. Pong, just straight pong. Yeah. Yeah. It went from that to literally rendered objects. They were kind of coursely rendered, but they were still being rendered. And the gaming industry started taking hold between 91 and 96. By the time that we had just pulled the trigger on $60,000 worth of Silicon Graphics hardware, by the time we got to 96, Windows NT had come out, and there were companies that were making graphics cards that were as fast as the low end Silicon Graphics graphics cards. One of the things that was happening that still baffles me today, I don't know how this was allowed to happen, but there were just stories about recruiters walking through the hallways at SGI, Silicon Graphics in the midnight, early to mid - 90s, recruiting people to leave SGI and go to work at this nascent graphics card company.

(01:22:47):

And instead of paying. And the idea is since the sales volume went from. So SGI, in its heyday, is probably selling several hundred computers a year, maybe even a thousand computers a year for hundreds of thousands of dollars to government, to the military, and all sorts of high-end users. Suddenly, you had millions of users, maybe tens of, in fact, hundreds of millions of users worldwide. So the cost for a graphics card went from thousands and thousands and thousands down to 300 bucks.

Lou (01:23:29):

Nothing like entertainment to push forward engineering, which I think has happened many times. And now we're starting to get into my recollection when I was actually conscious. We started with Atari at my house, then we went to Nintendo, and then Sega Genesis must have been somewhere around there, and the graphics there were much, much improved. So you're getting that same kind of thing that is putting some nice wind on your back too.

Terry (01:23:58):

Of course, the problem is that we had now at 96, we have just finished developing the development process, including a significant capital investment to develop our product on an SGI workstation when now there is a PC sitting right next to it that costs 1200 bucks that will run just as fast. And Windows NT was introduced in 96, and it was a multitasking full-fledged windowing operating system just like the Silicon Graphics had, and things only got better.

Lou (01:24:39):

What does that transition look like? How do you get from the Silicon Graphics machine to the Windows?

Terry (01:24:44):

So we basically didn't even take a breath. We realized, okay, now we have to basically convert this thing over to the PC. So we basically hired a group of people to port the program from SGI to the PC.

Lou (01:25:04):

Man, yeah, you just got to go. It thinks that's -

Terry (01:25:09):

That

Lou (01:25:09):

Was painful. A very volatile environment just because it's changing so quickly the whole time

Terry (01:25:14):

Through. Yeah, that was incredibly painful, but yeah.

Lou (01:25:17):

So the HVE is the human, the vehicle in the environment, and you have that all together for the first time. Is that right? Is that the first time where you go through and you set up the occupants and you set up the car and then you set up the environment and now you're running your SIEM and you've got this interface for each one of those sessions? It was always very intuitive to me. I first learned HVE when I was working with Eric Dial. I had used Smack before in a very primal fashion, really just in a very intelligent fashion. Then I started working with Eric Dial, who's obviously a very high-end simulation user, and he's like, "Here's HVE. I'm here if you need me. Go to the HVE forum, highlights the classes that I should go to at the forum, sends me to the simulations class." And then just between that kind of training and having him next door and just bumping through the program, it all seemed very logical to me.

(01:26:26):

I understood what I needed to do at every section because running the simulation is the last thing you do. First, set it all up. What kind of cars do we have? What kind of environment do we have? So that is a really clever setup in my eye. It worked very well for the way that I saw things.

Terry (01:26:43):

That's good to hear.

Lou (01:26:44):

Yeah, and it must have just felt great putting that all together and just having this one package where you can accomplish all of that. That must have felt like a monumental achievement or did it, I guess is a better question.

Terry (01:26:56):

I guess looking back on it, it was a pretty significant achievement. When you're in the throes, when you're in the midst of the hurricane, sometimes you don't see it around you, but we had a job to do and we just kept plowing away till we got it done.

Lou (01:27:14):

Man, I can't imagine the storm that you're in, like you're saying, because of all the technological changes around you that you have to adapt to, and you're consistently recoding things and throwing away $30,000 computers to just move on to the next thing.

Terry (01:27:30):

I will say that once we. HVE has a pretty good underbelly in terms of the design. We had some really, really bright people, a PhD, Florida State PhD computer science guy who was the brains of the output. I mean, he came up with ideas that were so important to the overall design of the program. So yeah, we definitely benefited from some really, really, really good minds. So once the program was done, I mean, there really wasn't too much to change in the overall design. We basically were just adding to it, adding things like a simulation of a tire blowout or the simulation of an ABS system or the simulation of a collision. We actually added the collision part, which is a story in itself, but we added the three-dimensional collision simulation, basically just tucked it right into the existing code. I mean, you just put that right here, add the code right there for the collision, and you're done.

(01:28:57):

Collision code is huge, but it's basically we talked to it through one line of code, say, "Run Dimesh." And so that part of that is owing to the design skill, the design savvy of some of our early programmers.

Lou (01:29:19):

Yeah, it was really modular. Going from that, from EDSMAC to SIMON, what was the development of that like? How long did it take? And it just seems like a major project with a lot of technical hurdles to overcome.

Terry (01:29:37):

SIMON was the first program that we had ever developed internally at EDC from scratch. As you notice, it doesn't have the ED in front of it. It wasn't EDCRASH or EDSMAC, it was SIMON. I mean, basically, I knew exactly what a simulation model looked like. I knew that I had to have a control routine, a numerical integration routine or free body analysis and a place to calculate the derivatives or the accelerations in our case. So it was simply a matter of, I mean literally, I don't remember the moment that I started sitting down, but create a file that has a control routine in it and flesh out a basic control routine and it was going to say, okay, you need to do numerical integration at this point. Okay, so you put that aside and we just used preexisting existing numerical integration routines. There are a lot of numerical integration routines out there and they all have various benefits, constant time steps versus variable time steps and predictor corrector methods and so forth.

(01:30:55):

We just used a fairly straightforward numerical integration routine that was based on a rungakutta method, which was used by EDSMAC and originally from the CalSPAN SMAC program. So that was easy. Then developing the SIMON vehicle model, that's where all the time was spent because now you're developing, you're doing mechanical engineering from the get-go. You're doing statics and dynamics of basically weight distributions and now you've got a wheel location. Okay, so there's going to be tire forces applied to that. And that was just mechanical engineering, by far the largest part of the development of SIMON. But technically it looked, with the exception of the vehicle model itself, SIMON and EDSMAC pretty much share the same overall design. There's more details involved in SIMON because SIMON can do any number of vehicles as opposed to just one or two. So there's other things, you're going to use loops instead of just I and J, you're going to use loops that go through the number of vehicles.

(01:32:23):

But the big difference between SIMON and EDSMAC is that free body analysis, the vehicle model itself and how the forces are applied to the vehicle model. And then you sum up all the moments and forces acting on the vehicle model and you use Newton second law to calculate the acceleration for this time stamp. And so there's just a tremendous amount of similarity until you get to the vehicle model.

Lou (01:32:55):

Yeah, that Dimesh, and that's 100% unique to SIMEN, that DIMESH model.

Terry (01:33:02):

Yeah. Sidebar, DIMESH came about through a conversation with a guy named Alan York who worked at Sandia National Lab. His background was, probably still is, find an element. And he'd gotten interested in the idea of using finite elements to simulate car crashes. But then he quickly discovered that that wasn't going to be practical because fine and element ran and literally even on a fast computer would take days back in the mid to late 90s. So he ended up hearing about EDC and about me through the Traffic Institute. So I got a call out of the blue from this guy named Alan York and he kind of explained his background and asked if there was something we could do together. I said, "I think there is because at the time we had EDSMAC and EDSMAC did collisions, but it was all two-dimensional. And the last thing I wanted to do was to create a three-dimensional program called SIMON and then limit it to two-dimensional collisions.

(01:34:07):

That made zero sense.

(01:34:10):

So from talking with Alan, he said," Well, if we can come up with a three-dimensional model that runs in a reasonable amount of time, a three-dimensional collision model that runs in a reasonable amount of time, that's our goal. "And Alan says," Give me a little while, I'll get back with you. "And after some fairly short period of time, he says," I think we can do it here's blah, blah, blah, blah, blah. "So he developed, and this is all Alan York, brilliant, brilliant guy. He developed a cheap version of finite element where in finite element, there are relationships between the nodes that are very complicated and very time-consuming calculation-wise. So Alan said," I think we can develop a cheap version of finite element where we remove the relationship between the nodes and we just give the nodes each a directional force displacement characteristic. "And that's essentially in a nutshell what Damesh does.

(01:35:22):

So you don't get everything that you get from finite element, but you get enough and you also have the benefit of running in seconds or minutes as opposed to days.

Lou (01:35:32):

Practicality, yeah. And it's proven through the validation and practice to be enough. You don't need the finite element necessarily in -

Terry (01:35:45):

Agreed. The things, for example, there's a concept called induced damage where the sheet metal that isn't in direct contact with the other vehicle still deforms rearward because it's adjacent to the contact. That rearward deformation where there's no direct contact, that's called induced damage. There's no way for the current version of dimesh to handle induced damage. It has to find a node, a vertex in order to apply a force in order to cause damage. So there are things like that. For example, you won't see the buckling of a roof or things like that in dimesh. So not everything works, but a lot of it does. The vast majority. I couldn't give you a percentage, but a lot of it does.

Lou (01:36:38):

Yeah, it gets the vast majority of the work done and gets you in the right spot. It's an amazing program. I've used it several times, but I had one case specifically where I went all the way through a federal trial with it and it was extremely valuable in that we were able to answer things that other people weren't able to answer. And it was found credible by, that was a bench trial and the judge understood it and it was obviously attacked by the cross-examining attorney and garbage in, garbage out type of an attack. But thanks to your education and my understanding of the program, I was able to defend that. And the judge at the end of the day wrote her very long verdict and there was a whole section on Simon there and the simulation analysis and why she found it to be credible and thought it was a accurate representation of what happened.

(01:37:31):

And it's a really powerful tool. This episode is brought to you by Lightpoint, of which I'm the principal engineer. If you're a recon, you already know video evidence can be a gold mine, but it can also become a giant time suck. We built vPrism to give reconstructionists the forensic video tools they actually need without burying them in features they'll never use. Scientifically calculate speed from video in under two minutes, examine frame timing, metadata, and file structure with a complete record of every action. vPrism is built by recons for recons, and it's priced that way too. Reasonable and transparent with easy to try, easy to buy floating licenses that move with your work. The roadmap is guided by real feedback from the community and Lightpoint customer service is, in my completely unbiased opinion, second to none. Head over to lightpoint.com/vprism to give it a try. I guess from here, just kind of finishing up on the history and the development, what was the most challenging, I'm going to say technical hurdle, but it doesn't necessarily have to be technical, but what was the biggest hurdle in making all of this happen?

Terry (01:38:40):

Totally non-technical is just a practical thing and that is getting people to buy a Silicon Graphics workstation. If there was any motivation between 96 and 98 to port the program to the PC, it was knowing that the size of our market was going to go from the twenties to the thousands because it was just so hard to get people to pull the trigger on a brand new expensive workstation. Even if they dropped a $10,000 or $8,000, that's still a lot of money. And it's a foreign piece of hardware that they have to learn a new operating system and everything. That was difficult. So we were very motivated when we realized that PCs had the same. I don't remember what the graphics, there are triangles per second and things like that. There are metrics that you can use and the PC was clearly doing as well as Silicon Graphics.

(01:39:47):

And I mean, Silicon Graphics went out of business in the early 2000s and for obvious reasons. I

Lou (01:39:52):

Was wondering. Yeah, they didn't get bought up or anything? They just shut down?

Terry (01:39:56):

They'd shut down. They changed from Silicon Graphics Incorporated to SGI, trying to make a larger market for themselves and the workstation market. But Sun Microsystems, have you heard of Sun Microsystems? They were very, very popular. I don't think they exist. They haven't existed since early 2000s, I don't think. Yeah, everything pretty much is on the PC these days.

Lou (01:40:20):

So moving to some of the technical aspects, it's interesting. So a lot of people who are listening to this, most I say who are listening to this, this is obviously a podcast for reconstructionists. So probably most people who are listening to this have run a simulation, but a large percentage of them won't. It's still amazing to me when I'm teaching a class and I'm like, how many are running a simulation at this point? So that I can guide the way that I talk about a certain topic, and there's still a notable percentage that aren't using simulation. So could you just walk through the process from a practical perspective of what's going on when you run a simulation? What are you taking into it? What knobs are you tuning? And how do you know when you have reached a point where you are satisfied with the, I'll call it the match?

Terry (01:41:13):

Sure. The starting point is always going to be your accident site and vehicle inspections. From those, you take home the environment in which the crash occurred and you know the path of the vehicle from the start of the sequence, maybe pre-crash in fact, up to the crash and then post-crash and all the way to rest. So you know the path that the vehicles took. You go out to the wrecking yards and you measure the vehicle so you know the damage on the vehicles, you know the make, model, and year of the vehicle so you can go to various databases and get the vehicle data. So you've got the accident site and you've got the vehicle.

(01:42:01):

And so then the next step is to create a three-dimensional environment in which this crash occurred. So you need to have some sort of a CAD capability. HVE actually has a sledgehammer version of a CAD program in it. It's not fancy, it's very, very minimal. And that was intentional because again, even if we have a thousand users, there are lots of 3D modeling programs out there that have a million users. And so we can't compete with this. We shouldn't try to compete. That would be stupid. So what HVE does instead is it tells the user, okay, get your packet, get your graphics, your modeling package of choice, use that to build a 3D model of your crash site based on your scene measurements, and then import that into HVE. One thing that HVE then allows the user to do is to, once that three-dimensional model is imported into the environment editor, then the HVE user can go in and assign different friction zones and various characteristics to the environment that the vehicle dynamics can take advantage of.

(01:43:27):

I'd mentioned earlier the idea of climbing on a curb or maybe going across a slick spot or maybe from asphalt onto a gravel surface. So HVE allows the user to modify that beautiful environment that you just made using your 3D modeling program. You can modify that environment to account for things like different friction zones and the curb and things like that.

(01:43:56):

So then HVE has a hierarchical database, so you actually select vehicles, not just from a file, but from a database of vehicles according to vehicle type, make, model, year and body style. So you actually select it. If you don't have one, you start with what's called a generic vehicle and then you can edit the generic vehicle to be useful for the vehicle that you have for the exemplar that you have. You just have to go in and edit the wheel base and the tires and the inertias and so forth. And you can also import a three-dimensional model of the vehicle's body so that the 2022 Acura actually looks like a 2022 Acura everybody's, oh, that's an Acura. I recognize that vehicle. That's good. You change the colors. Oh yeah, it's red. Yeah, good. So now you have the vehicle and you've got the environment. So the next step is what we refer to as setting up the event, and that involves putting the vehicle into the environment, so give it the initial position.

(01:45:17):

As I mentioned way back earlier, we were talking about simulation as being an initial value problem. The initial values that you need to enter into a simulation are the position at the start of the simulation and the speed, the velocity at the start of the simulation. So you put those two values in and then you have driver tables, which you enter the driver's braking, throttle, and/or steering. And once you have that, there's a lot more you can do, but at a fundamental level, that's the starting point. You push the go button and basically that causes HVE to fire off the physics program. So let's say it's EDSMAC. And so now EDSMAC will take the initial position, take all the vehicle data and the driver inputs, and use the physics of vehicle dynamics to figure out where the path the vehicles should follow based on those parameters, the vehicle parameters, the driver input parameters, and the initial position and velocity.

(01:46:30):

And when you're finished, you compare where the vehicles come to rest in the simulation with the location where they came to rest from your actual measurements. And there's probably a snowball's chance in hell that you're going to be anywhere close on the first simulation.

(01:46:52):

If you came pretty close, then kudos, you've probably been doing this a long time. Experience, this is one of the other things we always talk about. Experience is always your friend when it comes to simulation. The more you do it, the better you're going to get. There's zero doubt about that. But anyway, so getting back to our job flow, our workflow, so we've run a simulation, the vehicle didn't follow the correct path, so we try to make adjustments to the initial conditions, position velocity, or the driver inputs, braking, steering, throttle, and try to achieve a better match. What we have always preached, and this comes from my experience, and I've been doing this for a while, what I've discovered is that there's kind of an inner loop of adjustments and an outer loop of adjustments. The inner loop is driver controls. So we've selected an initial position, initial velocity, and then we go to the driver controls.

(01:47:58):

And the next step, since we didn't match the path that we were trying to, the next step is to adjust the driver controls, and that's going to be things like wheel lockups, steering, maybe a wheel was hit, you're in the collision, and it ends up steering 45 degrees to the left, and you didn't account for that. So let's account for that. So you try to account for everything that falls under the driver control category and see how close you can get the simulation to match the actual measured rest positions and the actual vehicle damage. That's also something else you're trying to match. And so you keep adjusting the driver controls until you achieve a match or until you say, "There's no way with this initial speed that I'm going to get the vehicle to go down to the rest position. It's just too far away." So at that point, no matter what I do with the driver controls, I can't get to the rest position.

(01:49:00):

Well, maybe I need to go back and look at my speed. So at that point, be the driver control. And by the way, the golden rule, when you make these adjustments that I was describing, change one thing at a time. That's absolutely in any scientific experiment, you have to have this one variable that you're adjusting at a time in order to know what the change was the result of. If you've changed two things, then if you adjust two things, so you adjust the steering and the braking, and then you see the resulting change in the rest position, you don't know if that change was due to the steering or the braking of the comics. So anyway, change one thing at a time no matter.

Lou (01:49:47):

In my 38 pages of notes, I only had, I think, an exclamation point on one page, and it was that rule number one, scientific method, change one parameter at a time and actually have three exclamation points there. So I think you've really drilled it into us at the time. Good,

Terry (01:50:01):

Good. Yeah, that is really important. Okay, getting back. So I've reached the point now where with all of my adjustments to the driver control section of the inputs hasn't made the vehicle go far enough, let's say. Well, at that point, I just reason to myself, I must have the initial speed too low. So you increase the initial speed and then hold the initial speed there and go back to the driver controls and beat on them until you either achieve a match or say, "I'm still not going fast enough." So then you go back to the initial speed and increase it more, and suddenly you're going too far, you're going beyond the rest position, and now you say, "Ah, now I've got a window. I know I'm somewhere in between." And that's the most important intermediate result that you're going to get on your way to a final match, is to get that window where with this speed, I don't get there, with this speed, I go too far.

(01:51:03):

So the speed's got to be somewhere in between. So you know you're going to be successful or this is as successful as you can be with all the parameters that you are able to control.

Lou (01:51:18):

Yeah. And to your earlier point, it's so important that you understand what each one of those parameters are and what they're doing or else you'll never know to change it. In a crash that's not full engagement, the inter-vehicular coefficient of friction, if you don't know what that's actually doing, then you might not get the idea that that's something that should be changed in this simulation. And that's kind of where the experience comes in. And then that fundamental understanding of what the simulation is and the model, what's the model actually looking at to determine these vehicle trajectories? And it seems like you got to really come at it, there's got to be a lot of education that's feeding this for the practitioner. And it brings me to the question of what do you feel like are the most important concepts that a reconstructionist has to understand to even sit down at the table and start this process?

(01:52:19):

Whether it's all the way back to F equals MA or something more specific than that, what kind of makes the best simulators in your experience? And by that, I mean the human.

Terry (01:52:31):

Yeah, no, I understood your question and I'm not sure I've got a good answer for you. Patience. Patience, don't get ahead of yourself. Methodical,

(01:52:43):

Come up with. I described the methodology a moment ago about the inner group of changes, the driver controls in the outer group, the initial conditions. That's part of the methodical part. And you just kind of said this a moment ago, Lou, the idea of observing a change in the simulation and understanding what caused that change in order to direct the next change. Very much a matter of understanding, I guess understanding what makes vehicles move the way they do and how your changes are affecting the movement. I mean, ultimately you're just trying to match. You can sit there and just do ad hoc changes and somehow stumble onto a halfway decent match, but you'll get there a lot faster than that's normally ago I said experience is your friend. When it comes to simulation, the more you do it, the better you're going to get.

Lou (01:53:57):

Yeah, totally. It's funny because how many times I've looked over a younger engineer's simulation and been like, "Well, it needs to rotate more clockwise and it looks like there's some damage to the right rear wheel here. Have you tried increasing the coefficient of friction there and that's going to get the car rotating in that certain way?" And it's like, yeah, if you don't have that basic, like you said, the vehicle dynamics aspect of it, then it might take you 20,000 iterations to come upon something that a seasoned practitioner with an understanding of vehicle dynamics could reach in 20 tries or something.

Terry (01:54:33):

Yeah. One of my favorite comments about simulation, and this is true about simulation uniquely, this is a benefit of simulation that you'll never get from reconstruction, and that is what I call the heel of the hand or the forehead. Oh, I get it now. I know what's causing this. The simulation is famous for that. No matter how many times you've used simulation in the past, even on a per case basis, you're trying to get a match and you don't understand why the vehicle is moving in the direction it is, and suddenly you make the right change and bingo, suddenly everything is starting to become clearer to you. The heel of the hand, "Oh, I get it." Anyway, that's

Lou (01:55:25):

Unique. It's so true. You know how many times I've gone through a case and paper to pen and looked at all the photographs and looked at all the damage to the vehicles and thought that I understood it really well, but didn't fully understand it until I went to go simulate it because it forces you to face all of the little parameters and the time and the distance and the steering inputs. And one of those, a good example of that is you go through this whole recon and then find out that the person's perception response time had to be 0.2 seconds for that to happen, and that's probably not what happened. There's something else going on that you're not accounting for, or a tire mark in the middle of the intersection. You like, "How in the world could that tire mark be there?" And then you start crashing the cars together and you're like, "Oh, I get it.

(01:56:12):

I see what's happening over there." Yeah, exactly. It really is a great educator.

Terry (01:56:17):

Yeah. Yep.

Lou (01:56:18):

So what constitutes a good match in your opinion?

Terry (01:56:26):

That's really difficult to answer. And in fact, I don't think I really do have a good answer. I think that. So having said that I'm not going to be able to answer your question very well. I would say as a starting point, it's going to depend on the crash that you are reconstructing and what's important in the particular crash. For example, let's say a vehicle rotates, let's just say 90 degrees and goes 150 feet. If your simulation, when you're all finished, you're able to do a whole bunch of simulations that confirm the speed that's necessary to get to go 150 feet. And if you reduce, if you try a lower initial speed or some difference in the inputs and the vehicle goes 148 or 146 or 152, you know that you're probably in the right ballpark. Even if in the real world, the vehicle rotated 90 degrees and there's nothing you can do to get it to rotate more than 70.

(01:57:42):

There's just nothing you can do. But still, no matter how much you play around with all the other parameters, you're getting that distance. You've got that distance bracketed in between 146, 152 feet. So your speeds, you have a pretty good idea of what's necessary to get that to happen, even though you can't get the vehicle to rotate as much. And it's possible there's just something going on with the vehicle or with a tire or something that just simply was never captured when the vehicle was measured or the crash site was inspected.

(01:58:24):

So in that case, even though I'm not matching the rotation as well as I would like to, I'd still be happy with that. I would still accept that as a reasonable result. Yeah,

Lou (01:58:35):

Happy

(01:58:35):

Exactly. I may not be happy. You got to correct yourself because the simulators among us are never happy until it's like lands right on, final rest goes right over the tire marks and you're like, yes, you go home happy that night. But I always remind myself, and I say to other reconstructionists, we're reconstructing a real world event that had an infinite number of micro events within it. The way that the tire folded and the wheel hit the asphalt, there's so much that's actually happening at the end of the day, this is a model to represent that, but it's not representing everything and you might not get the perfect match that you're hoping for. And one tactic that I've always had, and I'd be curious to get your take on this, I don't think we've ever spoken about this, is I back up as much as I can with some sort of traditional hand calc.

(01:59:27):

If it's a momentum analysis or just sliding friction or an energy calc and just say, "I've got the sim, I've done hand calcs, they back up my sim." So if you come after my simulation and try to blow that apart, you're also going to have to blow up my much simpler hand calculations that tell a very similar story.

Terry (01:59:47):

I think that's true as long as you're studying something that occurs in the two-dimensional world, as long as it's a reasonably level flat road, there's no curb Redirecting the vehicle. I mean, there's no real way to hand calculate. I guess you could probably break it up into separate calculations, but doing that is problematic too. So if you're studying a very, very three-dimensional event, there's pretty much nothing you can do with hand calculations that won't take you a lot of time, a lot of time, and probably a whole bunch of primary research that takes you into never never land. That's a hard thing to do. That's where three-dimensional simulation earns its money because there's really no other approach that's viable other than simulation.

Lou (02:00:44):

How do you think about the decision from going between or stepping up is maybe a way to put it from SMAC to Simon? When do you feel like going to the full 3D model is warrant, or how do you think about that?

Terry (02:01:00):

Oh, that's a great question. And I have an answer that comes from Paul Fancher. You'd mentioned his name when we were first getting started. He was at the University of Michigan, a really, really brilliant engineer. And he says that you should always use the model that has the fewest number of degrees of freedom that handles the situation, for lack of a better word, that you're trying to simulate. So if a crash occurred on a perfectly level road of uniform friction coefficient, you could use Simon, but the assumptions in the EDSMAC model, EDSMAC4, are suitable for that situation as well. There's nothing about the general model that's being disobeyed. So use the simplest model that you can. And the reason for that is that when you use a 3D model, it's a two-edged sword. There's good news and bad news. The good news is that you can handle, if you're faced with a situation, you can handle the situation where vehicles driving over an uneven road, hitting a curb, possibly going into a ditch, maybe even rolling over.

(02:02:44):

You can literally handle all of those things, but they all take equations of motion and that all takes more data. And all those equations are going to be running even when the vehicle is traveling down a flat road. That opens up the potential for those extraneous degrees of freedom influencing your result. So if that's not an important part of your simulation, then don't introduce the potential problems associated with 3D simulation for a 2D crash. So that's the decision making criterion in a nutshell.

Lou (02:03:28):

As simple as possible, but no simpler.

Terry (02:03:30):

Exactly. Yeah. Yeah.

Lou (02:03:32):

Make sure you're. Thank

Terry (02:03:35):

You, Paul Fancher on that one. I'm sorry I interrupted. I'm giving Paul Fancher the kudos on that because that was his point and I've always thought that makes a lot of sense.

Lou (02:03:44):

Yeah, I totally agree. And then you think of all of the vehicle parameters that either have to be estimated or established to run a Simon simulation or a 3D simulation compared to the EDSMAC version of it. There's so much more that goes into it. I guess similar question, what's your framework for thinking about what parameters of the vehicle need to be studied more intently than say default values or estimates? When do you decide, "Hey, we need to do tire testing," or how do you guide reconstructionists with that decision? When do you need to actually go measure spring rates and things like that?

Terry (02:04:29):

In the world in which the reconstructionist lives, we seldom know everything to a degree of certainty that, for example, let's say you're working at Ford Motor Company, you're in the suspension design section and you've got a 3D model of a Ford Taurus and you've measured everything. You know exactly what the stiffness of the bushings is, you know what the stiffness of the spring rates, you've got tire data for the real tires that are putting. In fact, maybe if you're in the vehicle dynamics department at Ford, you actually have two different sets of tire data and you have the data so well established that you are using computer simulation to decide whether I want to use a P24545R18 or a P255 45R18. Literally they get to that level. That's never going to happen in our world. Took me a while to get there, but you can understand that is just never going to happen in the reconstructionist world.

(02:05:34):

So the idea - We don't have

Lou (02:05:35):

All year to work on one problem.

Terry (02:05:38):

Or the budget and all of those things just prevents that level of expectation really. So I think if you have all of the parameters from a generic vehicle that are in the ballpark, and generic vehicles are built from actual measurements of large number of vehicles and then taking their average. So you're never going to have a bad piece of data. It may not be exactly the precise piece, but it's not going to be a bad piece of data. And in the world in which we, the reconstructionist lives, I think your expectation needs to be adjusted such that you realize that's the case.

(02:06:33):

So having reasonable estimates from a generic vehicle for vast majority of the parameters is going to be fine. Stiffness coefficients are an interesting question, comes up a lot. It turns out that if your stiffness coefficients are too soft, that you're using stiffness coefficients, let's say that are softer than the actual stiffness of the vehicle, what's going to happen in your simulation is that the crush is going to be a little deeper, the duration of the impulse is going to be a little deeper, the acceleration is going to be a little bit lower, but the area under the acceleration versus time history, which is the impulse, which is the delta V is the impulse divided by the mass, you're going to get a reasonable result for delta V and overall speed and speed change even though your stiffnesses are off by some pretty decent amount. So that's good.

(02:07:36):

That's doing simulation. That is not true in reconstruction. Reconstruction, totally different ball of wax there.

Lou (02:07:46):

Yeah, and that makes me think of performing sensitivity analyses, which kind of goes back to what we were talking about earlier with just matching evidence and looking at driver inputs and vehicle speeds and examining the path. But then like you said, how sensitive is, if you want to be able to handle the cross-examination question of, well, your stiffness coefficients were 300, 150, Mr. Peck, what if they were actually 280, 140? How does that change your conclusions? And to me, a huge part of simulation is a tool for performing sensitivity analysis.

Terry (02:08:28):

Yeah, absolutely.

Lou (02:08:29):

And it's huge because you can walk away with, yeah, it doesn't really make that big of a difference because there are, like you said, there's so many things that you don't know when you're performing a recon in general, you don't know everything. You have to know the weight of the vehicle and you need to know what roadway surface you're dealing with and the dimensions of the vehicle. But do we have to know exactly what the tire force is at a slide slip angle of that tire of four degrees or something like that? We're going to have to make some estimates in what matters, and it puts you in a really good position to be able to answer that kind of cross-examination, which you should really be performing on yourself as you're running a simulation, cross-examine yourself with respect to how sure you are of these input parameters, and you've written a lot about this, accuracy is a funny thing with respect to simulation.

Terry (02:09:25):

In fact, so that takes me to get on a little bit of a soapbox. One of the things that when I was doing reconstruction, one of the things that I never did was to say, well, you'd be asked the question all the time. It's a simple question. Lawyers, I think, are trained to ask this. Well, what is the accuracy of your answer? Is it plus or minus 5% or 10%? And I would never answer that. I would politely say, I can't tell you the accuracy. I'm going to go sidebar here for just a second, by the way. The validation studies show that the accuracy for known nearly perfect data is, like the EDCRASH program is, it's been a while, but minus four to plus 7% for linear momentum oblique collisions using linear momentum. And it's a little bit bigger than that using the damage analysis for colinear collisions.

(02:10:34):

But that is perfect data. And so for somebody to try to use those numbers and say, "Well, not probably plus or minus 5%," that just defies reality. It's just never going to happen. I mean, even with perfect data, that's kind of the ballpark we're in. So I would sidestep the accuracy issue. Like I said, when I used to reconstruct crashes, I would politely say, "I can't give you the accuracy, but what I can tell you is that I have analyzed this crash using a wide variety of impulse covering a wide variety of different vehicle properties, and I really can't do anything that gets the vehicle going lower than 46 miles an hour. And I really can't do anything to get the vehicle going more than 55 miles an hour." So I'm very comfortable telling you that the vehicle's going somewhere between 46 and 55 miles an hour.

(02:11:32):

That's all I can tell you. I don't know if it's 51. Nope, 46 to 55. That's the best I can do with what we've got.

Lou (02:11:41):

Yeah. And when you have that seat time and you've worked on that simulation for 10 hours or 50 hours or whatever it turns out to be, you walk away with a very strong feeling of what that range is because you've tuned so many knobs and you're like, if somebody comes at you and you're like, "Try 39," you're like, "Watch 39." It's not 39. There's no chance. And you don't get it any other way other than just running those sims and you walk away, which I was talking to Jared Carter a little bit about this, and I understand the perspective from both sides, don't get me wrong, but I like to run my own simulations. There's some things that I can give up in my workflow, but running the simulation is not one of those because it does benefit so much from experience and you learn so much as you're running that simulation that you are a much better witness in the seat, you're a much better expert providing information to your client when you've done that work.

(02:12:39):

And like you said, you know the bounds.

Terry (02:12:40):

Yeah, confidence.

Lou (02:12:42):

Big time.

Terry (02:12:42):

Confidence. Yeah.

Lou (02:12:45):

So this actually puts us in a really good spot with respect to my original outline and presenting evidence. There's a few things that you've said over the years that just stick with me, and if I remember correctly, this is one of them is if you're talking about the minutia of your simulation, you've kind of already lost. The goal is to not get into the tiny little knobs that you have turned in the simulation and talk more about the broad strokes of your simulation on the stand. Am I remembering that accurately?

Terry (02:13:21):

I don't recall having said that, but that makes sense. So yeah, I don't disagree with what you're saying. Don't

Lou (02:13:27):

Disagree

Terry (02:13:27):

At all.

Lou (02:13:28):

And that's the avenue that I've taken is when I'm presenting, at least on direct examination, what I've done for a simulation, I talk a lot about the way that you laid out the broad strokes. It's like we look at the car, we know what the damage looks like, we know the weight of the car and the size of the car, and we've examined the evidence and we've done photogrammetry to map out the skid marks and the gouge marks, and then we build this virtual environment in the virtual cars and we crash them together at varying speeds until we get a good match of the evidence, and this is what it shows. And I just try to keep it very high level like that. And in my experience, any detailed questions are going to come at deposition, and if you handle those really well, they're not going to want to talk about them in front of the jury because it just makes you look more and more prepared and more helpful.

Terry (02:14:17):

Exactly. Yeah, I couldn't agree more.

Lou (02:14:20):

So part of the reason I'm asking these questions is one, obviously you've been a reconstructionist for a long time, but then at the same time, you've been such an integral member or figure is probably a better word to use here in the industry. And you have probably had more conversations, detailed conversations with other reconstructionists about simulations and how they worked on their cases and what their testimony was, and just the ins and outs, seeing them present at the HVE forum than almost anybody. So the amount of conversations you've had with practitioners, you're kind of like a hub of all of what they have heard. And I'm wondering from both your experience and other people's experiences, how do you think about or how do you explain to a client or the judge or the jury what the strengths and the limitations of a specific simulation are?

(02:15:20):

Or do you leave that for if somebody asks you the questions about them or do you recommend presenting those out front?

Terry (02:15:27):

So I mentioned time-wise, in 1984, we introduced Ed Crash and then Ed Smack soon after that. Well, I'd been working as a consultant at Talbot Engineers up through November of 1986. We officially cut ties, I guess if I were to look back at it, I say at that point we had enough cash flow to sustain a meteor living doing this full-time. Didn't have to meet with Randy at that City Cafe at Monday mornings anymore, so we had a small office. And I started getting phone calls from attorneys saying, "Mr. Day, you're the guy that wrote this..." Well, okay, a big part of it. Yeah. So there's this guy who was just saying these stupid things. He's on the other side of a case I'm working on. "I want you to come and testify against him. One of my users, I didn't make that clear, I guess, but one of your users is saying just stupid things.

(02:16:30):

"Well, even though that's the attorney that's trying to hire you, that's his interpretation. But I realized right away that at that point that it wasn't going to be a very good thing for me to testify against my clients, against my customers. And basically, I think it's a conflict of interest, in fact, to sell software to someone and then testify against them. So I haven't officially been in the reconstruction business myself since I left Talbot Engineers in 1986. Now, as we all know, you get a job in October of 1986 and it comes to trial in 88, and then it goes to the appeal, and next thing you know it's 1990, you're still working the same. That kept me busy - Hard to retire. On a carry on basis for those cases. But I stopped really working on reconstruction cases full-time in 1986. And I haven't been in a courtroom situation since, I'm guessing, the early '90s, 92, maybe 93.

(02:17:42):

So with that in mind, there have been a lot of changes, and I don't currently go to court like 20, 30 plus years, obviously a long time.

Lou (02:17:54):

That sounds lovely. I

Terry (02:17:56):

Don't consider myself, especially with all of the new tools that are out there now, I mean, in the early '90s, total stations were just becoming popular to map out crash sites up until then. And basically when I was working, I used a roller tape, like the guy who's working for the Department of Transportation and he's putting down lane markers or something. I mean, it's just really crude tools compared to what's available these days. And maybe I'm going in a direction that isn't exactly where you want to go, but -

Lou (02:18:42):

No, this is on my line of questioning too, is that decision process. So I definitely would love to hear about it.

Terry (02:18:49):

Yeah. Well, I think that the tools that are available now, especially with LiDAR and drones and so forth, I mean, that's the kind of stuff that when I was first developing these tools and thinking about 3D environments, I mean, I could only dream of that kind of stuff, and now it's commonplace. So that's really an amazing, amazing improvement in the technology available for reconstructionists, and it's improving the quality of reconstructionist, no question.

Lou (02:19:28):

Yeah, it's interesting. That was another line of questioning was where you see the future heading. And it makes me wonder now after this whole conversation, Terry Day exists in 2026 as a fresh graduate from University of Michigan. What do you think you might be setting your sights on now?

Terry (02:19:50):

Oh, gosh.

Lou (02:19:55):

This is a fresh question just because I'm like, okay, if somebody with that kind of gumption and intelligence and resources, what boundary might you push on today?

Terry (02:20:11):

Tire models.

(02:20:14):

And I'm not sure that's going to be the best answer, but that definitely comes into play. So first of all, I should probably admit to something. I'm a physics guy. I've never really focused on 3D modeling of environments. I know that there are tools out there and the people that use those tools, I admire and they produce an incredibly important product. But my goal has always been the physics side of the world. And I'm a Mr. F equals MA guy. I can live, eat, and breathe F equals MA because so much of what causes any motion at all starts with F equals MA. And so you've mentioned the first principles. I mean, if you don't know how something works, you can always go to F equals MA and develop a model. The thing, and I mentioned this earlier, the thing that F equals MA doesn't tell you is how tires produce forces as a function of tire slip angle and inclination angle, vertical tire load, tire friction, all of those things.

(02:21:35):

I mean, people work at the tire companies literally spend their entire professional careers trying to better estimate, not calculate, they're always estimating. You always modeling.

Lou (02:21:50):

Is it empirical? Is that how they're getting data right

Terry (02:21:53):

Now? A big part of it, yeah. Flatbed tire tests. Yeah, a lot of it is very much empirical. The magic formula tire model is basically nothing but a set of equations that have nothing to do with tires, but then throwing coefficients into them based on tire testing that cause those equations to produce valid results for various in-use conditions, vertical tire load, tire slip angle, inclination angle, so forth. The limitation of a 3D vehicle dynamics model is pretty much always going to come down to tire models.

Lou (02:22:35):

I remember in your simulations class, that was one of my biggest takeaways is the simplicity of the Fiala tire model is kind of the simplest tire model that is in. I mean, except for just a straight linear, which is not that different than the Fiala, except you get the saturation, if I remember correctly. And then you go farther along, and then Simon and HVOSM, they're using more sophisticated tire models. And if you don't understand the limitations of your tire model, then it, again, puts you in this bad situation where you might not understand your simulation.

Terry (02:23:12):

Totally, totally, totally agree with you. Yeah, you have to have the tires right. You just have to have the tires right.

Lou (02:23:20):

It's the contact. Yeah, I'd be curious to see how that develops, because right now they're essentially just kind of scatter plotting things and fitting a polynomial to them of some sort.

Terry (02:23:31):

That's what the Magic Formula tire model is. The Delft University in the Netherlands has a version of the Magic Formula tire model that is used, basically the car companies use that tire model, but of course they have endless amounts of test data for the tire that they're working on.

Lou (02:23:52):

Oh, man. And it's expensive, as I'm sure you know. I'm sure you've worked with customers and helped them find tire testing, but I'm doing some simulation in bike sim, which is great, and it's amazing. And I have one case specifically, I had a few cases, I guess I should say, where I was like, okay, it'd be really a big benefit to know this exact tire. Strange case, and I wanted to use a very sophisticated tire model by Cosign F or something like that, an amazing tire model that they have. So I called up a couple places and they gave me their pricing for tire testing, and I was just like, I might as well go buy the motorcycle and do my own testing.

(02:24:32):

And that's ended up what we had, the testing center in Phoenix for exponent. We just went out there and did the motorcycle testing on their track, which was a great asset to have access to that. But it was cheaper to literally buy a motorcycle and drive it out to Phoenix and do the testing than probably to do two tire tests. It's just a tremendous amount of work, which I guess is part of what's limiting things now. But I'd be curious to see if with some AI models and modern technology, if they're able to come up with a more, I don't know about sophisticated, but more universal determination of tire forces.

Terry (02:25:17):

Yeah, I had never thought. I am the first to admit that. So I'm retired, I don't have to get up in the morning and start doing F equals MA. But the one thing that is happening right now that I am watching with a lot of anticipation, both good and bad, is AI. Having said that, I know very little about AI, but I hadn't really connected AI and tire modeling, but that seems like that might be a really, really useful thing to throw AI at.

Lou (02:25:54):

It's one of the things that I've found it to be most adept at is taking giant sets of data and starting to see what everything means because they can process it so quickly. Whereas humans need to come up with. I mean, I guess the model does too, the AI model, but anyway, humans have to come up with a hypothesis about the data and test that, and then another hypothesis and test that, whereas the AI seems to be in a position to perform a similar sequence. I'm not sure if it's logically the same thing, but just over and over and over and over and over, and then spit out something 10 minutes later that would've taken you four years.

Terry (02:26:32):

I'm going to go sideways here, but an example of that, I was listening to a person, a doctor from the National Institutes of Health talking about using AI to do cancer research. And his point about the use of AI is going to be, he said it's going to be a game changer because there's so much data out there and you could have a hundred people looking at that data for a hundred years and not see the trends. But if you throw all of those hundreds of data sets into an AI model and just walk away for a day or two and you come back, it could actually say, "Well, here, this gene, every single one of these cases has this gene, and you go for years or maybe never stumble upon that unless you got lucky, and yet that's what AI is so good at."

Lou (02:27:28):

It's exciting times. I mean, sure, we might all be out of a job in five years, but hopefully cancer will be cured. So yeah, you're retired now. So Tony Cornetto, who has been on the podcast.

Terry (02:27:41):

I'm glad you mentioned Tony. He's

Lou (02:27:43):

The man. Yeah. He's unbelievably intelligent and so far into this stuff. So how did that originate? Obviously, at some point, I imagine you're thinking like, "Well, I can't run this forever." So how does the handoff occur?

Terry (02:28:01):

So back in, I'd say the late teens, sometime in that range, people would take a look at me and say, "He's kind of getting older. I wonder how much longer he's going to do this." And of course, you've got a pretty significant investment in your software, so they'd say, "What do you have for succession plans?" And it was true, "I don't have any plans to retire anytime soon. Hopefully I don't get hit by a bus." And that would be the end of it. Tony was one of those people in 2019. We were at SAE, and Tony asked me that question, but then he said something that nobody else had said. He said, "Well, if you ever do decide that maybe your time has come to back off, I want you to tell me." So a series of things were going on later on in 2019, and I was thinking it might be the right time.

(02:29:12):

So I called Tony, I sai, "Were you serious?" He says, "Damn right." Okay. So that's how it happened. That's

Lou (02:29:17):

Awesome. Yeah, great guy to take it over. Yeah,

Terry (02:29:21):

Tony is bright. He's a really nice guy. He laughs easily. Yeah, he's just a really, really good human being.

Lou (02:29:33):

Yeah, I really have enjoyed getting to know Tony. I must have known him through friends of friends, but then I eventually met him at IPTM. I don't remember exactly when, but probably close to a decade ago, and we just hit it off right away. And then we did the podcast together, and the amount of things that he's clearly infinitely curious, so he's exploring a bunch of new things. I would agree with It's great to see because he's. And he just came out with these plugins for HVE, so it works really well with Blender now. And to your point where generating a CAD program to compete with AutoCAD or Blender doesn't seem like a wise move, and he's making these moves to make Blender and HVE work together seamlessly. It's really cool.

Terry (02:30:24):

And that's exactly the concept behind HVE is that it leaves the pieces of the task that are already done really well by existing mods. It leaves that to that model. And then that if you can import the results from that model, then bingo. And that's what Tony, you were just describing what Tony has done so well, a combination of Blender.

Lou (02:30:51):

So are you still involved with EDC at all?

Terry (02:30:55):

I teach the reconstruction and the simulation courses once a year, the reconstruction course, EDC reconstruction, which we've been literally doing that every year nonstop since 1985. And the simulations course every year nonstop since 1986. They're Zoom classes now, and the reconstruction course is late October, early November timeframe. I think this year it's the last week in October. And then the simulations course is the middle of January. And like I said, those are Zoom classes, one week long, and I teach those. And then the HVE forum is also a week long, but it's got this series of workshops. It's a matrix of workshops. So at any one point in time, there are three or four different workshops going on. You get to select the workshops. The HVE forum focuses somewhat on the physics, but it's also the place where you get the overall big picture training for the user interface and all the ways to make it jump through hoops for you.

(02:32:09):

That's a live in-person class usually taught somewhere in the Southern United States in the first or second week of March. This year it's in San Antonio, second week of March.

Lou (02:32:22):

Yeah, that's a cool experience too. And like you said, you get to pick what you want to go learn.

Terry (02:32:28):

And I teach the 3D physics portions of the HVE forum, the workshops, 3D physics workshops at the Forum.

Lou (02:32:39):

Yeah. So like I was saying before, you have such a large surface area with the community and you hear so many of the stories and help reconstructionists get through. I can't even remember how many times we exchanged emails over the years when it's just like, okay, I'm running into a problem here or what do I do with the coefficient restitution and the crush here or whatever. I imagine you're fielding questions like that pretty regularly or were fielding questions like that pretty regularly. And then the forum, you get to see everybody's presentations and see what they're going through. You've obviously just a very good feel for what I think reconstructionists are up against and have been historically. Kind of a long-winded entrance to, I guess, what would be your advice for young up and coming reconstructionists? What can help them have the best career or be the most, I guess, get the truest answer possible is I guess what we're all after.

Terry (02:33:47):

I think, and this option isn't available to everybody, but the ideal situation, and I'm going to toot some horns here, I won't name names, but you get my point. I think the best scenario for the entry level reconstructionist is to go to work at one of the big firms that has a hundred engineers working for them or 50, 100 engineers. They have huge budget cases. They've got training, they've got proving grounds, they've got test facilities, because you could learn so much by being exposed to that that you will never learn otherwise. I think that's the ideal scenario when you get there and you - Get

Lou (02:34:35):

Thrown into these huge cases and see how they're being worked up.

Terry (02:34:40):

Yeah. And just to be exposed to the tools that are available and the people that you meet and the knowledge that you. Osmosis is a very good thing. And then of course, once you've got everything that you've learned, once you've learned everything that's possible from these people, then you go out and start your own firm and you become infinitely successful because your background is so, so thorough and so deep. That's my take. I did not follow that path by the way.

Lou (02:35:17):

But yeah, that's okay. Yeah. You see what the ideal path might look like. And it's so huge. I was saying that earlier too in another podcast where it's like there's a lot of who luck in the business and you don't really know what the culture is like where you're going until you're in it, but it makes such a big difference to your potential career path. And for me, what you're talking about was when I first went to work with Eric Dial and just saw him performing these simulations at such a high level, caring about every single detail.

Terry (02:35:55):

Yeah. Eric is a gem.

Lou (02:35:57):

He really is. He's so talented with respect to the simulation stuff. It's wild. And that's how I came into your ecosphere. And it was great to be a part of that and see that kind of high level simulation and the questions that you could answer with simulation that I hadn't even considered could be answered with simulation. The way I'd been exposed to it prior was a different thing. And the people you're around, the five monkeys you hang around with the most, you're going to start acting like those five monkeys.

Terry (02:36:30):

I would also take the opportunity to mention that that's one of the great things about going to the forum is that you'll be rubbing shoulders and elbows with 40 to 60 other people who are just as interested as you are about really doing this job well. And everybody has their own experiences. And so the networking that occurs at the forum is incalculable in terms of getting it any other way.

Lou (02:37:04):

I totally agree. The amount of acceleration that you can receive from somebody just saying one line to you about the way that they're handling a situation. I

Terry (02:37:12):

Would agree.

Lou (02:37:13):

Thank you so much, Terry. I mean, you made such a tremendous impact in this community and I really appreciate you sitting down and taking the time to talk to me and to share your stories with everybody.

Terry (02:37:25):

Well, I enjoyed this immensely and I appreciate the opportunity to talk with you and to see you. It's been a long time since I've seen a lot of these people. There are a lot of people that I still remember very, very fondly and I think about. And then there's a lot of new people that I see at the forum when I go there. And that's great news because the younger generation coming in with everything that they bring to the table is just great. So anyway, I've really enjoyed this. So thank you very much, Lou. I appreciate the opportunity.

Lou (02:37:59):

Thanks so much, Terry. Hey everyone, one more thing before you get back to business, and that is my weekly bite-sized email to the point. Would you like to get an email from me every Friday discussing a single tool, paper, method, or update in the community? Past topics have included Toyota's vehicle control history, including a coverage chart, speed from video methods and tools, AI and recon and the courtroom, Bendix data and handheld laser scanners. If that sounds enjoyable and useful, head to lightpoint.com/tothepoint to get the very next one.