Elvas Tower: Diesel Locomotive Performance - Elvas Tower

Jump to content

Posting Rules

All new threads will be started by members of the Open Rails team, Staff, and/or Admins. Existing threads started in other forums may get moved here when it makes sense to do so.

Once a thread is started any member may post replies to it.
  • 11 Pages +
  • 1
  • 2
  • 3
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

Diesel Locomotive Performance

#1 User is offline   steamer_ctn 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 1,145
  • Joined: 24-June 11
  • Gender:Male
  • Country:

Posted 24 August 2019 - 11:50 PM

As a result of a request I have reviewed some of the code for how a diesel locomotive performs, and have noticed some anomalies.

I am proposing to fix these.

The first one is as a result of the way that the code handles the specification of power levels in the locomotive.

Attached Image: diesel_efficiency.jpg

A diesel electric locomotive uses a diesel prime mover to generate electricity (using generators naturally) and this electricity is then used to drive traction motors to turn the wheels.

Thus we have a number of energy (and power) conversions. Each of these conversion will result in a small loss of power.

The above diagram (taken from a BR test report) describes the effect.

The "Output at Engine Shaft" describes the output power of the Diesel Engine (or Prime Mover). Typically most diesel locomotives are described by the Prime Mover power, for example 2000hp. As suggested there follows a number of power losses, such that the RailHP (Power to the Rail) is less then this value. For example a diesel might operate at 83% efficiency, so in our locomotive the RailHP will be 1660hp.

The OR parameter MaxPower should be set as the Power to Rail value.

If DieselPower and Traction curves are defined in the ENG file then the two power values seem to be correctly displayed in the HUD. However with a BASIC ENG file configuration where these values are not defined, the Prime Mover power and the Power to Rail value are the same.

To enable an appropriate difference to be displayed, and extra OR parameter will be added to specify the Prime Mover Power.

This and some other anomalies will be addressed as part of this blueprint.

#2 User is offline   steamer_ctn 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 1,145
  • Joined: 24-June 11
  • Gender:Male
  • Country:

Posted 25 August 2019 - 02:36 PM

A change as described above has now been added to the unstable version of OR.

This change will only impact a BASIC ENG file configuration (ie one that does not have DieselPowerTab curves and TractiveForceCurves defined in the ENG file).

In a BASIC ENG file configuration, the following two parameters will be required:

ORTSDieselEngineMaxPower ( 1491.4kW ) ==> sets the maximum power output at the shaft of the diesel engine (or prime mover)

MaxPower ( 1237.8kW ) ==> sets the maximum power at the rail.

Attached Image: hud_loco.jpg

The power figures in the red box should, at full throttle equal the ORTSDieselEngineMaxPower, and the power figure in the yellow box should not exceed the value defined by MaxPower parameter.

#3 User is offline   R H Steele 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,349
  • Joined: 14-March 13
  • Gender:Male
  • Location:known universe
  • Simulator:Open Rails
  • Country:

Posted 26 August 2019 - 08:27 PM

Peter, this looks fine, thank you, http://www.elvastower.com/forums/public/style_emoticons/default/hi.gif Hoping for comments from any interested ---- I'm almost finished with most recent work.... Deltic and test objectives, etc.
One item to note for clarification to users of the ORTS Specific Diesel Engine Definition (Manual Sec 8.2.1 ) the MaximalPower value refers to power at the shaft of the prime mover -- same as the new value "ORTSDieselEngineMaxPower" for the basic engine. ( = Gross Power ) and the OR UoM is watts. Other accepted UoM for power are kW and hp. Any UoM other than watts must be entered immediately after the value --- eg. 3000hp or 2237.1kW
The only question I have...and it's more of a semantic nature...would it be preferable to employ another term for power at the rail instead of MaxPower? Perhaps too close to MaximalPower? I'm not that familiar with accepted terminology....RailMaxPower, maybe??? It's not that important, just something that occurred to me.

#4 User is offline   steamer_ctn 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 1,145
  • Joined: 24-June 11
  • Gender:Male
  • Country:

Posted 26 August 2019 - 10:55 PM

View PostR H Steele, on 26 August 2019 - 08:27 PM, said:

this looks fine, thank you
Thanks for the feedback.

View PostR H Steele, on 26 August 2019 - 08:27 PM, said:

The only question I have...and it's more of a semantic nature...would it be preferable to employ another term for power at the rail instead of MaxPower? Perhaps too close to MaximalPower? I'm not that familiar with accepted terminology....RailMaxPower, maybe??? It's not that important, just something that occurred to me.

My personal perspective would be to have names that are a bit more prescriptive, and as far as I am concerned both of these names should have a better reference names.

The only drama is that both of these are now legacy names, so how would old files be treated if they are changed, especially MSTS files that would have the MaxPower parameter used widely throughout of them?

One possible way is to have two names that sets the same value. However even this might be a bit confusing.

#5 User is offline   Jean-Paul 

  • Fireman
  • Group: Status: Active Member
  • Posts: 105
  • Joined: 28-October 14
  • Gender:Male
  • Simulator:Open Rails
  • Country:

Posted 28 August 2019 - 12:32 AM

