Optimum Lap Simulations

[drive2win]

I was wondering if teams were able to accurately select Final Drive Ratio using Optimum Lap. We tried simulating our vehicle in Optimum Lap and found some weird errors. One example was when we simulated a rear sprocket of 30T and 50T, we got the same acceleration and very similar lap times.

Just wondering if anyone else had this issue? Also any alternative ways to select Final Drive Ratio would be great to read.

[CWA]

How much power / what engine curve were you using, and what were your tyre friction estimates? Your results would be valid if the vehicle was predominantly traction limited for each test condition of each event.

Without meaning to be patronizing, how much time have you actually spent analyzing your observations objectively before jumping the gun and blaming your unexpected results on any software 'errors'? Try comparing your results with some basic hand-calcs as a sanity check, you might be surprised..

[theTTshark]

Chances are you aren't taking into account your gear boxes built in primary reduction drive that you have to include in your final drive.

[MCoach]

When doing this compared to our track data we found that Optimum Lap was overestimating the time we spent traction limited, like a lot. See the above suggestions because they're valid assuming low experience. A lot of people aren't aware of the primary reduction, but also check out the traction graph that OL shows.

[drive2win]

Yea the problem does seem to be the traction values for Long. and Lat. I'm going to update the whole thing and try again.

Thanks for the input

[JT A.]

OptimumLap was very accurate in predicting our sprocket ratio. We simulated a 37/11 ratio in OptimumLap and the sprocket ratio on our car turned out to be exactly 37/11.

Unfortunately, we don't know if this is the best sprocket ratio, because while I was in school the team insisted (and still insists) on using a very cramped rear end design that can only fit one size of sprocket.

[DougMilliken]

... the team insisted (and still insists) on using a very cramped rear end design that can only fit one size of sprocket.
Going a little off topic, but maybe this discussion is ready for some humor?

Your comment reminds me of a discussion on bicycle gearing. A couple of years ago a friend wrote, "...consulting with {redacted} cycling program right now, including BMX. I can tell you that they are absolutely married to the idea of 44 x 16. That is simply the right gear. End of discussion."
Of course this might not be *exactly* right--which may have been the seed for the following "invention" --
http://www.bmxnews.com/2010/11/podcast-rennen-revolutionizes-bmx-gearing/

[BillCobb]

Student engineers should keep their thinking caps on 24/7.

[BillCobb]

"Its always the spaces in between". Battle Hymn of FSAE.

https://www.youtube.com/watch?v=gcCJQP5iggU

[drive2win]

JT A we had that same issue last year, we ran a 32T because nothing else would fit, and chassis and drivetrain were designed separately. Its one of the growing pains with a new team. Its our first time using Optimum Lap, so I just wanted to double check that nothing was "wrong" with the software.

[CWA]

Its our first time using Optimum Lap, so I just wanted to double check that nothing was "wrong" with the software.

There may be something 'wrong' with the software, of course. You may have uncovered some kind of bug in the software that OptimumG were not aware of (unlikely, as your user case seems rather normal).

