OK I lied - recommended reading and then I'm done for 2010

Yes, it is that boring sitting around on Christmas Eve in the boondocks of Colorado. To be honest, doesn't even feel like Christmas at all! In any event I'm assuming some of you folks might be in similar situations or have some spare time to screw off over the next couple days. As such, figured I'd share some good online reading material that I've been following.



Hyperbole and a Half

One of the funniest things on the internet. Suits my sense of humor perfectly. The title really describes the content quite well, and I'm not sure what else to really say! She's cute, too! But unfortunately (for me) not single.

If you like simple funny drawings and sarcastic hilarity, scope it out.




Smart Football

Believe it or not, American football at the professional level is a very cerebral game, and takes some definite mental capacity at every position (not just the quarterback, a la Peyton Manning). Even the 300lb offensive linemen have a lot they are responsible for knowing on every play. If you don't believe me, take a look at an except from the Cardinals playbook (10 pages, from ESPN)... or you can download all 463 pages of the 2000 New York Giants offensive playbook (10MB). 463 pages just for offense, let alone defense and special teams.

In any event, Smart Football by Chris Brown is a cool inside look at football strategies... how the plays are designed to attack different defensive schemes, or how to confuse and attack the quarterback. Really interesting shit, and has made me enjoy the game a lot more since going to games smashed while in college. Even gets into some statistics of analyzing different teams or coaches tendencies in certain situations, etc.



Scarb's F1 Blog

Craig Scarborough describes himself as "a freelance journalist\illustrator who focuses solely on the technology of F1." (and in this case, the Audi R18). Pretty good technical look at a variety of technical aspects of F1 development. Fantastic illustrations.

Includes anything from aerodynamic development, recent trends in setups (including the option of no rear corner springs), sensors, ancillaries, etc.



Vintage Metalworks Blog

Dave is one of my coworkers who enjoys metalworking and restoring old cars. Personally I've always been big into machining and TIG welding since college, but Dave takes it to the next level with some really fantastic sheet metal work. Only started blogging recently, but I expect this to have a lot of good content in the next year.

Incidentally, that photo on the right is the Fadal 3-axis VMC that currently resides in his garage. Fun little side venture - he picked up the bill on the machine, and I bought most of the tooling. While mechnically it's vintage 1987, the controller has been upgraded to a 2006 model. Need something machined? We'll do it for a fair price!

Allrighty. Merry Christmas, ladies and gents. I'm gonna have a beer, watch Law & Order, and play with the dog.

Last entry of 2010

I'm out in Durango, Colorado at the moment... visiting my folks for a week then spending a few days up in Boulder & Denver for shenanigans with college friends. As boring as staying with the 'rents is, I didn't bring much with me so I can't really do much racecar work. I do have a good update though!

On the simulation stuff, I made a huge step forward in the code. The previous cornering model was pretty crappy to be honest - constant velocity. I changed that up and have brake and throttle modulation working. I also changed the way it solved the straightaways. Check it, suckas-

I mean for Christ's sake, the previous version took longer to run than the lap itself! Cut it down to 5-6 seconds to solve. Also got the lap times much closer to reality... I had forgotten to make a conversion from feet per second to miles per hour so my lap times were off by 50%! Still, this isn't fully tuned... but I know the F1000 cars at Road America this year were running anywhere between 2'03"s and 2'20"s or so.. and I'm at 2'13". All is looking good.

Some interesting stats on the blog itself... with some of the stats Google started giving me:

