Vivian Meazza wrote: > Andy Ross wrote: > >* For one, I still hate the boost function that goes negative at high > > RPM > > I have revised the curve: now a Hoerl power function. It's a good fit > over the rpm range up to x4 peak power rpm (unnecessary: x3 is too > much imho) and tails off thereafter reflecting less output as more of > the compressor stalls. The output remains positive for ALL values of > rpm, and won't break under any circumstances.
OK, check. This doesn't look bad at all. It's asymptote is zero, which still sounds wrong to me*, but as you point out it doesn't reach that regime until well beyond a meaningful operating range. * My wife, in graduate school, did work with very high vacuum gas phase chemistry. The first line of pumps attached to the vacuum chamber were "turbo pumps" which, as I understand it, were essentially very high speed fans designed to whack any stray molecules out of the chamber kinetically. This corresponds loosely to a compressor operating in a very high supersonic regime, where inter-molecule reactions are irrelevant -- there will still be some "boost" just due to the kinetic operation of the compressor rotation. Dunno, just intuition obviously. > >+ Explain better why you want the new CUTOUT control and didn't just > > make the wastegate setting modifiable at runtime (which simplifies > > the engine model and seems more general, IMHO). > > The Merlin (Hurricane, Spitfire and P51d) had a Boost Control which > acted on the throttle to control the boost pressure: I briefly > considered modelling that, but it is adequately modelled by the > wastegate in YASim. The CUTOUT control seems to me to be simple to > implement, reflects the way it worked in reality, and is applicable > to several models. OK, so the boost control was like a wastegate then: A spring-loaded pressure release value that opened up to keep the manifold pressure clamped to some fixed value? And it was analog-adjustible? The reason I ask is because the Mustang POH I have doesn't (I don't think) mention a control like this. What it did have is a lever to select which of the three supercharger states were active: no supercharging, first stage blower, or second stage blower. Literally, it was just linked to valves that opened up around each of the two gear-driven compressors. No analog control whatsoever -- just a warning not to engage each blower below/above certain altitudes and power settings . And it wouldn't have behaved like a turbo waste gate. The boost for a given stage is more or less solely a function of RPM and doesn't have the "clamping" behavior that the wastegate setting would show. My guess is that the "cutout" switch in the UK planes is just a different user interface for the same underlying ductwork, and that using a new control axis is not needed. Instead, how about using the existing BOOST input and setting its value to (for example) 0.0, 0.5 and 1.0 based on the position of the cutout lever and the blower stage lever (or whatever it's called in the Hurricane). I'm willing to be wrong on this; I certainly don't claim to be an expert on engines in general or the Merlin specifically. But even so, here's a software engineering justification for ejecting the CUTOUT control. The existing code tries really hard to be general, and useful for many aircraft. Adding a new control axis corresponding to every control idiom in every aircraft we want to model is going to get out of hand really quickly. Regardless of which one of us is correct above, the CUTOUT axis can already be implemented by using the existing engine code unchanged: the BOOST control is already there, and all that would be needed for the wastegate hack would be to make it configurable (i.e., the engine code doesn't change). This is preferable, IMHO, to mucking with the internals of the engine model. I know your change was a one-liner bit over override logic, but the problem is that the engine code already has a bunch of stuff like that, and it's already getting hard to follow. Your change might look simple right now, but add three more one-liners and it won't be quite so obvious which one has precedence and subtle bugs will get introduced; exactly this kind of thing happened with the gear ratio code. It literally took almost a year for that (conceptually simple!) change to stabilize and work its bugs out. The cleanest solution at this point, IMHO, would to split out the x-charger implementation and do it twice: once for gear-driven superchargers and again for exhaust-driven turbochargers. Andy _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d