Before you start considering this possibility with any seriousness, you should FIRST be looking at what mechanisms would cause these results, look to explain why your results didn't match your hypothesis (I assume you expected 50T to give you a faster acceleration event time?). You should always be working on the basis that your hypothesis was wrong, before looking at your tools being wrong. Don't forget, your hypothesis is likely based on a couple of years of engineering learning from a couple of students (correct me if I'm wrong). The software is likely based on decades of engineering experience from greater numbers of professional engineers, plus months of development time to give robustness.

This is not to say the software isn't limited in what it can predict, you may have been bordering on limitations of the model, but model limitations are different to software bugs. "All models are wrong, some are useful" should be remembered here, and related to my point above, it is up to you to understand the model and it's limitations well enough so you will know when you should and should not trust results. Do you think the "point-mass" nature of the model is giving results that would not be repeated in reality for the conditions you have tried to simulate? Do you think a point-mass model does not capture some mechanisms that you think are critical for a representative acceleration or full lap simulation? If so, try to think about why.

As a sanity check, do the maths for this situation and post the results OP:

Take your vehicle's top speed at the end of your simulated acceleration event,
Using the peak power value of your power unit, calculate the force at the contact patch at the above speed when peak power is seen,
With your chosen longitudinal coefficient of friction and vehicle weight/geometry, will your driven tyres be saturated or not?

[JT A.]

I should first state a disclaimer that I haven't used OptimumLap in a while. When I did use OptimumLap, I never found anything "wrong" as far as bugs. But the bottom line is OptimumLap is a model...which reminds me of one of my favorite quotes from a professor - "All models are WRONG, but some are still USEFUL".

The first step before you use any model is to understand how it works, what are it's assumptions/simplifications, how significant are they, how that will affect the results, what scenarios is it well suited for, what scenarios it isn't equipped to handle, etc. One of the big things I remember about OptimumLap is that it doesn't really have a built-in way to model a true "launch" like you would do in an acceleration event. As I understand it, the simulation starts from 0 mph, figures out what RPM that corresponds to (0), looks up the torque at that RPM, and uses that to accelerate the car to the next increment of time/distance. How representative is this model, when in real life you would launch from a set RPM somewhere near your peak torque? The way I worked around this was to set all the torque values from 0 RPM to the launch RPM to the same torque value. As long as the launch RPM is at the bottom of your powerband, this shouldn't throw off the results of autocross/endurance simulations very much, since it shouldn't be dropping below the ideal powerband anyways.

[CWA]

...which reminds me of one of my favorite quotes from a professor - "All models are WRONG, but some are still USEFUL"

That's a good one, where have I read that one before..

[drive2win]

I think I figured out the source of the problem regarding lap times, For every gear ratio it is telling me that I am launching from 5th gear (We have 5 gears). I have plugged back the values for the torque curves, but I cant figure out why it is saying that when "Elapsed Time"=0 "Engaged Gear"=5. I have compared some hand calculations to results under the same time but at different gear ratios, and found where our errors were.

Any advice to why the car is launching from our top gear?

[MCoach]

drive2win...I have hunch.

How is your information entered for your engine gears and final drive data? Is it in decimal format or fractional?
Would you be willing to screenshot at least a part of it for us to take a look at? Maybe there's a hint there, but I could be wrong.

[drive2win]

Hey I have attached a pic of the "Engaged Gear vs Distance" Graph and the gear ratios. Its weird because when I ignore the the primary and secondary reduction ratios the graph starts in first gear, but when I include the primary and secondary reduction the graph starts in our top gear.

Thanks a lot for helping out.
477

[drive2win]

I re posted the picture twice im not sure which one is easy to see.

[CWA]

I'm curious to see how this turns out.


...when I ignore the the primary and secondary reduction ratios the graph starts in first gear...

Can you include a screenshot of this too? Also, if this is your only problem, can't you just work out the total effective ratio for each gear (multiply each GR by primary / secondary reduction ratios) and enter data into only the Gears 1-4 fields. This allows you to leave the primary / secondary reduction fields blank, so the simulation will start in first gear for you?

PS - the image that isn't the attachment is better quality

[drive2win]

I'm curious to see how this turns out.



Can you include a screenshot of this too? Also, if this is your only problem, can't you just work out the total effective ratio for each gear (multiply each GR by primary / secondary reduction ratios) and enter data into only the Gears 1-4 fields. This allows you to leave the primary / secondary reduction fields blank, so the simulation will start in first gear for you?

PS - the image that isn't the attachment is better quality

Yea I could ignore the primary and secondary ratios but if the graph is only "right" when information is missing my thinking is that there is something else wrong, so I'm just trying to find the root cause of the problem.

Thanks for the help, the team and I are using Optimum lap for the first time so we are just trying to get it to work right so we fully understand the software.

478478

[exFSAE]

You should always be working on the basis that your hypothesis was wrong, before looking at your tools being wrong.

I dunno about that statement. Surprise: all your tools are wrong! Good George EP Box quote on that. Step 1 is to thoroughly vet your tools before you use them. Know what they're good at and what they're not good at.

Assume nothing. Still finding implementation errors in ADAMS/Tire and I'd wager that's got quite a few more man hours of engineers banging on it than Optimum(whatever).

[Tim.Wright]

I dunno about that statement. Surprise: all your tools are wrong! Good George EP Box quote on that. Step 1 is to thoroughly vet your tools before you use them. Know what they're good at and what they're not good at.

Assume nothing. Still finding implementation errors in ADAMS/Tire and I'd wager that's got quite a few more man hours of engineers banging on it than Optimum(whatever).

Oh boy don't even get me started on this one. This is absolutely true. Most vehicle dynamics applications have got serious problems in them somewhere. Some are straight out bugs, some are unreasonable simplifications in the models.

Just a few months ago I found that the current version of adams/car still contains a big bug in the calculation for anti-squat which I found in the 2003 version of the software. 12 years on, its still in there...

This is why, when I'm making a new handling model, I first calculate the all the handling curves using a bicycle model. Any significant differences you see at this stage are ALWAYS in the more complicated model.

[CWA]

I dunno about that statement. Surprise: all your tools are wrong! Good George EP Box quote on that. Step 1 is to thoroughly vet your tools before you use them. Know what they're good at and what they're not good at.

Yes we all know the Box quote, it's been mentioned in this thread enough for the point to be made. See the rest of my post that you quoted.

Perhaps there should be clarification over terminology here. The OP's initial post was trying to imply that there was a bug / error in the software causing the results he described. A bug / error in a software is different to the limitations a certain type of model has. Box saying 'all models are wrong' is him reminding you that a model has limitations as to what it can predict / represent.

The OP's initial post was trying to imply that the software has an error-state in it, where the software is doing something that the software designers probably didn't intend for it to do. In this case the OP is right, there seems to be some kind of bug that picks the wrong gear at the start of simulations based on certain inputs. This error is not the same as a result that doesn't tell you what you want to know / a result that does not reflect the real life trends you want it to due to the generic limitations of a point-mass model.

I had made the assumption that the OP had already been through 'Step 1' and decided that a point-mass simulation was appropriate in giving him a rough idea as to what gear ratio to use. Maybe I assumed this because I also believe that this type of simulation is enough for what he wants to achieve (optimise gear ratio), the OptimumG software captures enough of the dominant mechanisms that are needed to predict an FSAE car's performance with respect to this tuneable.

If I had said "Once you have chosen an appropriate tool, if your results don't match your hypothesis, you should always be working on the basis that your hypothesis was wrong, before looking at your tool being broken" would this seem more correct to you?

The point I was trying to make to the OP in my post was that the results (or more accurately, the lack of a 'delta' in the results) he presented as "wrong" could actually be quite valid for a certain combination of vehicle parameters (power and tyre friction) which he did not elaborate upon.

Back on topic, the thread has since moved on, and a bug (rather than a limitation) of the model has been found. I am still keen to find out how relevant this bug was, and would like to see what the new ~30T / ~50T simulation results are now that the gear selection bug has been spotted and can be avoided. I would like to know if this bug was actually the cause of the OP's "incorrect results"..

[TiJei]

As far as I remember the vehicle starts only in first gear in case oft an open loop simulation. On a closed loop curcuit the vehicle will cross the Start/finish line with maximum possible Speed limited by adjacent corners. It has to be mentioned, that even on an open loop curcuit the vehicle starts with lowest gear and lowest entered engine speed.

Anyway, this question might have been solved already.

Regards

[drive2win]

Yea, we realized that after the fact, thanks

[drive2win]

1. Due to the fact that the team has no actual dyno numbers, we knew that the information that optimum lap would give us was a little off, but we decide to try anyway.
2. Although we doubt that the software has a bug, we believe that there are errors in the inputs for information related to traction or gear ratio.
3. Just shear inexperience, as I said before it is the first time we used Optimum Lap, and we only have 1 running car for the last several years.

Couple all these issues with a lack of knowledge transfer from previous years equates to pretty much a first time team this year.

Solution:
So as a solution.... I have decided to create a simple oval and straight line track and create a set of gear ratios to run laps on. Once all the times have been recorded we will buy a few sprockets, lay out the track and try to achieve the laps times set by optimum lap and hand calculations.

Its not the most efficient way to go at a problem but it allows us to learn several things at the same, while also progressing towards the completion of the car.

Thanks alot for all the help guys, I learned alot through the discussions.