[steamer_ctn]

The code for the steam locomotive model is currently having some work done on it (see release 1815) .

New Features

Some of the new features include:

i) Water usage
ii) Coal usage
iii) working injectors
iv) some formula modifications
v) Crude Superheating added
vi) Extended Shft-F5 HUD visibility of parameters

Steam Locomotive Definition

Firstly some background information, based on info gleaned from research material.

A steam locomotive's performance can be described by the following basic parameters (extremely over simplified description):

i) Fire Grate Area - along with the draft, and fuel heat value, determines the maximum heat released from burning the fuel.
ii) Boiler Evaporation Area - will determine the amount of heat transferred to generate steam within the boiler
iii) Cylinder Data - the size and stroke of the cylinders will determine the force that the locomotive can develop.

Heat losses will occur as you move through the above cycle.

Important ENG File Parameters

The core version of OR added the following new parameters to the ENG file.

EvaporationArea ( "2198*(ft^2)"  )
FuelCalorific ( 13700btu/lb )

As part of this most recent development the following parameter has been added to the ENG file.

  GrateArea ( "29.75*(ft^2)"  )

The following existing parameters also play an important part in the model being developed

WheelRadius 	( 0.648m )
NumCylinders 		( 2 )
CylinderStroke    		( 26in  )
CylinderDiameter  		( 21in )
SteamFiremanMaxPossibleFiringRate( 4200lb/h )
MaxTenderCoalMass ( 13440lb )
MaxWaterMass ( 3977lb )
SuperHeater ( 1.0 )

Note: This is not meant to be an exhaustive list of all the OR used parameters, just the ones currently involved in the redevelopment.

Special Notes -

SteamFiremanMaxPossibleFiringRate - typical sustainable values for this parameter - 3300 UK - 4200 Aust - 5000 USA
SuperHeater - set = 1 if saturated, set to value > 1if superheated

Model Usage

One of the aims of this code development is to try and simplify input parameters used in the ENG file, and use only well defined and readily available information.

Whilst "default" MSTS ENG files should run ok in the new model, it is suggested that for optimal performance the above parameters be researched and added or modified within the ENG file.

Thus most of the above information can be found at sites like the following.

Steam Locomotive Data

Merchant Navy Data

Driving

Currently when OR first starts, the steam locomotive starts in a "cold" state, ie low FlueTemp. As the locomotive moves off, provided the heat into the boiler is greater then the boiler losses, the FlueTemp should increase. Maximum steam generation will occur when the FlueTemp is high.

Testing

To ensure consistent test result that are only impacted by the actual locomotive parameters, it is suggested that a common test track be used.

The following test track has been developed to allow steam locomotives to be run and tested to asses their performance characteristics. The track has a number of sections of track pitched on different "common" gradients.

Test Track

This code development firmly sits within a "work in progress" category.

Cheers

Peter

[Genma Saotome]

If we're going down this path may I suggest something along the following example to calculating surface area?

SurfaceArea
	MinimalDefaultSurfaceArea (
		TotalArea()
	)
	RobustAlternativeSurfaceArea (
		GrateArea()
		FireboxArea()
		FlueArea()
		SuperheatArea()
	)
)

where the use of Minimal is all that is required but may be replaced by Robust data. It might not make any difference to performance in-game as the sum of Robust() should equal Minimal() but it does convey to all users something about the level of research/quality of information behind the numbers, especially when developer and end user have data in-hand that is at variance.

I would also suggest the addition of a non-functional parameter to go along with FuelCalorific()... something like FuelName() as that will explain something of the choice made for FuelCalorific()... values like "Lignite", "Bituminous, Utah", "Bituminous, Illinois", etc. Again, to convey to users the working assumptions used by the creator that can be quite helpful to the end user in adjusting the locomotive to specific routes.


WRT initial temperature of the flues... "cool" is fine for a default -- it assumes we're starting at a terminal -- but OR really should provide for a replacement value to be coming from the Activity files as the actual start of the Activity can be well along a run. Ditto for actual fuel & water levels. It might not be possible to add it now but IMO it should be anticipated.

[Genma Saotome]

