Numerical Analysis of Brake Rotors

[KeithYoung]

As some of you may know I am getting ready to start getting in the groove of working on my numerical code to simulate F1 type brake rotors. This is an initial post opening the topic. Eventually this thread will turn more technical, but first less technical things will have to be sorted out.

I want the series of posts to be as consistent as possible. In order to achieve this I'd like to know some things before I start writing.

What particulars interest you about F1 brakes?
How much interest do you have in the math behind it?
How much interest do you have in writing your own engineering code?
Are there good examples of similar writings that already exist?
What is a good format to use, since the idea seems so open ended? Many updates etc
Who here has good physical data on racing brakes used on LMP2 and up?
Would anyone be interested in working in parallel using commercial software?

Let me know what you guys think. I'd really like to have the direction and format nailed down before I start posting.

[olefud]

What aspect of brake rotors are you analyzing? I’ve been working empirically on heat rejection. This is essentially unfunded IR&D so much of the data is under confidential disclosure agreements with the people who paid for the brake dyno testing. However, if you are modeling heat rejection, I can provide qualitative input. Before you can model something, you need a sound theory. Perhaps this is an area for discussion.

In any event, I’ll be following your efforts.

[Lycoming]

Sounds potentially a bit more rigorous than the other stuff we're used to seeing around here. A good excercise, I think.

-My main interest in the brakes is about rotor design... notably use of slotting/cross drilling.
-A bit more math would be good, I think. I do too much of the stuff on a regular basis these days, but its good to give a better description and for modelling purposes.
-I'm very interested in the code, but only if its C, matlab or python :p.
-I know there are some good SAE papers on the topic, and Ive seen a code exapmle of brake temperature simulation.

Unfortunately I don't have much to say on the other points.

[KeithYoung]

olefud - This is mainly finding the temperature distribution of the brake rotors. Currently my code accounts for convection and radiative cooling. Once I know my code is good, I'd like to try common configurations of brake rotors, then try optimizing. Two peices of quantative info that you may be able to share are the maximum temperatures you've heard of brake rotors surviving, and a high but safe temperature. Particularly for carbon carbon brakes. Ballpark numbers are all I need. (So far I've only considered atmospheric reentry temperatures since part of my background is astrodynamics, similar materials are used in heat tiles as carbon brake rotors)

Lycoming - So far it is in Matlab. The code may change to Fortran. I have access to a quasi supercomputer at the university but my understanding is that Fortran will be highly preferred due to it's Linux base.

[Jersey Tom]

The code may change to Fortran.

Stick to MATLAB or Octave for future engineering familiarity and accessibility, and "dabbling" in a program here like this.

Though I'll admit at some point in my career I'll probably want to get some NumPy experience... focus on what has broad application.

[KeithYoung]

What's wrong with Fortran? I'm not a software/computer guy, so please educate me. The reason I'd see possibly doing it is Matlab is horrible when it comes to loops, and in order to have a small step size/large number of elements that greatly increases the number of loops required. Also, I don't think our "supercomputer" run Matlab code. Switching to Fortran would enable an immense jump in computing power due to the code and circumstances.

Plus I thought Fortran was free, isn't it? Matlab isn't free to most people here. Let alone if I use a command that happens to be in some special toolbox.

Let me know. Thanks!

[Greenish]

If you in fact need a highly parallel supercomputer to solve your problem sufficiently, then by all means don't let them scare you off of fortran... it is highly optimized for numerical computation, especially on those architectures. And for computationally minded folks (as opposed to the computer science minded) it's somewhat more straightforward than more general-purpose languages.

However - if you want to play with algorithms, sticking with relatively small problems (under a few hours computation on a fast workstation) then you're probably going to be much more agile if you can use matlab (or the free version, octave). You don't have to do as much bottom-up work and can focus on the problem at hand.

Then if you get all the pieces working and it's just going to be too slow to do some huge optimization problem with matlab, then you can port it to the big machine and parallelize it as you go, but at least you'll know the core parts work on their own and can focus on scaling at that point.
---
To bring this back to racing-related applications, I know lots of programs are capable of doing thermal/mechanical analysis of brake rotors. For example, I use CFdesign at work, and know it is capable of modeling this kind of thing to a point (i.e. you would have to give it a power dissipation number, but it could calculate the conductive, convective and radiative effects). If you want to get into the chemistry of the pads, or the structural parts, some kind of multiphysics software would probably be needed. Have you considered using an off-the-shelf (possibly open-source) program, and if it doesn't have its own optimizer, wrapping it in a script? I'm not sure how custom or into the weeds of the analysis you intend to go.

[Greenish]

Followup to the above, having just read your other post in another topic and glanced at your blog. Didn't realize you were an undergrad figuring this out as you go along - good for you!

I think you're on a great track keeping it simple and normalized to start with. You can always add scaling factors for units to compare it to real world. Your list of assumptions is good and by knocking them off one at a time you'll make something useful at each stage. Stick with 2D (or quasi-2D, i.e. R-theta with a thickness property) and steady state for sure until the rest is worked out.

And matlab is an excellent tool for this kind of work.

[KeithYoung]

If you in fact need a highly parallel supercomputer to solve your problem sufficiently, then by all means don't let them scare you off of fortran... it is highly optimized for numerical computation, especially on those architectures. And for computationally minded folks (as opposed to the computer science minded) it's somewhat more straightforward than more general-purpose languages.

However - if you want to play with algorithms, sticking with relatively small problems (under a few hours computation on a fast workstation) then you're probably going to be much more agile if you can use matlab (or the free version, octave). You don't have to do as much bottom-up work and can focus on the problem at hand.

Then if you get all the pieces working and it's just going to be too slow to do some huge optimization problem with matlab, then you can port it to the big machine and parallelize it as you go, but at least you'll know the core parts work on their own and can focus on scaling at that point.

Great advice. I'll stick with Matlab until I know it isn't cutting it. Plus by then I should have a little Fortran experience based on the funded research I'm doing.

---
To bring this back to racing-related applications, I know lots of programs are capable of doing thermal/mechanical analysis of brake rotors. For example, I use CFdesign at work, and know it is capable of modeling this kind of thing to a point (i.e. you would have to give it a power dissipation number, but it could calculate the conductive, convective and radiative effects). If you want to get into the chemistry of the pads, or the structural parts, some kind of multiphysics software would probably be needed. Have you considered using an off-the-shelf (possibly open-source) program, and if it doesn't have its own optimizer, wrapping it in a script? I'm not sure how custom or into the weeds of the analysis you intend to go.

We don't have any commercial CFD software access here afaik, just wind tunnels.

At the moment I don't have much interest in the chemistry of the pads, but the structural part I could write myself.

As far as using other software, the main purpose of this exercise is for me to learn numerical analysis (beyond the Newtop-Rapson etc we learned in class). So the only real use I'd have for open source software is if I can't find any real life data it could serve as another theoretical comparison.

I appreciate the help Greenish.

Another question for all of you. How clear are my previous articles? I've been just writing chronographically since there are plenty of textbooks out there that are straight dry writing. Will the writing for this series need to be clearer?

[Jersey Tom]

What's wrong with Fortran? I'm not a software/computer guy, so please educate me. The reason I'd see possibly doing it is Matlab is horrible when it comes to loops, and in order to have a small step size/large number of elements that greatly increases the number of loops required. Also, I don't think our "supercomputer" run Matlab code. Switching to Fortran would enable an immense jump in computing power due to the code and circumstances.

Plus I thought Fortran was free, isn't it? Matlab isn't free to most people here. Let alone if I use a command that happens to be in some special toolbox.

Let me know. Thanks!

A few things, before I run off to work-

1) MATLAB isn't horrible in loops. Wasn't great in some older versions but does some crafty JIT compiler acceleration in the past several releases. Plus, if you really want to go faster you can always fully compile the code.

