Questions about Torque Converter

Known problem: conflict with this mod

The torque converter characteristics in BeamNG is very depends on input RPM, the entire physics seems to be revolved around input, and although the input has large effect on the output(torque multiplier etc.) the reverse is not true.

According to the BeamNG Wiki, the torque converter is based on the "Capacity Factor" or "K-factor" model.

After digging into some lua "BeamNG.drive\lua\vehicle\powertrain\torqueConverter.lua" staff, I figured up the physical calculation, as shown.(ignore stability-related such as "kFactorSmoothing" or the torque "cap")

kFactorCoef = fluidDensity*converterDiameter^5, determined by jbeam, constant during gameplay.

kFactor = -0.004 * device.converterStiffness * (avRatio - 1) / (1 + device.converterStiffness * abs(avRatio - 1))
Although the kFactor is an f(avRatio), but the maximum and minimum value is always ±0.004, increasing the Stiffness will increase the responsiveness upon rpm differences, but the TC will "soften" eventually.

inputTorque = kFactor * kFactorCoef * inputAV * inputAV * fsign(inputAV)
Since kFactor is an f(avRatio) and avRatio = outputAV / inputAV, inputTorque is an f(inputAV,outputAV). However the max/min value of kFactor is 0.004, the maximum inputTorque is an f(inputAV), thus the input maximum torque does not depends on output RPM in any way!

outputTorque = inputTorque * min(max(stallTorqueRatio - (stallTorqueRatio - 1) * avRatio / couplingAVRatio, 1), stallTorqueRatio)
Since the stallTorqueRatio and couplingAVRatio are determined by jbeam, the maximum outputTorque is an f(inputAV) same as above.
Thus, the torque curves are as shown. The x axis is avRatio.

Note: I used GroGebra Classic to draw the curves, extract the ggb from the torqueconverterkf.zip and Open the file. Then you can adjust the sliders to change the shape of the curves(I changed the -0.004 to make multiple curves in the same picture).

The above is the physical modeling in BeamNG, but is that realistic?

According to the pictures in most real life torque converters, the modeling is realistic most of the time.

Some kFactors are inverted, just like MPG and l/100km.

Note how the kFactor drops very rapidly(and almost linear) at the "coupling phase" That's because the torque multiplication in the "stall" and "acceleration" phase due to the stator.

Explanations: Fluid coupling is powered by fluid momentum, not friction. The faster spinning impeller pushes the fluid outwards, then the fluid hits the turbine, transferring the momentum to the output. The slowed down fluid moves back inwards and to the impeller. In a fluid coupling w/o stator, the slowed fluid hits the fast-moving input blades, causing a significant amount of drag. In a torque converter, the stator redirects the flow in a way that moves along the impeller's spinning direction, effectively de-loading the engine. That's why the kFactor curve slope is shallower in the "stall" and most of the "acceleration" phase, also at a given size, the stall speed is higher in a torque converter than a fluid coupling.

Long story short, the torque multiplication is caused by the stator reducing the input load.

Realistic example: If you drive a slushbox (3AT/4AT w/o lock-up clutch), during the acceleration right after shifting to highest gear, you may feel that the input/output speed relationship is very "soft", the engine RPM stays almost constant during the acceleration, until the vehicle reaches sufficient speed. This is also true in BeamNG, just drive the Bluebuck with 3AT, use 50% throttle after shifting to 3rd gear, and watch the vehicle speed and engine RPM. This is realistically simulated.

Also note that none of the curves IRL displayed the characteristics where the avRatio is below zero or well above one.

This is because of two reasons:
1. These conditions are less common,
2. The "capacity factor" modeling is less realistic in these conditions.

First let's have a look at avRatio<0 condition. This is where the turbine spins backwards and becomes another impeller. The centrifugal force pushes the fluid in the turbine back to the impeller, causing huge drag, which might stop the engine. This condition is uncommon since automatic transmissions have solenoids that prevent the gear from shifting to D in reverse motion or R in forward motion. You may occasionally heard that some drivers tried to pull away in a steep slope, the car rolls backwards that stalled the engine. Fortunately, modern vehicles come with a one-way viscous clutch that prevent this(and possible engine/gearbox damage) from happening.