• Total views: 12,285 (don't think it started counting until middle of year)
• Views in last month: 3,350
• Views back in September: 1,957
• Followers: 84... that I know of

I appreciate all the comments everyone has left - I try to reply to all of them. If you have a question or comment or whatever, feel free to leave it.

Despite the slow start this year, think I got a hell of a lot of momentum going here toward the end. Looking forward to 2011 - both personally and professionally. Hopefully making amends with some people (one person in particular), maybe making some decisions on what direction I want my life and career to take. Lot of things to consider.

In any event, I thank all for stopping by and hope everyone has a good holiday. I'll catch you all next year-

Jersey Tom - Giants fan, vehicle dynamics engineer, tire data guru, and all around cool guy

A thought - LoLTD vs. LaLTD

Been quiet here for a couple days. Got a call from my friend on Saturday morning telling me to drive the 460 mi / 740 km out east since he had scored Giants tickets from some random dude at Starbucks.

Unbelievably embarrassing loss to watch in the last seconds of the game, but hey, what can ya do. Play the next game, keep marching toward playoff contention. Thankfully we had Sorrento's (probably some of the best cold subs you can find in the entire goddamn universe, 100x better than anything in Ohio), so that dulled the pain. Personally I recommend the #1 with onions, lettuce, tomatoes, roasted peppers, oil and vinegar, salt and oregano. As for drinking at 930am? Don't judge.

Back to the point at hand, I wanted to get a couple notes down for my own reference here. In vehicle dynamics parlance, 'LLTD' commonly refers to lateral load transfer distribution - a key number for cornering balance. An extreme example of front LLTD bias is shown below. Boogity boogity boogity.

One would think that there's an analog to this in the longitudinal direction (hence Longitudinal Load Transfer Distribution versus Lateral Load Transfer Distribution). It might be nice, on-throttle when the car pitches back, to be able to transfer more load to the inside rear tire for extra forward bite (exit speed is king) at the expense of front axle lateral capacity. Yes, you can have power-on understeer even on RWD cars.

On a road course car I can't imagine having much difference in wheel rate left-to-right on the chassis. Can we do it with some tire rate and kinematic trickery like we talked about before? I suppose if you start with negative camber all around... as you go into roll in a corner and the tires all gain inclination in one direction the insides will have a softer rate than the outsides, and your LoLTD then biases itself to dump load on the outside rear. Pretty much stuck with that with a SLA suspension. Shit. Well, at least it's something to take into consideration and highlights the importance of having good tire rate data over a range of conditions.

I crack myself up

Good quote...

...by the infamous Bill Cobb. Don't roll your eyes too much.

Having a Matlab wizard on a race team is as important as having a tire or engine specialist. There ought to be plenty of work to keep them busy. This is New School Racing theory. Old School is struggling...

Trail-braking: AKA, "Not driving like an idiot"

Let's get ready for the meat of tonight's discussion. You'll probably need to put on some tunes, it gets lengthy. Credit to Laura for this one (an incredibly bright masters degree aerospace engineer with a passion for wedding planning and such - hence the blog).

If you've seen my earlier sim outputs, they drive the corners at constant speed (the apex speed - it's driven as a constant radius corner). In other words, all braking and accelerating is done in a straight line. Only reason for that was for simplicity, ease of coding, and getting something simple up and running. If you were to look at a plot of the driver's instantaneous inverse corner radius along the length of the track, it would look something like this:

In reality if you drive like that, you're going to be at the back of the pack. Not going to go into the details why here - feel free to read any number of racing or driving publications. In any event, given that trail-braking (and throttle modulation out of the corner) accounts for such a big improvement in lap time I was getting pretty skeptical that my sim in it's current form would give accurate direction results at all. As an aside, you can look at 'inverse corner radius' as a way to quantify the line your driver takes over the course of a lap, or a couple laps - even if speed and lateral acceleration change. If you're data logger is grabbing velocity and lateral acceleration it's a snap. Alternatively I believe it's a canned math channel in MoTeC i2. Can't say I came up with it.

Anyway, the other night while laying in bed and I got to thinking - I'm way behind on Christmas shopping, I haven't had Peking Duck in a damn long time, was completely boggled my some woman issues from this summer, and then the next logical thought in the progression was how to solve this combined acceleration problem. Might be easy.

First step - cut in the corner into two halves.

My corners already have an assigned value for apex radius and total length / duration. I'll have to set an additional variable for apex location as a percentage of the total corner duration. This way I can look at which corners benefit from early or late apex (if I'm crazy enough to do that later on). I pick some arbitrary way of defining how the radius transitions through the corner - maybe with a spline or parabola.

Second step - establish combined slip friction ellipse
I've talked about this before here. Earlier I was talking about the ellipsoid being stretched due to downforce but you'll have it from mechanical grip as well. Simple example - you have four tires to brake with, and only two (in this case anyway) to accelerate. In addition to having the ability to specify unique values for braking and acceleration I'll probably also have the ability to have unique values with left- and right-cornering. Don't think a road course car would have an asymmetric setup? Take a look at Lime Rock Park. Might as well be NASCAR in reverse. Only has one left turn, and six rights.

Third step - solve each half's forward velocity trace
Really similar to how you'd solve a straightaway... though this time my acceleration function is going to be based on the engine torque supplied and delivered at the wheels, or the combined slip ellipse (whichever is lower).

