[Lindsayts]

In an effort to produce greater accuracy the openrails code widely uses the "Interpolator" function. This is in fact what one may call a super look up table. One inputs the function with a value say cylinder cuttoff and the output is the cylinders effective pressure ratio. The super part is if the input is between look up table values the result is interpolated.

Now these tables are under user control in the eng files by the "new Interpolator(stf)" function which should allow one to input a look up table and get an almost exact result of what one wishes, this being majorly good for those of us who are accuracy freaks.

Unfortunately there is no docs for this. As stated its quite widely used, there being three tables in the diesel code and around 5 or 6 in the steam code. Now I have had a look at the "new Interpolator(stf)" function and I ___THINK___ the resulting eng line should be something like this.........

forcefactor2 ( .200 .5 .265 .64 .33 .685 .395 .78 .46 .85 .525 .88 .590 .915 .655 .934 .72 .96 .785 .97 .85 .98 )

This is for the forcefactor1 table in the steam code. The line is in pairs of values, the first being the cuttoff the second being the cylinders effective pressure ratio. So .200 and .5 go together as does .265 and .64 and so one.
Only this does not work, the line is parsed without errors but the function output makes no sense.

As far as I can see due to there wide use in OR which is intended to be an accurate sim this function is in desperate need of decent documentation.

Please can this be done in the not to distant future.

I make a plea to the OR developers if one ever writes any function such as this ______PLEASE_______ document it while one can still remember how it works. In opensource this a VERY common reason for poor docs, ie the code writer can no longer remember how the code works. This is NOT as unfrequent and as silly as it sounds.

Lindsay

[Genma Saotome]

I certainly hope those literals in each table can be replaced by something read from the .eng file. Anyone one?

[copperpen]

Far as I am aware, the interpolator tables are not there for an end user to tune because the normal end user will never see them. They are part of the source code which is compiled for the end user. The only bits the end user has control over are the sections of the eng file used by the OR code.

As a for instance, the injector interpolator table output is derived from the injector sizes given in the eng file.

The reasoning behind not allowing interpolators to be modified is best answered by Peter, as is the reasoning for the limited amount of eng tuning the current code allows.

[Lindsayts]

copperpen, on 15 June 2014 - 01:12 AM, said:

Far as I am aware, the interpolator tables are not there for an end user to tune because the normal end user will never see them. They are part of the source code which is compiled for the end user. The only bits the end user has control over are the sections of the eng file used by the OR code.

As a for instance, the injector interpolator table output is derived from the injector sizes given in the eng file.

The reasoning behind not allowing interpolators to be modified is best answered by Peter, as is the reasoning for the limited amount of eng tuning the current code allows.

I apologise in advance if this post is to abrupt for some of the OR devs, the accuracy of the performance of rolling stock is something I am _____VERY______ passionate about. Its making me scream with frustration that OR has gone so far but is still not good enough. The steam code in my opinion is trying to be to accurate (its very complex) but not allowing the machines to be as variable as they really were.

The OR developers cannot assume they know anthing better than anyone else no matter how much research has been done. This particularly goes for any of the older technologys's, specialy steam powered machines which were ____VERY_____ variable. A good example of this is the power Chapelon managed to get out of the machines he MODIFIED. The modifactions done were all relatively minor changes, but he managed to extract between 30 and 50% greater power than before. Massive amounts of knowledge has been lost. The setup of the trainsim ____MUST_____ allow any user to be able to input the knowledge they have.

Second point most of the interpolators (I can name them if anyone wishes) have been setup to allow users to input data. Holding back docs to stop a user modifying anything is ____NOT_____ the way forward in an open source project. I would do such docs myself but I do not get along with C# (or in fact any programming language using objects).

A third point is OR needs to understand the clash between a config being difficult to set and being able to setup up a config accurately. I put this in because Peter has put in much effort to try and simplify the setup, the problem is at this stage its simply _____NOT______ flexible enough to cater for all variations.

