Elvas Tower: Interploator function - Elvas Tower

Jump to content

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

Interploator function A question of documantation Rate Topic: -----

#1 User is offline   Lindsayts 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,849
  • Joined: 25-November 11
  • Gender:Male
  • Country:

Posted 14 June 2014 - 03:13 PM

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

#2 User is offline   Genma Saotome 

  • Owner Emeritus and Admin
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 15,359
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 14 June 2014 - 04:51 PM

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

#3 User is offline   copperpen 

  • Executive Vice President
  • Group: Status: Elite Member
  • Posts: 3,144
  • Joined: 08-August 05
  • Gender:Male
  • Simulator:MSTS & OR
  • Country:

Posted 15 June 2014 - 01:12 AM

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.

#4 User is offline   Lindsayts 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,849
  • Joined: 25-November 11
  • Gender:Male
  • Country:

Posted 15 June 2014 - 11:19 AM

 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

#5 User is offline   copperpen 

  • Executive Vice President
  • Group: Status: Elite Member
  • Posts: 3,144
  • Joined: 08-August 05
  • Gender:Male
  • Simulator:MSTS & OR
  • Country:

Posted 15 June 2014 - 12:18 PM

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.

#6 User is offline   Genma Saotome 

  • Owner Emeritus and Admin
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 15,359
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 15 June 2014 - 12:24 PM

 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.

#7 User is offline   Lindsayts 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,849
  • Joined: 25-November 11
  • Gender:Male
  • Country:

Posted 15 June 2014 - 12:34 PM

 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

#8 User is offline   captain_bazza 

  • Chairman, Board of Directors
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 13,927
  • Joined: 21-February 06
  • Gender:Male
  • Location:Way, way, way, South
  • Simulator:MSTS & OR
  • Country:

Posted 15 June 2014 - 01:55 PM

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

Cheers Bazza.

#9 User is offline   copperpen 

  • Executive Vice President
  • Group: Status: Elite Member
  • Posts: 3,144
  • Joined: 08-August 05
  • Gender:Male
  • Simulator:MSTS & OR
  • Country:

Posted 16 June 2014 - 11:57 AM

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 )

#10 User is offline   Lindsayts 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,849
  • Joined: 25-November 11
  • Gender:Male
  • Country:

Posted 16 June 2014 - 01:14 PM

 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

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users