For braking, I can do the same shit in reverse for the first half of the corner. Honestly the only hard part is going to be putting in enough code  to make it do something realistic when you have a corner that you don't brake for and accelerate through. I'll have to figure that one out later. Once I get this corner thing figured out though, the straights on either end should still solve themselves just the same. All this work is going to have to be put off until another night anyway. Still got other stuff to do tonight. Apparently there's a pro open-wheel team starting to look for FSAE grads with vehicle dynamics and simulation experience. Hmmmm. Tough life and career decisions, just as I thought I was ready to settle a bit and move back east or west. Then again, who would want to leave the wonderful world of working at a tire company?

As a final note, you'll see that I slightly changed the name of the blog. I got a kick out of it. If you don't "get it," you're missing some good books in your library.

Speed and accuracy improvements

First off, let me tell ya... you can make just about anything into a delicious Mexican-tasting dish with liberal application of ranchera sauce. Seriously, this stuff is good. Threw some remnants of rotini, farfalle, and chicken together with some shredded rice and half a bottle of sauce. Tasty as all get out. My all time favorite dish with this type of sauce is of course 'arroz con pollo' - particularly of the style available at Tequila's. If you're passing through any of those locations in Colorado I suggest you stop in and get it. You can tell them Jersey Tom sent you if you'd like, but they'll probably reply with, "¿Que? ¿Quien es este pendejo?"

Anyway, just as I was getting to the point of saying, "Well shit... anything more to this sim thing is going to be a real pain in the ass," I had a couple pretty good ideas to improve the realism and accuracy as well as solution speed.

1. Replace integration scheme.
I considered explaining the concept of numerical integration here, but instead I'm gonna direct you to Wikipedia if you're a non-engineer and really that interested about it. As I was mentioning in the earlier post on the topic, for the moment I'm using a dumb rectangular-method integration method. Generally the least accurate of any method I know, unless you're using a random number generator. Think I'll upgrade to the trapezoidal method for now, which is plenty sufficient given that the accuracy limitation will now lay in the engine torque function which is doing linear interpolation anyway.

Another viable option is to replaced the fixed time step method with a variable step method... but I'm not too excited about that at the moment.

2. New way to solve straightaways.
Currently my sim finds the braking point on a straight by stepping the initial application point backward 1 foot at a time, starting at 0. If you have a long braking zone, that takes a long damn time. At first I had been thinking of implementing an adaptive algorithm that increments the braking length in large steps if it's way too fast for the following corner. Better method is to do a single forward integration of acceleration from Turn X, and a single "backward" integration of braking starting from Turn X+1. The brake application point is their intersection. Bam! This alone should make the damn thing run literally 100x faster.

3. Add trail-braking and throttle modulation into and out of the corners
Whoa, now. Think I'm going to have to make a separate entry about this, because it's serious stuff. So serious that it precludes the inclusion of Mexican sauces.

Weekly news - Australia beats UK!

Turns out blogger.com gives me the option of looking up traffic stats for this site in a variety of ways. Giving an engineer data is always a bad decision as invariably they will waste way too much time looking at it in every way imaginable, and then ultimately present it in such a manner that suits their own ulterior motives, hidden agenda, or mood.

Not only do I get to see this, but also where people came from that clicked links to this blog, as well as Google search terms that brought them here as well! Some of the search strings were pretty interesting. In any event, this week saw a boost in views from Australia, mainly on account of a couple forum posts from Race Magazine. Welcome Aussies. Also had a few referrals from a 'Formula SENA' forum which I believe originates in Columbia. From what Spanish I recall, the post title was basically, "This blog has interesting pictures." ¡Bienvendio!

...e io sono un po triste che ci sono poche persone dall'Italia. Spiegate la parola, miei amici italiani!

For anyone else casually reading the blog, feel free to click the 'follow' button over on the right. It's interesting for me to see how many people check this out on a regular basis. 83 and counting!

Road America!!

While the actual project lap time is way off, for the most part this matches some real F1000 data at this track - surprisingly well considering I'm taking blind guesses at most of the car parameters. There are a few reasons for the time being off, but I'm not too worried about the absolute values as much as the relative change. Still have plenty to tweak for drag, downforce, and tire grip... but this is a pretty promising result.