OR is still being projected as an accurate train sim, the users ______MUST______ be able to set it up properly.

I do not know if I am doing any good here, particularly as any work in OR is taking time from my own sim I am working on :( (its quite different being simpler but with more flexibilty built in)(Note 1).

Note 1: Its simpler because I do not believe its required to model the actual machines workings as most operators simply do not have access to such data. Its just required to model the performance accurately, this is a far simpler task.

Lindsay

[copperpen]

The code as it now sits is reasonably accurate for generic output. Flexibility within the eng file is something I wanted to see, because it allows the user to tune the engine performance. There is some, but it is very limited in its capabilities. I will repeat, the interpolator tables are not in a place that is readily available to be used in the way you suggest. The current code is designed to use these tables in the place where they are currently located. Now, it is possible to amend the code to take the table data from an eng/config file instead, and revert to default if not present. Something for Peter to consider.

[Genma Saotome]

copperpen, on 15 June 2014 - 01:12 AM, said:

Far as I am aware, the interpolator tables are not there for an end user to tune because the normal end user will never see them.

It is fine for a default to exist as an aid to those users who are unable to find enough information to develop their own... and if the code as it is to be regarded as phase 1, well, that is fine too... Rome wasn't built in a day. But in all other regards I emphatically agree w/ Lindsay's comment (directly above).


FWIW have always held that the only literals that ought to be in any code are factors for converting units of measure and misc constants (temp at which fresh waters boils); EVERYTHING else should reside outside of the code in one data file or another, present as default values. WRT Open Rails, other files should be available for end users to provide their own substitutions (at their own risk and hopefully satisfaction). As an example, IMO it is perfectly reasonable to have a default set somewhere that holds the value of BTU's per unit if weight of coal... so long as there is some means for me to subsitute BTU's per unit of weight for bunker C Oil, Utah Bit Coal, Pennsylvania Bit Coal, Pennsylvania Anthracite, Illinois Bit Coal, etc. etc. etc. and point to those alternative values (that I have in-hand) as needed. I don't care about how the actual solution is done, only that the end user can have the final say in some reasonable way if he wants to.

[Lindsayts]

Genma Saotome, on 15 June 2014 - 12:24 PM, said:

FWIW have always held that the only literals that ought to be in any code are factors for converting units of measure and misc constants; EVERYTHING else should reside outside of the code in one data file or another, present as default values. WRT Open Rails, other files should be available for end users to provide their own substitutions (at their own risk and hopefully satisfaction).

Could not have put it better myself!

In my own sim all data including the formulas used are specifed in external text files. This was done to allow easy alteration without having to recompile anything.

Lindsay

[captain_bazza]

As a 'steamer fan', I concurr with Lindsay and Dave on this.

Cheers Bazza.

[copperpen]

I am not in disagreement, just pointing out the way it is currently set up. As for BTU values for fuel, this is adjustable by the end user within the eng file by using either of these entries,
ORTSFuelCalorific ( 13700btu/lb ) or ORTSFuelCalorific ( 33400kj/kg )

[Lindsayts]

copperpen, on 16 June 2014 - 11:57 AM, said:

I am not in disagreement, just pointing out the way it is currently set up. As for BTU values for fuel, this is adjustable by the end user within the eng file by using either of these entries,
ORTSFuelCalorific ( 13700btu/lb ) or ORTSFuelCalorific ( 33400kj/kg )

One thing I wish to make clear it is not my intention to even appear to be attacking anyone one on the development team but OR is being pushed in the end to be an accurate sim. As has already been said its good the code has defaults as it least it gives a chance to those with little knowledge to produce something that is at least reasonably driveable. But the steam code ___MUST___ be able to be tuned by those of us with a real passion for acccurate behavior.

Two items in particular need to be targeted, the cylinders effective pressure, whats called in engineering circles Brake Mean Effective Pressure (bmep). This is essentially a "goodness" factor for the cylinders and valve gear. This is catered for in the code by "ForceFactor1" and particularly "ForceFactor2" parameters

The second is pressure drop between the boiler and the cylinders. From Chaplelon's work it is clear this is where a lot of Tractive effort was lost. Chapelon being apparently the first railway engineer to think of testing things like gas flow. This is catered by the "CylinderPressureDropLBpStoPSI" parameter.
The three parameters mentioned are all "Interpolator"'s

All three these are in the code to parse the eng/wag file.

Now as stated I am no expert in C# by I think the items below are correct.

Code exerpt from MSTSSteamLocomtive.cs

line 667

        /// <summary>
        /// Parse the wag file parameters required for the simulator and viewer classes
        /// </summary>
        public override void Parse(string lowercasetoken, STFReader stf)
        {
            switch (lowercasetoken)
            {

A lot of parameters cutout for clarity.......

line 707

                case "engine(ortsforcefactor1": ForceFactor1Npcutoff = new Interpolator(stf); break;
                case "engine(ortsforcefactor2": ForceFactor2Npcutoff = new Interpolator(stf); break;
                case "engine(ortscylinderpressuredrop": CylinderPressureDropLBpStoPSI = new Interpolator(stf); break;
                case "engine(ortsbackpressure": BackPressureLBpStoPSI = new Interpolator(stf); break;

So all the effectvely needs done to be is to find out how the data for new Interpolator(stf) is arranged and prove that this function works. This is NOT part of the steam code but part of the stf (structured text file code, I assume).

I have had a study of this code as mentioned previously to try and figure it out but found it more obscure than is usual for C#.

The actual parsing of the text line is done in .........
I think anyway........

trunk/Source/RunActivity/Common/Interpolator.cs

starting line 57

        public Interpolator(STFReader stf)
        {
            List<float> list = new List<float>();
            stf.MustMatch("(");
            while (!stf.EndOfBlock())
                list.Add(stf.ReadFloat(STFReader.UNITS.Any, null));
            if (list.Count % 2 == 1)
                STFException.TraceWarning(stf, "Ignoring extra odd value in Interpolator list.");
            int n = list.Count/2;
            if (n < 2)
                STFException.TraceWarning(stf, "Interpolator must have at least two value pairs.");
            X = new float[n];
            Y = new float[n];
            Size = n;
            for (int i = 0; i < n; i++)
            {
                X[i] = list[2*i];
                Y[i] = list[2*i+1];
                if (i > 0 && X[i - 1] >= X[i])
                    STFException.TraceWarning(stf, "Interpolator x values must be increasing.");
            }
        }

This appears to have the data in pairs the whole line enclosed in braces eg

         ( x1 y1 x2 y2 x3 y3 etc in pairs )

I you separate the pairs by comas OR throws an error.


I do not believe this section of the code is rocket science (mind you it is ____ANOTHER_____ thing to do,ssssiiiiggghhhh).
Putting this section of the code through a debugger may prove interesting.

I have not been just sitting down wingeing :pleasantry:.
Lindsay

[copperpen]

There is an eng file parameter called ORTSCylinderEfficiencyRate ( x ) where x is currently a value between 0.6 and 1.2. I wanted this to be a range of 0.1 to 1.7 but Peter felt this was too wide a range. The description for this parameter is Multiplication factor for steam cylinder (force) output, these values working in conjunction with the force factor tables do give reasonably good results. If this parameter is not present a default is used.

[Lindsayts]

copperpen, on 16 June 2014 - 01:54 PM, said:

There is an eng file parameter called ORTSCylinderEfficiencyRate ( x ) where x is currently a value between 0.6 and 1.2. I wanted this to be a range of 0.1 to 1.7 but Peter felt this was too wide a range. The description for this parameter is Multiplication factor for steam cylinder (force) output, these values working in conjunction with the force factor tables do give reasonably good results. If this parameter is not present a default is used.

Yes, I saw this, I believe Peter is incorrect here, a reasonable range for the OR steam code at its present state would be 0.5 to 1.7.
To some extent the code is inconsistent here, why go to all the bother of trying to calculate pressure drops and cylinder effective pressures then throw in an overall factor. I personally would be quite happy just to have ORTSCylinderEfficiencyRate and forget about the rest. For most of the time steamers where produced they were almost always constructed by rules of thumb. As I have already said Chapelon appears to have been the first railway engineer to start looking at pressure drops and gas flows, he appears to have gone to great lengths to understand the limitations.

In the end for the code to work on pressure drops and such goes against the way steamers were designed for much of the time they were being used. The major problem with the code trying to be a true simulation of the machine is that there is almost no information about exactly what happens in the individual parts of a steamer. Even Chapelon most of time only giving overall performance figures. Only mentioning almost in passing the effects of passage sizes and problems caused by the valve gear.

Thinking on this, I personaly believe that ORTSCylinderEfficiencyRate should range from 0.5 to 1.7 this would give the range of control that would allow one to easily get the performance one required.

Note, as far as I am concerned OR is a train simulator its not really required to be an accurate engine physics simulator all it has to do is SIMULATE the locos real performance. Although I can easily see the attraction that a good steamer physics simulator can have. I already having done a couple of them myself.

A slight gotcha here is that I would not die of shock if some errors are still in a code base so complex as that that exists in MSTSSteamLocomtive.cs

Lindsay

[cjakeman]

Some good points being made here. Don't want you to think they are being ignored, but I've been busy with the new website and I know Peter has also been working hard on improving our documentation - which has also been a concern.

Lindsayts, on 16 June 2014 - 03:15 PM, said:

Note, as far as I am concerned OR is a train simulator its not really required to be an accurate engine physics simulator all it has to do is SIMULATE the locos real performance. Although I can easily see the attraction that a good steamer physics simulator can have.

Perhaps we could have a simple max power-speed curve definable in the ENG file. If present, this would bypass any modelling of the firebox, boiler and cylinders and would assume that the fireman can always deliver as much steam as is needed.

Is that what you mean?

[Genma Saotome]

I know what would help me: Having an Excel spreadsheet that mimics what OR is doing, where I could enter the parameter values from locomotives whose performance I understand and then examine & compare the results.

For instance, I have very good data on the WP 2-8-8-2 locomotives... I'd start there and eventually plug in data for a variety of other locomotives that I understand. If the results are fundamentally different from the expected I might be able to drill in and figure out why.

[Lindsayts]

cjakeman, on 24 June 2014 - 06:41 AM, said:

Some good points being made here. Don't want you to think they are being ignored, but I've been busy with the new website and I know Peter has also been working hard on improving our documentation - which has also been a concern.


Perhaps we could have a simple max power-speed curve definable in the ENG file. If present, this would bypass any modelling of the firebox, boiler and cylinders and would assume that the fireman can always deliver as much steam as is needed.

Is that what you mean?

Many thanks for the reply, I was not sure I had been heard but one must __ALWAYS__ remember OR is being developed by volunteers that do have other lives.

That would be ideal, but really we do not at this stage need anything even that complex. As stated all thats really needed is to have the parameter ORTSCylinderEfficiencyRate ( x ).capable of being varied ove a wider range 0.5 to around 1.7 would be reasonable.

As I have previously mentioned and this needs to be clearly understood steamers were ___VERY ___ variable machines even within the one class. Steam loco's were NEVER mass produced (Note 1) all machines being individually built so they were all a bit different. Beyer Peacock the builders of the Garrat locomotives at least in the early days (1920's) stamped all there parts with the locos class number, the stamp include the items position. For instance a coupling rod would be stamp G42 LR for the rod on the rear engine unit left side.
Old drivers will clearly state different locos in a class had differing personalities, this being one of steamers attractions.

Note 1: Some companies, two being the American Locomotive works and particularly Heisler Locomotive works did make some parts on jigs so they were interchangable, Heisler being the only company as far as I know that advertised you did not need a machine shop to own there loco's. All normal running parts being availible as off the shelf spares.

Lindsay