The least realistic condition of the "capacity factor" modeling is during engine braking, where the avRatio is well above one.

When the "avRatio" is above the "couplingAVRatio" the TC is in the coupling phase(the stator is freewheeling thanks to the one-way clutch), no matter the avRatio is at 0.95, 1.05 or 9.5. The problem is during engine braking, the negative torque is capped because the kFactor has a maximum negative value.

Modern fuel-injected vehicles have DFCO(deceleration fuel cut-off), which makes engine braking much effective. According to my driving experience, when coasting downhill from standstill in 1/L/M1 gear, the engine RPM never fails to rise above idle with speed increase. You can replicate this easily by stopping the vehicle at the entrance of a underground parking lot, shift to 1/M1, then release the brake.

However in BeamNG

The engine always at idle when starting from a standstill without using the throttle, even when the TC output(gearbox input) spins like crazy at 8000+RPM.
If you then tap the gas, the engine will rev up and the vehicle will decelerate very rapidly for a moment, before the engine explodes. This is actually worse after 0.17 update where the engine braking torque increased(before most cars like -30Nm-ish after 0.17 -65Nm-ish), but in the picture, the TC torque sent to the engines never reaches -60Nm

 

oh YES ! this has been bugging me for years

 

I didn't understood 3/4 of your post but it looks really interesting and at the moment that it criticize the torque converters in the game im happy.
I was so annoyed by all the strange behaviors of automatics transmission that I decided to tweak a few values of etk's diesel automatic transmission, I basically raise by ~20-30% the torque converter diameter and the stiffness (I wanted to make it as close as possible as the LR 8 speed automatic of a discovery 4 SDV6 that I could drive a few times to have a comparison point).

Here you can try it if you want, it's not perfect but still very satisfying and enjoyable to drive

 

Yes, they all seem very slippery and small, i had a thread about this but that was mainly criticizing the older automatics, It feels like im driving with a Dynoflow with 2 ratios instead of one. If i could get a small tachometer and take a video of my old classic being used, i would do so to show what the converter is doing in relationship to the speed/throttle position
--- Post updated ---
Sergeantfido's oldsfullsize mod and its TH350 feels about right (though converter is perhaps a dash to small?)

 

My iq is too low to be in this thread.

 

↓ ↓ ↓For current in-game solution, scroll further down↓ ↓ ↓

IRL dynamics

Viscous coupling: this is very simple. input torque = output torque, the higher speed differential, the higher the torque, when the diameter and the fluid viscosity is determined, no matter (input/output) is 5000/4500, 1000/500 or 250/-250, the torque is the same.

Fluid coupling: instead of viscosity, fluid couplings transfer torque via fluid momentum. The faster spinning impeller pushes the fluid outwards, then the fluid hits the turbine, transferring the momentum to the output. The slowed down fluid moves back inwards and to the impeller. The outward/inward is because of centrifugal force.
Centrifugal force = m*ω^2*r. Thus the inputAV^2 prevails, the higher the angular velocity, the stronger the coupling. The impeller blades are not completely symmetrical in order to reduce energy losses, inputAV^1.5*outputAV^0.5 maybe?

Torque converter: Already mentioned in the OP, the torque multiplication is because of the reduction of the input load(keep this in mind) via the stator.

The k-factor is in Nm/(rad/s^2), thus the inputTorque / (inputAV^2).
At stall, the output speed has very little impact on input load. At coupling, the TC feels like viscous X inputAV^2 factor(no input load reduction). The reason we don't use k-factor modeling in fluid coupling is because the k-factor function would be linear, i.e."y = ax + b".
That explained the "classic slushbox drives like CVT" feeling. With a constant throttle(not too high to kickdown), at stall the output has little influence on the input, constant engine RPM. At acceleration the output RPM increases, the speed differential decreases, but the "input load reduction" also decreases, they counterbalance each other, the engine RPM increases very slowly. At coupling the the engine RPM increases with vehicle speed, that's the upshift point. The tuning of a slushbox is effectively balancing engine loss and TC loss. Shift too late, higher engine loss. Shift too early, higher TC loss.