Even in its rough state, I played a bit with it over 3 sim runs.

1. Baseline
2. Base lateral grip + 5%, longitudinal grip -5%
3. Base lateral grip -5%, longitudinal grip +5%

Not going to give away which did what... but one of them results in about 1.2% better lap time compared to the base, the other is 1.3% slower. On a 2+ minute lap at Road America, I'll let you figure out what time differential that is. Of course since this model has no combined mode operation, it's tough to say if it's directionally correct.

A lap around Martinsville

Ladies and gentlemen - holy fuck, we've done it. Some upbeat tunes are in order. If you're not a fan of my tunes, well, that's why this is my blog and not yours.

Allow me to show you a 30.1 second lap around Martinsville:

 

Right about now you may be saying to yourself, "Daaaang homie, that shit is fly." Alternatively you might be saying, "Well that looks fuckin' dumb." You'd be correct either way. It's a dinky little short track, it's not gonna look very cool. Also, admittedly, a 30 second lap at Martinsville is pretty damn slow! Cup cars (NASCAR) get around in under 20 seconds. However, my numbers for drag, downforce, tire grip level, and gearing, are all arbitrary. Also, my "driver" doesn't trail brake nor ease into the throttle, so again - absolute numbers are BS.

Believe it or not, for weighing literally over one ton more than a F1000, Cup cars also have a better power to weight ratio. A 358 ci (5.9L) V8 turning over 9000 RPM will do that!

Still got some stuff to check out to make sure everything looks legit, and then I can start breaking down a road course and seeing what it comes up with. Will have to see if I can dig up some actual F1000 DAQ at some racetrack to back-calculate appropriate numbers for drag, downforce, and mechanical grip. But for now... I'm catching up on Mad Men.

Baby steps - can put a straightaway together!

Nothing too thrilling tonight. First, credit to Liz C for turning me on to People Under the Stairs.

Good tune to sit back and have a vodka on the rocks.

Anyway. Pretty much got the straightaway stuff squared away. Making the ghetto solver was definitely a blessing in disguise with being able to set a distance limit for integration, rather than time. I'm sure that excites you - in many ways.

So for example we can come out of a 30 mph corner down a 1000' straight and back the braking point up in 50' increments:

 

Not super thrilling to look at, but important. There is time data that goes along with the velocity and distance outputs, not shown here. All the numbers for drag, downforce, and longitudinal tire grip are just made up at the moment so don't heed too much attention to it. If I wanted to be really fancy I could probably put a segment in the acceleration solver that puts a delay between gear shifts. I'll screw around with that a bit down the road.

So next up I need to make a quick and dirty corner solver (find max speed a corner of given radius can be taken, when including both tire and aero effects) and then the actual full lap solver. To actually run my first sim I'll need to define a track. Road America, Mid Ohio, or even Nelson Ledges will take some time to break down segment by segment. Therefore, as a first pass to make sure the damn thing works at all, I'm going to start with the most simple track I can think of...

Martinsville!

View Larger Map

Should really be able to wrap most of this crap up by this weekend, which is good given that I can potentially get out and be social. You would be amazed at the look of raw animal lust in a woman's eyes when I strike up a bar conversation about racecar vehicle dynamics.

Gearbox added to engine model - more or less

Positive - Added a transmission to my engine model.
Negative - Canned ODE solver no longer produces a believable result. To be honest, I'm not sure what the hell it's doing at all!

Solution: Ghetto-fy it. As in, my integration scheme is as follows:

y(i+1) = y(i) + yprime(i) * timestep;

Yeah, I know. Not exactly Runge-Kutta. But hey, whatever. Wanted something quick and dirty to make a result. It's an easy problem to solve (linear interpolation of the torque curve), and I have plenty of CPU power to just muscle it. I'm sure my other solver is failing out because of some accuracy or tolerance setting that I'm too lazy to fuck with at the moment.

To a degree this might be nice, in that instead of setting a time span for integration I can go one more step and calculate distance, and have the solver cut off after a certain amount of travel. Ultimately that's what I'm interested in for doing straightaway sims.

Here's the result though, with the following parameters. It's a little goofy under 3000 crank RPM since I have no dyno data, so I filled in some BS numbers (engine is pretty much stalled at that point!). By "Engine Thrust" it's thrust at the tires, coming from the engine. Obviously with the data below 3000 RPM being crap anyway, the 0-60 time isn't even worth looking at.

