Hi Epic-o, great questions!
1- You're absolutely right. I don't know how I managed to misread that rule (maybe I thought it was "road, time trial, and track"?), but it's both embarrassing and disappointing given how much work has been sunk into the new version with those assumptions in mind. I think we'll be able to get close again in performance, but it's going to require much more creativity out of the design. I'm very glad you pointed it out though, because at least we're at a point in the design where we can still change things for this next iteration.
2- I'll let Stefano answer more there. We looked at a number of methods, and found this one the best in terms of cost and results. Our access to the nicer CNC machines we're using isn't what I'd call cheap though; it's a decent chunk of the total cost of our frame to get the shape accuracy we want.
3- We'd estimated our wattage (I use 22 mph, 25 mph, and then a higher 30-35 mph design point for aerodynamics, but am referring to the 22 mph speed for wattage comparisons because it's most limiting from the design perspective) by doing a basic drag build-up, similar to preliminary design methods you might see in aircraft design. It's pretty low-fidelity, assuming bike parts are more or less aerodynamically separate, but I believe the errors should come close enough to canceling each other that I feel comfortable estimating things to ± a few watts @ 22 mph or so. We account for some of the more highly interacting effects through some decent-fidelity CFD.
That comparison to the S5 is obviously gonna change as we rework things to fit the UCI rules I messed up, but I think we'll be alright. The comparison was done between the new S5 as specced (aero wheels + nice aero drop bar) against my spec with climbing wheels and noticeably slower aero drop bar, so we should have plenty of wiggle room to compete with the big boys despite my unbelievable misreading of the rules. We're using a full bike, outfitted as you'd ride it (bottles, drivetrain, etc.) but without rider for easier comparisons with existing bikes. We'd probably do better were a rider included, given our significant work on frame influence on rider drag, but including that makes it harder to compare apples-to-apples.
4- The CFD used was a finite-element research code. Since grid-count isn't a great way to compare finite element and the finite volume codes more common in industry I can tell you we used a similar number of degrees of freedom to industry models, which is overkill for the rider-less, drivetrain-less simulations we did. Since we used that fidelity only in limited cases to determine overall trends in performance, we just used an old but dependable SA turbulence model, rather than trying to deal with laminar-turbulent transition. I'm more comfortable tuning that model, so I think I get better results than with some fancier models that I don't have as much experience with. That l-t transition will matter more now that we have less aspect ratio in the tubes to work with, but I'm confident the code will handle it. The code we're using compares very favorably with industry standards - we can match or beat Star-CCM's accuracy for the problems of interest for bikes with the better part of an order of magnitude less compute time, for example. Not sure why bike companies use Star-CCM beyond ease of use; it's pretty awful at predicting separation without a bunch of tuning, which is a pretty massive flaw in a product where drag is based almost entirely on degree of separation.
5- I'm using XFOIL for initial airfoil design, mostly. MSES is useful for the blunt trailing edge stuff, but I find it less user-friendly simply because I've used it less. We've used 2D CFD for validation, but it's not often really necessary. We don't use optimization algorithms yet because our 2D methods are in many ways ill-posed problems for optimization (the optimizer will seek flaws in the code that are difficult to exclude from the problem statement without limiting the design space too much). We could use them with our 3D stuff, but that's currently too expensive without going to a level of accuracy I'm not sure I'd trust in the first place. We are definitely looking into this route for future iterations, though.
Regarding the interaction cascades - right now we're using my judgement from some previous projects informed by representative 3D CFD validation runs to design things in XFOIL. I want to play around with 2D CFD for this once V2's designed to see whether it's necessary to go 3D to really simulate this cascade well, or if we can get away with easier 2D stuff. The high degree of crossflow on most bike tubes made 2D seem tenuous to me, so we didn't bother upping the cost to CFD for now. We're likely giving up a bit of performance using this design method, but it's worked pretty well so far in real-world testing (see the pollen experiment/happy accident a few pages back for more) as far as separation prediction goes.
Custom aero carbon DIY
Moderators: MrCurrieinahurry, maxim809, Moderator Team
Check out these captures from a presentation on the development of the P5. I don't know how much tuning was involved to get such good results but in paper the k-omega SST model seems the perfect one for these low-Re separation-driven drag computations. If you can get this level of accuracy wwith STAR-CCM I don't see a reason for jumping to a higher order code other than computing efficiency.
Can you comment on the tuning procedure of the SA model? I suppose you adjust the model coefficients based on published data of airfoils for Reynolds number representative of bike conditions.
One last question, how have you had access to the MSES code? Did you ask Mark Drela himself for a copy or it is available in your university/research center?
Can you comment on the tuning procedure of the SA model? I suppose you adjust the model coefficients based on published data of airfoils for Reynolds number representative of bike conditions.
One last question, how have you had access to the MSES code? Did you ask Mark Drela himself for a copy or it is available in your university/research center?
- Attachments
-
-
Visit starbike.com Online Retailer for HighEnd cycling components
Great Prices ✓ Broad Selection ✓ Worldwide Delivery ✓
www.starbike.com
-
climbandpunishment
- Posts: 62
- Joined: Fri Mar 20, 2015 4:40 am
Computing efficiency has a great deal to do with it - more simulations for a given price means in theory better designs, and we're talking about a very significant difference in simulation cost.
The other key point to keep in mind is that a given level of error versus the wind tunnel doesn't really give you the whole picture - as you'd imagine, for the CFD to be a useful design tool you have to be able to replicate actual flow physics well, not just get a good average drag number. Star-CCM needs a heck of a lot of mesh points to successfully do that well in my experience, while a better adaptive code can resolve those features at a much more reasonable cost. Working on a project lately where Star-CCM was the only CFD option available, I was able to get better separation modeling out of panel codes with a simple separation model than out of Star's various turbulence models with a reasonable mesh, by an embarrassingly huge margin. You can see from that chart that Star didn't match wind tunnel trends well, which is a huge red flag in my mind. A blanket 2.2% error is awesome and can be accounted for in the design process; an error of 1% here and 10% there means I'm probably not adequately capturing the flow physics, and it's happening in a way I can't account for - and can't design well around.
Bottom line, I think Star does a great job of making CFD easy, but a less than great job of making it accurate. While that's not a balance I'd choose personally, there's certainly value to making simulations accessible, and maybe that makes more sense for companies with limited trained manpower.
I agree that SST is probably the best model out there at the moment for this problem, other than of course stepping up to full-on DES/LES/DNS type stuff. SA tuning parameters seem more physically based, which is more intuitive to me. The SA tuning I'd done was a by-product of some research I'd previously done for what luckily were appropriate conditions. We had wind tunnel data both of our own and some by others in different tunnels to go by.
The other key point to keep in mind is that a given level of error versus the wind tunnel doesn't really give you the whole picture - as you'd imagine, for the CFD to be a useful design tool you have to be able to replicate actual flow physics well, not just get a good average drag number. Star-CCM needs a heck of a lot of mesh points to successfully do that well in my experience, while a better adaptive code can resolve those features at a much more reasonable cost. Working on a project lately where Star-CCM was the only CFD option available, I was able to get better separation modeling out of panel codes with a simple separation model than out of Star's various turbulence models with a reasonable mesh, by an embarrassingly huge margin. You can see from that chart that Star didn't match wind tunnel trends well, which is a huge red flag in my mind. A blanket 2.2% error is awesome and can be accounted for in the design process; an error of 1% here and 10% there means I'm probably not adequately capturing the flow physics, and it's happening in a way I can't account for - and can't design well around.
Bottom line, I think Star does a great job of making CFD easy, but a less than great job of making it accurate. While that's not a balance I'd choose personally, there's certainly value to making simulations accessible, and maybe that makes more sense for companies with limited trained manpower.
I agree that SST is probably the best model out there at the moment for this problem, other than of course stepping up to full-on DES/LES/DNS type stuff. SA tuning parameters seem more physically based, which is more intuitive to me. The SA tuning I'd done was a by-product of some research I'd previously done for what luckily were appropriate conditions. We had wind tunnel data both of our own and some by others in different tunnels to go by.
Last edited by climbandpunishment on Thu Jul 23, 2015 6:24 am, edited 1 time in total.
Hey Epic-o,
Re: EPS molding-- our CNC time is a big part of our (admittedly small) budget at a local facility. Last version our manufacturing process was incompatible with eps (no heat) but we could potentially go with that at some point. In my previous experience with eps it can be difficult to achieve a good surface finish, there is usually not uniform compaction, and the residue left in the frame after dissolving it out is pretty gross. I think there is a reason most manufacturers use bladders.
Re: EPS molding-- our CNC time is a big part of our (admittedly small) budget at a local facility. Last version our manufacturing process was incompatible with eps (no heat) but we could potentially go with that at some point. In my previous experience with eps it can be difficult to achieve a good surface finish, there is usually not uniform compaction, and the residue left in the frame after dissolving it out is pretty gross. I think there is a reason most manufacturers use bladders.
Hi Stefano,
Just to clear things up, are you taking about using EPS molding without a bladder? From the limited information available online, this is the first time that I hear about this technique. For example, all the molding techniques employed by Felt make use of an internal or external bladder (http://velonews.competitor.com/2014/08/ ... kes_339460 pics 10 to 14).
Just to clear things up, are you taking about using EPS molding without a bladder? From the limited information available online, this is the first time that I hear about this technique. For example, all the molding techniques employed by Felt make use of an internal or external bladder (http://velonews.competitor.com/2014/08/ ... kes_339460 pics 10 to 14).
-
climbandpunishment
- Posts: 62
- Joined: Fri Mar 20, 2015 4:40 am
Thanks Mark! We've been enjoying it a lot ourselves too, though it's a lot of work. Can't wait to show you guys what we've got in store for version 2!
Epic-o, I'm also curious about where you're getting the 10-50 million cell in industry estimate from? Is that private knowledge, or resources you've been reading like that Cervelo presentation? Scientifically rigorous grid cell-count convergence studies are difficult on the very limited hardware I'm working with at the moment, so I'd really appreciate examples to compare to (if you can share and it's not private stuff from industry).
Epic-o, I'm also curious about where you're getting the 10-50 million cell in industry estimate from? Is that private knowledge, or resources you've been reading like that Cervelo presentation? Scientifically rigorous grid cell-count convergence studies are difficult on the very limited hardware I'm working with at the moment, so I'd really appreciate examples to compare to (if you can share and it's not private stuff from industry).
climbandpunishment wrote:Thanks Mark! We've been enjoying it a lot ourselves too, though it's a lot of work. Can't wait to show you guys what we've got in store for version 2!
Epic-o, I'm also curious about where you're getting the 10-50 million cell in industry estimate from? Is that private knowledge, or resources you've been reading like that Cervelo presentation? Scientifically rigorous grid cell-count convergence studies are difficult on the very limited hardware I'm working with at the moment, so I'd really appreciate examples to compare to (if you can share and it's not private stuff from industry).
Mostly resources freely available.
2016 Madone white paper reports 12 million volume for a bike in the tunnel simulation. The significant difference between the volume count of Trek's and Cervélo's simulations can be attributed to different reasons besides the presence of the rider (Cervélo's simulations models even the tiniest details (sprockets, FD bracket, etc) while Trek ones does not (take a look to the saddle in that white paper), the possibility to make the domain even smaller than the real tunnel for the bike-only simulation without negative blockage effects, etc.) The old paper by Hart on the development of UKSI olympic bikes and equipment and newer research papers (bike-only) also give values around the 10 million mark.
There are some (research) papers that give some notions about mesh convergence studies based on books on best practices and Richardson extrapolation, you won't find that info in white papers. I suppose that the first thing that manufacturers do before setting up their CFD methodology is to do that kind of studies. The fact that they focus on wind tunnel-CFD correlation simplifies things because they don't have to worry about BCs position and values sensitivity studies like in simulations that replicate real world conditions. They just have to "copy" wind tunnel ones.
Can you comment on the your number of volumes and typical simulation time? Workstation specs? Your more efficient CFD code could allow you to close the computing power gap with respect to the big boys.
-
climbandpunishment
- Posts: 62
- Joined: Fri Mar 20, 2015 4:40 am
Interesting, and thanks for those resources! I'll take a deeper look at those and see if I can learn something about how much computing power is really needed for bikes.
As I mentioned, our FEM CFD methods don't really translate well to cell counts - we used roughly the equivalent of 25 million cells worth of computing time for a 1st-order traditional finite volume mesh and solver. We'd been using an older Xeon workstation with only 8 cores, so as you might imagine the compute times were quite long (on the order of weeks, depending on the exact solution). Given our current resource limits, convergence studies of the scientific rigor I'd want weren't really a realistic option, even with Richardson extrapolation. I'm hoping we'll be able to move to a faster machine in the not-too-distant future.
At a first glance, 10-million odd cells for a reasonable level of detail on a bike seems small to me, but then I suppose if you're after an unsteady solution and you're not terribly concerned with accuracy that might be enough. I assume Trek did convergence studies, but I do wonder exactly what level of accuracy they decided to accept. I'd usually look at 50-100 million cells for an aircraft with even less separation, but then the Reynolds number is much higher there so it's hard to tell whether that's an accurate guesstimate.
As I mentioned, our FEM CFD methods don't really translate well to cell counts - we used roughly the equivalent of 25 million cells worth of computing time for a 1st-order traditional finite volume mesh and solver. We'd been using an older Xeon workstation with only 8 cores, so as you might imagine the compute times were quite long (on the order of weeks, depending on the exact solution). Given our current resource limits, convergence studies of the scientific rigor I'd want weren't really a realistic option, even with Richardson extrapolation. I'm hoping we'll be able to move to a faster machine in the not-too-distant future.
At a first glance, 10-million odd cells for a reasonable level of detail on a bike seems small to me, but then I suppose if you're after an unsteady solution and you're not terribly concerned with accuracy that might be enough. I assume Trek did convergence studies, but I do wonder exactly what level of accuracy they decided to accept. I'd usually look at 50-100 million cells for an aircraft with even less separation, but then the Reynolds number is much higher there so it's hard to tell whether that's an accurate guesstimate.
Hi guys,
Any updates? It was a very interesting project.
Any updates? It was a very interesting project.
Visit starbike.com Online Retailer for HighEnd cycling components
Great Prices ✓ Broad Selection ✓ Worldwide Delivery ✓
www.starbike.com
