I could be wrong
Surely not ;-)
ababkin wrote:Furthermore, the units, scale or even linearity(to an extent) of the inputs doesn't matter much as long as the transformation/mapping is determined and calibrated experimentally (what we call 'tuning')
I disagree. The reason you want all your parts separate and as they actually are in real life is two-fold. Number one, you want to be able to conceptualise and adjust each parameter independently of the others. Number two, in order to produce a clean software solution you need the same modularity and clear defined boundaries of what each thing is and does. By far the most logical way to lay these out is to follow mother nature and do it as the physics really is.
Some parameters can be combined without harm, such as VE and AFR are on MS in most installations, however it would be very difficult to combine some others. Consider not splitting injector dead time out for example, how would you model that in software? How would you "tune" it in a VE table? You need separate control of that parameter for very well defined reasons.
Splitting the AFR OUT of the VE table is a very good move as it removes the guess work required when you change your mind about what sort of AFR you want at XxY load point. VE remains the same and only the AFR actually changes. VEMS does it this way and I believe it is the correct way to do it.
IMO, VE table, as it was popularized by MS, is a misnomer.
Absolutely, it doesn't reflect VE at all in most MS installations for a large variety of reasons.
[it] is fine to have all kinds of other factors 'embedded' into it, that affect the final behavior/tune, or even some fudge-factors to improve resolution/dynamic range.
As I mentioned above it entirely depends on which one that is exactly. If you try and blend the wrong ones in it will actually be totally impossible to ever reach a tune that always works. Others you can include with no consequences except those of conceptual understanding of what it is you are doing. However, that is a BIG loss IMO.
but IMO it may very well be a waste of cpu time, memory and will complicate the tuning process.
Allow me to fix that for you :
but IMO it may very well be a waste of cpu time, memory and will simplify the tuning process.
That depends on what you are trying to achieve. My goal is to create a physics realistic model with a clean implementation that is easy to comprehend and adjust. I believe segregating the code into real world physics is the best way to achieve both a clean implementation AND ease of use.
It's not like one could read the real VE values from the engine's manual and punch them into the VE table.
Maybe not, but after you are done it is nice to get a visual representation of how your head, cams manifolds and other plumbing flow at various RPM. A real VE table WILL give you that fairly accurately if the system is implemented and setup correctly. MS tables will not at the moment for various reasons.
So, IMO, value of having real VE values is zero.
And you are entitled to it :-)
Fred.