• Car weight: 1000 lb
• Drag model: Tuned to generate 400 lbf at 120 mph (arbitrary numbers)
• Final chain sprocket reduction: 3.250
• Rear tire OD: 22.6"
• Shift point: 11,000 RPM

Next up.. I'll have to clean up this solver and add the distance output and solution limit, then do the same for a braking sim, then start building the actual lap solver.

More success!

Giants beat the Redskins 31-7, I picked up some decent Chinese food, and I got more shit to work. Made a dinky little simulation run with a rough CBR1000 torque curve, a single gear, an arbitrary number for inertia, and a drag model tuned for a drag-limited top speed of 100 'units'.

 

You pumped? I'm pumped. I texted Brandon and Justin about it and they got pumped too, see below:

Next step will be to add some logic to the thrust model that flips between gears based on velocity. Shouldn't be too difficult. That will have to wait till tomorrow. I'm sure I'll be in a stellar mood tomorrow when I wake up early, see god forsaken snow outside, and then have to drag my ass outta bed to get ready for another week at work. Woo!

Piecewise ODE FTMFW

Believe it or not I am pretty excited about that plot - it is the solution to a piecewise ODE function.

if y <= 10

   yprime = 1

else

   yprime = 2

end

Implication is that I can supply a discontinuous function for my acceleration and braking simulations - for example, an actual bike engine torque curve and gearing.

Of course in college they have you dick around finding closed-form, analytical solutions to differential equations. That's of limited or no value here! Still wish they'd have a course - "MCEN3010 - How to actually use this shit for real world problems."

Might try the torque curve bit later today depending on my mood - which will be predicated on if the Giants beat the Redskins, and how many beers I have.

Well shit, might need some new ODE's already

Did a little test to see if I could get an ODE to solve at all. Simple one worked just fine. One I wrote out for my on-throttle bit? Not so much. I'm not entirely sure why it errors out, but I do have a thought.

1. It does shoot to infinity at v = 0. Even though the initial condition will always be greater than zero, I have a feeling this may be an issue. May be able to work around it by making a piecewise differential equation and clipping the engine thrust at a value where the tires would break free anyway. Hey, it's a numeric solution, why the fuck not?
2. The constant power thing isn't as straightforward as one might think. What value do you use? Obviously it isn't going to be peak power - so I have to think up some average over the power band. Interestingly, thinking about a 3200ish lb sportscar with a 0-60 time of 4.7 seconds (like the Nissan 370z), that's only an average power input of about 150hp, of the 330 rated output power. Of course, with 0-60 so dependent on starting line hook, and higher speeds introducing aero drag effects, it's not a good way to come up with an scaling value.
3. If I'm making a piecewise function out of the accelerating ODE anyway, I suppose I could use an actual torque curve and gearing - picking an appropriate gear based on speed (x dot), then looking up RPM and torque. 

I'll have to think about this crap more tomorrow.  

Lap sim - you down with O.D.E.?