2) If you're in school becoming an engineer - MATLAB is much more commonly used in industry for every day problems. In the past 5 years I haven't ran into a single instance of anyone having to know Fortran. MATLAB? Every day.

3) While MATLAB in general isn't cheap, it is for students. If you really want a free solution, you could use Octave and then still keep the same format.

4) You don't need a super computer to do heat transfer problems like this. When I took numerical methods in early 2005 we had some similar project to do and it ran just fine on my laptop - which I had bought in 2003!

Are there times when a particular program would be better suited to be written in C or whatever? Sure. But for something like this... stick with MATLAB. Get the experience in something you're bound to use as an engineer after college. Anything really intense is likely to be left to "for real" programmers with a functional spec written by an engineer.

[PlatinumZealot]

The code may change to Fortran.

Stick to MATLAB or Octave for future engineering familiarity and accessibility, and "dabbling" in a program here like this.

Though I'll admit at some point in my career I'll probably want to get some NumPy experience... focus on what has broad application.

Most engineering codes are based on FORTRAN programming language. I think you have that and NASTRAN and some others. But those two were the main engineering programming languages they told me about when I was in school.

[Jersey Tom]

Most engineering codes are based on FORTRAN programming language. I think you have that and NASTRAN and some others. But those two were the main engineering programming languages they told me about when I was in school.

Some years ago yes, FORTRAN was pretty standard in engineering work. Since then... in my experience you run into it with ancient legacy code or if you have a huge project where you really need computational horsepower.

I think really with higher level programming levels like MATLAB, you get the end result faster. Maybe the data runs just a touch slower but it's so much quicker to get the code written up and the data post processed. Really the way to go these days.

[KeithYoung]

Thanks for all the insight into the different language options. I've made up my mind to stick with Matlab. I doubt I'll make this so intensive it needs Fortran. The only stuff I know of here that specifically uses Fortran is the jet engine simulation code my professor has been writing for over 7 years. I don't forsee myself taking this beyond a quasi transient state, for example changes over timeframes smaller than it takes for several rotor revolutions probably won't be included.

[noname]

Are there good examples of similar writings that already exist?

You may want to check with manufacturers of aircraft brakes. High temperature composite brakes are well known to them, and I bet they developed quite a few proprietary tools over the years.

[riff_raff]

This project sounds quite ambitious indeed. While a steady state analysis would be reasonable, solving for transient conditions would be quite complex. I've seen some pretty sharp guys work at aero/structural coupled analyses using commercial codes, but it was no easy task.

As noname notes, the commercial aircraft brake suppliers like Goodrich or Messier-Bugatti have likely done lots of work in this area. But to be honest, the braking conditions for a typical commercial aircraft landing would outwardly seem to be less complex than those for an F1 car during a race. The aircraft braking event is fairly uniform, controlled, predictable and singular. The aircraft carbon brakes I've seen don't appear to be designed for rejecting heat. Instead, they look like they're designed with enough thermal mass to simply absorb the heat input. On the other hand, carbon racing brake rotors are designed to reject heat effectively.

riff-raff