Hello !
It's an interesting idea, but naming this "new" parameter isn't simple. Moreover, it would be important to take in account Diesel locomotives having already an include file describing their "Engine" characteristics and complete "ORTSMaxTractiveForceCurves". In these files, raw Diesel power is named "MaximalPower", while there is no denomination for power at rail, which results of MaxTractiveForce curves, and which often varies with speed.
I think it may be seen as a "light" alternative to a full OR eng. file including MaxTractiveForce curves : less restrictive, but easier.
Jean-Paul

#6 User is offline   steamer_ctn 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 1,145
  • Joined: 24-June 11
  • Gender:Male
  • Country:

Posted 08 October 2019 - 02:57 AM

In an effort to give more clarity around how OR "thinks" that a diesel has been initialised in regard to the power and force inromation, I have added some code that displays the values in the logfile at start to show what OR will use to determine the performance of the locomotive.

The main reason that I decided to provide this feature is that parameters can sometimes be overwritten by others in the ENG file, for example power tables will overwrite force parameters such MaxForceN, etc. So it is important to understand how OR constructs your locomotive.

Diesel locomotives rely on a principle of constant power, ie the prime movers, traction motors, etc produce a constant output power. The force applied to the wheels varies as the speed increases.

Typically a diesel will have the following key design parameters which OR must duplicate to successfully ensure that the diesel performance matches the real world situation.

Diesel Prime Mover Output power and Rails Power - see first post in this thread for more detail.

The Rail Power is then used to calculate the tractive force (force applied to the wheels at different speeds).

Typically the following two design parameters specify the key force values required.

Starting Tractive Effort - force applied to the locomotive wheels when it starts.

Maximum Continuous Tractive Effort - a reference point at a particular speed which indicates the amount of force applied at this speed. To validate this value a reference speed needs to be present, hence a new ORTS parameter called "ORTSSpeedOfMaxContinuousForce ( 19.5mph )" is used as an input in the ENG file to give this reference.

As an example look at the Dash9 info on wikipedia (bottom RHS of page under tractive force). This shows the starting tractive force and the max continuous at the relevant reference speed.

The force/power checks will only be displayed in the log file, if the above ORTS parameter is included, so give the checks a go with your favorite locomotive that you have above reference info for.

These code changes are very much a work in progress, so subject to changes and modifications.

These changes are in the Unstable version only, and apply to versions after - U2019.10.08-1036.2019-10-08 10:36:09

#7 User is offline   edwardk 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 1,326
  • Joined: 11-December 09
  • Gender:Male
  • Location:Chula Vista, CA
  • Simulator:MSTS
  • Country:

Posted 12 November 2019 - 05:19 PM

Currently, maxPower() is suppose to represent the hp to the rail at 100% in OR. With the change, is maxPower() going to be used the same way it was used in MSTS?

#8 User is offline   Genma Saotome 

  • Owner and Admin
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Owner
  • Posts: 13,469
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 12 November 2019 - 09:40 PM

I'm ok with whatever names you want to use so long as everything is documented clearly and completely in the OR manual. By clear and complete I'm thinking (in the most general terms) something that has a clearly identified section for how all possible working solutions there have been, each having a list of parameter names to be use along with clear guidance on what parameters should not be present. And then for each new parameter something that addresses value conversion from anything previously used.

IOW an easy to understand and use migration path from methods A, B, C...J to K (the new way).

My concerns are two part: Not being able to locate real data to plug into the new methods which probably means translating old stuff I have in-hand to the new way, and second, not knowing what is safe to discard.

IMO a cluttered basket of incomprehensible parameter names in any given .eng or .wag is insanity defined.

#9 User is offline   edwardk 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 1,326
  • Joined: 11-December 09
  • Gender:Male
  • Location:Chula Vista, CA
  • Simulator:MSTS
  • Country:

Posted 13 November 2019 - 03:46 PM

Peter,

I remembered reading a post concerning lack of performance under Trainsim and sure enough there is. Running the earlier unstable versions before your change, the hp to the wheels would be around 4,280hp. Running the latest version after your change, the hp has dropped to 3,444hp. This is a big drop. Your response to the post under Trainsim was that there should not be a drop without the required changes. More information will be needed regarding the above change and if necessary, reversed.

Edit: The train that I was running above is SLI's Salad Express train with some of the ORTS changes such as the Bearing Type and the Davis entries.

Edit: Of course this depends how much the hp should be dropping. The above train is using the ES44AC. This is from Bob, "comment ( 4380HPx89%eff )"

#10 User is offline   ATW 

  • Engineer
  • Group: Status: Active Member
  • Posts: 537
  • Joined: 07-January 13
  • Gender:Male
  • Simulator:MSTS Open Rails
  • Country:

Posted 13 November 2019 - 05:14 PM

I notice recently that custom ORTS sub folder ENG files doesn't work very much anymore when it comes to testing. Custom ORTS parameters like tractive force curves, diesel section an controls do not perform in ORTS that old MSTS legacy parameters overrides ORTS sections.

Off topic maybe but think this happened before but the Traction_Braking Digital sections of cvf do not even show dynamic braking forces.

  • 11 Pages +
  • 1
  • 2
  • 3
  • Last »
  • 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