Yeah you know me! Actually, truth be told, by the time I took Differential Equations & Linear Algebra (APPM2360? I don't remember) I was so burned out on applied math that I retained pretty much nothing. Additionally, that was probably Fall '04 semester so it's been a while.

Before we get into specifics of writing out ODE's, let's think out loud on how the hell I'm even going to get this to work. Invariably the first thing to do is establish some assumptions. Whenever you're doing any sort of simulation or model or whatever, you are not recreating reality. Get that notion out of your head, forever. You are creating your own abstraction of reality with whatever physical laws, rules, and limitations as you see fit. These might be based on lack of necessary data (e.g. tire data), lack of the skill set to make something really fancy (e.g. me when I was in college), or constraints of time and money (e.g. running a simulation on a laptop rather than a cluster, or desk side supercomputer - badass!).

Here's what I'm thinking as far as assumptions:

• Point model - no kinematics, tire data, load transfer, or anything of the sort.
• Mass fixed at 1000 lb (at least initially, may evaluate being over minimum weight)
• Forward thrust available from the engine at a constant power - i.e. inversely proportional to velocity.
• All cornering done at constant velocity and radius - at max lateral capacity
• All acceleration and braking done in a straight line
• No rolling resistance effects
• Downforce and aerodynamic drag proportional to the square of velocity
• Mechanical grip (coefficient of friction) values in x- and y- directions held constant. Down the road, it would be interesting to do a sensitivity study and do a number of sim runs, altering the grip level of one corner at a time. Goal - determine which corner has the biggest impact on lap time, and focus steering and balance tuning toward that corner.

As far as how the thing would actually work... first step would be to run through and establish the maximum speed each corner can be taken. Pretty straight forward. The second and much more difficult step essentially comes down to finding the braking point (if there is one) on every straightaway. Haven't entirely figured out the specifics, but roughly:

1. Pick some arbitrary initial guess for length of braking zone on this particular straight
2. Use the initial velocity of the on-throttle portion from the previous corner
3. Run ODE solver over the length of the on-throttle portion to establish a velocity trace
4. Use the final velocity from on-throttle as the initial velocity of the braking portion
5. Run ODE solver over the length of the braking portion to establish its velocity trace
6. Use some sort of goal seek, objective function, or incremental loop to work the braking point backward until the final braking velocity is at or below the next max corner speed. Need to be as close to it as possible really.

For that last step, the incremental 'while' loop backing the braking point up a little bit at a time is probably the 'dumbest' approach in being computationally inefficient, but also the easiest to program.

So we come to the actual governing ODE's themselves...

On acceleration:

On the brakes:

Bam! Easy, assuming I remember anything from sophomore year. There have been many beers consumed between then and now (including a few at lunch today). I'd probably be a halfway intelligent guy if I hadn't drank like hell my last couple years in college!

Anyway. Now comes the hard part... actually making it work in code.

Getting back to top-level engineering

You may be wondering why I've prominently displayed Lady Gaga here at the top center of the entry. Turns out, if you use the 'Pulse' reader app on your Smartphone (from the folks at Alphonso Labs), the preview icon for new Blogspot entries is whatever the first image is in the article. I wanted my latest preview to be something ridiculous (yes, I am easily amused). By the way, if you don't use Pulse - you should!

Much of the work I've posted up here has been "nuts and bolts" level - CAD and such. Generally this is opposite the design philosophy I preach of starting high-level and working down to specifics (up front engineering). At the same time, the CAD work has been done parametric enough so that I can go in and change my suspension points etc and have the model rebuild more or less painlessly. Anyway, it's to the point where I should back off and do some top-level design work.

I'm gonna go ahead and put on my musical selection for tonight before we get going.

Recommended reading material -this thread at FSAE.com, particularly Geoff's ('Big Bird') lengthy post November 30th, and the section 'Analysis Process.' Some really good takeaway points, namely-

1. If you start simple with analysis and predictive work up front, you can get some real good design insight before anything is set in stone.
2. Even college students can cobble together meaningful vehicle simulation programs over a couple days, in Excel, including beer breaks. 
3. It's critically important to identify the relative importance of various performance attributes. You do not have infinite time or resources in your design cycle, ever. I've seen a number of engineers (mostly in college) get so sucked into minutiae that they completely lose sight of the big picture.
   
   "But if we do that, we're going to be giving up some handling!"
   "Yeah, and if we don't, the driver won't fit."

I've thought about it, and I might try my hand at putting together a rudimentary lap sim myself. Time investment may only be a couple nights worth of work. If it doesn't pan out from there, no big loss. If it does, I can always add in complexity. The great thing is everything builds on itself. No wasted work.

As an aside, it's amusing to me that for as aroused as FSAE students get for designing around kinematics, body motion is really a few steps up the ladder in model development. More fundamental things like tire cornering stiffness are sometimes overlooked. I wonder if I polled a number of kids the next time I'm at MIS, how many would be familiar with VSAL and how it defines camber rates, while not being totally familiar with tire properties.

We've established that we can simplify and build on vehicle models, but same holds true for track models - maybe even more so. Can probably simplify the hell out of a track model!

I can take some pretty damn big liberties in a track model - the lengths of straights, corner radii, etc. Why? Because I don't care what my exact lap time around Road America is going to be.

For one, you're never going to be able to predict it, within tenths anyway. Track condition, ambient conditions... enough to swing grip, downforce, engine power enough such that the time it spits out won't quite be right. Parameter identification based on previous race results is one thing - future is prediction.

Second, I'm not designing a chassis for Road America. I'm designing a car for Nelson's Ledges, Mid Ohio, and Road America and whatever else. So long as I have track models that are roughly representative of a road course, I think that's good enough for the majority or entirety of up front engineering.

Some interesting work ahead.