[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.

[James Ross]

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

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.

Thanks for doing some testing; if you could document everything you've found in this new thread (private forum for the moment) that'd be great. I'll stop hijacking this thread now - sorry 'bout that. :crazy:

[Lindsayts]

James Ross said...

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

Copperpen said,

"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."

I understand James's concern here, in my opinion though on this issue OR shot itself in the foot well before Steamerctn came on the scene. I have done a great deal of testing on MSTS's physics and while we do not know what KUJU was doing the model used appears to be __quite__ simple. The controls , reverser and throttle simply modifing the values given in the eng file.
When it comes to MSTS compatibilty the problem that OR has for version 1.0 is that the steamer code for a long time has gone __FAR__ beyond MSTS compatibilty. I have spent many many (many.... did I mention that) hours working out how the current steamer code works. Trying to get true compatibilty would need a significant step backwards, the current code even before the present modifications being far down the road to post OR v1.0.

Remember OR now is a true open source program all can work on what area they wish, although in the released version of the SVN code base its always possible to restrict experimental code, All people working on the sim need to have a at least some understanding of what all others are doing and also where the code is heading.

Note:I am no longer doing any work on the steam code in OR as I do not believe what is being done is the best way. My own code is a some what more complex version of how MSTS works, ie I am modifing the cylinders brakemean effective pressure, fuel and water consumption parameters etc with the controls to get loco performance rather than simulating the complete machine itself. The actual values for bmep, fuel and water consumption being taken from real life test reports.

Lindsay

[copperpen]

farrmp, on 14 October 2013 - 12:43 PM, said:

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

CTRL F will take you into the manual firing mode, control keys are listed at the bottom of the Keyboard window in the Options selection.

X1816 will now give working AI injectors.

[copperpen]

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

Thanks for doing some testing; if you could document everything you've found in this new thread (private forum for the moment) that'd be great. I'll stop hijacking this thread now - sorry 'bout that. :)

I do not have access to that one yet. As for hijacking, not a problem. :sign_welcome: You are after all lead developer on the project.

[copperpen]

Lindsayts, on 14 October 2013 - 01:12 PM, said:

Note:I am no longer doing any work on the steam code in OR as I do not believe what is being done is the best way. My own code is a some what more complex version of how MSTS works, ie I am modifing the cylinders brakemean effective pressure, fuel and water consumption parameters etc with the controls to get loco performance rather than simulating the complete machine itself. The actual values for bmep, fuel and water consumption being taken from real life test reports.

Lindsay

There are several different methods of achieving a working steam locomotive code and they all work. The problem with using data from real life test reports is interpolating them into the "real world" environment as something that works for everything. For me, simulating the complete cycle with the controls as modifiers on the output is more satisfying, because it means that whatever you do at one point has repercussions elsewhere. It is also quite easy to get something that works in manual mode, but quite another thing to get a properly working AI mode as KUJU found out. Admittedly far as I am aware their dev time was curtailed by M$ which contributed to the almost useless AI firing mode.