Something else... a professional pet peeve: We should not define a parameter with multiple datum (e.g., value plus units of measure). IMO it would be far better to define stuff like this:

SurfaceAreaSqFt()
SurfaceAreaSqM()

where the use of one but not both is expected,

than to do this:
SurfaceArea(value, unit of measure) -- two different datum.

[James Ross]

steamer_ctn, on 14 October 2013 - 03:19 AM, said:

The core version of OR added the following new parameters to the ENG file.

Since when were we allowed to extend the MSTS file formats in this way?

[copperpen]

James Ross, on 14 October 2013 - 10:25 AM, said:

Since when were we allowed to extend the MSTS file formats in this way?

I do not think it is a case of extending MSTS file formats. If these are not present in an eng file the code will calculate a figure for those new parameters. The big problem we have in looking at getting steam engines to work is that it is not possible to see how KUJU developed the code which does in fact have it faults. I thought that the objective of OR v1 was to provide the same as MSTS, which is an impossibility for steam locomotives if you do not have access to the original code.

If you go look at the file loadstr.hdr located in the MSTS Utils./FFEDIT folder you will see a long list of things that KUJU were going to implement mixed in with those that did make it. Some have tried to add them to the eng file but with no idea of what they are supposed to be doing it becomes a guessing game.

By adding those three extra file parameters it becomes possible to get a working steam locomotive. If the end user has the relevant data for those parameters he/she can add them. If not the code will calculate them.

[copperpen]

Genma Saotome, on 14 October 2013 - 08:47 AM, said:

Something else... a professional pet peeve: We should not define a parameter with multiple datum (e.g., value plus units of measure). IMO it would be far better to define stuff like this:

SurfaceAreaSqFt()
SurfaceAreaSqM()

where the use of one but not both is expected,

than to do this:
SurfaceArea(value, unit of measure) -- two different datum.

Please remember that this is a WIP and probably has other areas that can be tidied up as well. That said, all suggestions are welcome and will be considered.

[James Ross]

copperpen, on 14 October 2013 - 12:12 PM, said:

By adding those three extra file parameters it becomes possible to get a working steam locomotive. If the end user has the relevant data for those parameters he/she can add them. If not the code will calculate them.

I understand why they have been added for Open Rails, but I don't remember any change in policy that would allow such things to be done (yet). Do you happen to know what MSTS does when it loads an engine with these three extra parameters?

[Genma Saotome]

FWIW I fully agree w/ James' concerns... we've been over that ground many times.

That said, I've been a long time proponent of adding things to MSTS files after the closing parenthesis where, AFAIK, MSTS software never goes. Being able to do this:

SIMISA....

MSTS FirstParenthesisOfAnyFile (
	blah()
	blah()
)


OpenRails {
	new()
	new()
)

Opens up the ability to add all sorts of features. It will work w/ MSTS. And it might completely screw up 3rd party tools.

Of course there are alternatives... the ever present (1) Do Nothing and (2) Create a new file and read both old and new. As James has noted there has not been a team decision to move away from Do Nothing (tho I seem to recall Matej saying something was added to .eng files). IMO it would be wise that any change from that policy be a team decision.

[farrmp]

Just a comment. I downloaded x1815 yesterday and am VERY pleased with the progress on steam locomotive physics with this WIP!.
I have run 4 different locomotives on the 3DTS Donner Pass route the performance of these engines 'Just Feels Right'.
( These are 3 recent steamer's by midneguy and the 3DTS Consolidation) Any tips on how to get some feedwater into the boiler?
Thanks for all the time and effort that goes into writing the code to simulate something this complex. You're on the right Track - Pun Intended!

Paul

[copperpen]

James Ross, on 14 October 2013 - 12:18 PM, said:

I understand why they have been added for Open Rails, but I don't remember any change in policy that would allow such things to be done (yet). Do you happen to know what MSTS does when it loads an engine with these three extra parameters?

To give you a proper answer I went off and ran a short test with a modified steam locomotive. In the same folder I have some diesel locomotives that also have some OR specific parameters in them. MSTS does not like the diesels but accepted the steam engine without a problem.