Thus, in terms of the use of torque converter instead of fluid coupling in vehicles. Torque multiplication is only one of the reasons. Another very important reason is to use a larger diameter to provide a stronger coupling(high efficiency), without overloading the engine at low output RPM.
If the stator fails, the k-factor will be very high at stall, making low speed handling very sluggish. On the other hand, when avRatio>1, the stator always "fail", thus the converter shouldn't "soften" at all.

The "softness" and the stall ratio is in according to the shape of the stator blades. If the stator blades are curvy, the stall torque is higher but the couplingAVRatio is lower.


About the physics modeling

Please compare the picture above and the picture below.
NOTE: the kFactor in the lua is not the kFactor IRL, the realistic kFactor is kFactor*kFactorCoef

Thus, in order to make a realistic torque converter in BeamNG.drive, you need to adjust the "converterStiffness" to control the "softness" when stalled, and adjust the "converterDiameter" AND "converterStiffness" to control the coupling slope aka converterDiameterIRL. Adjust the "stallTorqueRatio" and "couplingAVRatio" back and forth to control the stall highness. Then you can get a torque converter that is realistic at 0<AVRatio<1.

The "runaway effect" is indeed the most peculiar, and no, the kfactor doesn't grow with inputAV, the input torque catch is because of inputAV increases. And since the "couplingAVRatio" is always <1, when AVRatio>1, the TC should always fluid coupling, the AV^2 still in effect(maybe inputAV*outputAV), please read the above explanation about the difference between viscous coupling and fluid copuling.

Engine braking is not allowed on many two-stroke engines, but two-strokes are mostly used on motorcycles(sequential instead of AT with a TC).
The one way clutch might be useful in save fuel(oil crisis?) on carburated vehicles where at high RPM, engine brake torque is also higher BUT the idle fuel consumption is higher instead of lower. With Engine braking reserved to save brakes when coasting downhill, hence the use of "L" gear. They are not that common because of the complexity, in order to reduce "jolt" upon downshifts, simply tune the transmission to downshift at idle speed at or below 2nd gear. Either way, the inputTorque shouldn't be -33-ishNm(0 when coasting w/ one-way clutch, -63~ishNm with proper engine braking)

↓ ↓ ↓Possible In-Game Solution↓ ↓ ↓

Fix the inputAV "catch"
Use inputAV * max(inputAV,outputAV1), instead of inputAV^2. Push start a vehicle with AT is still (realistically)impossible.

Code:

inputTorque = min(max(kFactor * device.kFactorCoef * inputAV * max(inputAV,outputAV1) * fsign(inputAV), -device.converterTorque), device.converterTorque)

Fix the kFactor "soften" at avRatio>>1
Use the y = a * x - a to make the coupling slope then use the max function to override previous kFactor approximation at avRatio>1, then use the min function to "cap" the kFactor to prevent instability when avRatio is very high (engine off, inputAV=0), before finalize the calculation with -0.004.

Code:

kFactor = device.kFactorSmoother:get(-0.004 * min(max(device.converterStiffness * (avRatio - 1) / (1 + device.converterStiffness * abs(avRatio - 1)),device.converterStiffness * avRatio - device.converterStiffness),device.converterStiffness))

The adjusted lua is in the attachment, to test it, put in "Documents\BeamNG.drive\lua\vehicle\powertrain\" folder.
And then

For plug and play, just put the packed mod into mods folder

 

Oh my god, you've done it, you explained the problem, and you even bloody well fixed it too, you sir are a true legend. Thank you, i couldn't drive with normal beam converters now that you have fixed the problem, i just hope the next update doesn't kill it all

 

Awesome job, automatic transmissions feels way better with your version, some problems still didn't got resolved but it wasn't the thing you tried to solve so that doesn't matter . Keep up the good work, everything you do is always mindblowing and you really contribute positively to the game

 

inb4 this gets a staff pick

 

This post is going THROUGH the roof ! I told you months ago you are a very smart person (pm) and I knew I was right

 

Aha, I somehow managed to find this.

It appears that my guess "the torque multiplication is because of the reduction of the input load(keep this in mind) via the stator" is right, mostly.

As shown, the "freewheel" only happens in 1st & 2nd gear AND when Drive(D gear) is selected. Maybe @NOCARGO can implement this since they did the freewheel in CrashHard Classic.