Elvas Tower: Incorrect Default Values of MaxTractiveForceCurves - Elvas Tower

Jump to content

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

Incorrect Default Values of MaxTractiveForceCurves Rate Topic: -----

#1 User is offline   steamer_ctn 

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

Posted 18 July 2021 - 03:46 AM

Whilst discussing an issue in another thread a potential bug was identified (see posts#53 to posts#54).

To clarify, this is an issue that will only occur when a tractive force curve is inserted into an ENG which has dimensionless (no UoM assigned) values in the table. In brief the bug incorrectly reads the speed column values into OR when they are dimensionless.

To describe this bug more fully.

Firstly on pg 144 of the current manual it states, "The ORTSMaxTractiveForceCurves are formed by blocks of pairs of parameters representing speed in metres per second and tractive force in Newtons". In the code example above this statement it also shows dimensionless (ie no UoM) values, and thus I suspect most people have interpreted this to mean that the dimensionless values are in metres per second and Newtons.

Secondly when reading this table OR uses a special file reader that assumes that for dimensionless values the user has entered the table speed values in mph, and hence then internally multiplies it by 0.44704 to convert it to the internal standard of m/s. Hence all users who have used dimensionless values in the ENG file on the understanding (from the manual) that they were supposed to be in m/s have introduced an error into their setups. This error will result in a reduction in force at the desired speed.

To me the simple fix for this is to change the input of dimensionless values such that the assumption is that they have been entered as m/s values, as has been indicated in the manual for some time. I believe that everyone will have used these values when constructing the table with dimensionless values. I am unaware of any other reference to suggest a different dimensionless value for this table.

However it relies on the fact that any users who have been using dimensionless values were all thinking that the speed values were in m/s. If there are some users who have been thinking that the values were in mph or kmh then this may create a problem as we will have two different "legacy" approaches. Hence we will need to force a change on one set of users ENG files.

To be completely clear any tables created with an appropriate dimension (ie UoM) will still be interpreted correctly regardless of which file reader approach is adopted.

In addition, the ORTSDynamicBrakeForceCurves described on pg 126 of the same manual says, "The Dynamic brake force as a function of control setting and speed can be defined in a DynamicBrakeForceCurves table that works like the MaxTractiveForceCurves table". Hence this implies that the DynamicBrakeForce table suffers from the same issue, and would need to be changed in a similar fashion.


So to get a feel for any potential Issues.

Who thinks that they will be impacted by this proposed changed (ie they have used a dimensionless speed value other then in m/s for their table creation)?

If so, where did they get the information that the speed value should be something other then m/s if it has no UoM?

There are a number of MSTS legacy parameters that actually do have a dimensionless value in mph. For example, DynamicBrakesMinUsableSpeed (see MSTS reference documentation). At this stage it is not proposed to make any changes to these parameters.

#2 User is offline   Weter 

  • Member, Board of Directors
  • PipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 6,806
  • Joined: 01-June 20
  • Gender:Not Telling
  • Simulator:ORTS
  • Country:

Posted 18 July 2021 - 05:12 AM

If we will follow a logic:
1. the curves were introduced for ORTS, hence they have never been seen before>there were no other cases/formats of such tables, that are able to mess someone.
2. the manual (can't say about CTN site) tells, m/s and N are the primary UOMs, hence everyone, who believes in what manual suggests, did follow manual's instructions.
Personally me have noticed, that engine shows more poore performance, rather it was expected, since curves were defined.
Conclusion: the parsers were not adopted to new feature, but being intended earlier to understand right MSTS -inherited politic, based on USA-standard default UoM: gallons, pounds, inches, miles.
As a recommendation.
Doesn't it have sense to use SI UoM as default, since ORTS is positioned as an international project?
At least in case of ORTS-exclusive parameters.

#3 User is online   R H Steele 

  • Executive Vice President
  • PipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 3,404
  • Joined: 14-March 13
  • Gender:Male
  • Location:known universe
  • Simulator:Open Rails
  • Country:

Posted 18 July 2021 - 06:59 AM

View PostWeter, on 18 July 2021 - 05:12 AM, said:

...
As a recommendation.
Doesn't it have sense to use SI UoM as default, since ORTS is positioned as an international project?
At least in case of ORTS-exclusive parameters.

It certainly makes sense to me. The correct SI UoM for the ORTSMaxTractive Curve set would be m/s and N respectively. I do have a self interest, having constructed all my Std_End files with curve sets on that basis.


#4 User is offline   Laci1959 

  • Foreman Of Engines
  • Group: Status: Contributing Member
  • Posts: 910
  • Joined: 01-March 15
  • Gender:Male
  • Simulator:Alföld
  • Country:

Posted 18 July 2021 - 07:09 AM

View PostR H Steele, on 18 July 2021 - 06:59 AM, said:

It certainly makes sense to me. The correct SI UoM for the ORTSMaxTractive Curve set would be m/s and N respectively. I do have a self interest, having constructed all my Std_End files with curve sets on that basis.

The problem with this is that all official documentation uses km / h and kN.

Laci 1959
http://kepkezelo.com/images/ril385g7hjyvkqjpd5r8.png

#5 User is offline   Weter 

  • Member, Board of Directors
  • PipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 6,806
  • Joined: 01-June 20
  • Gender:Not Telling
  • Simulator:ORTS
  • Country:

Posted 18 July 2021 - 07:42 AM

Divide by 3.6 / add triple zeros. ;)
If you would a kind of harder way, try to specify km/h and kN there
If being talking serious, as long as you use excel tables, it not tolerates dimensions, but can automatically re-calculate x/3.6 and y*1000

#6 User is offline   DirtyRam 

  • Fireman
  • Group: Status: First Class
  • Posts: 108
  • Joined: 23-October 12
  • Gender:Male
  • Location:Northwest Lake Ontario
  • Simulator:OR
  • Country:

Posted 18 July 2021 - 08:55 AM

View PostR H Steele, on 18 July 2021 - 06:59 AM, said:

It certainly makes sense to me. The correct SI UoM for the ORTSMaxTractive Curve set would be m/s and N respectively. I do have a self interest, having constructed all my Std_End files with curve sets on that basis.


Good day, I concur with Gerry, as I use his efforts and mod them to my needs. I don't know metric having left grade 12 and going to work for CP in 1974 and CN in 1988. At this time Canada went metric. Canadian railroads didn't convert to metric to stay compatable with the US. So they should default as m/s and n for the international users as well as still being able to read other measurements. IE: mph/lbf, etc.
Thanks, Mike

#7 User is offline   Weter 

  • Member, Board of Directors
  • PipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 6,806
  • Joined: 01-June 20
  • Gender:Not Telling
  • Simulator:ORTS
  • Country:

Posted 18 July 2021 - 09:09 AM

Don't worry, it will accept all units as before. The subject of discussion here, is about which units of measure we may leave unspecified in configuration files.
The rest values are just have to be specified.

#8 User is offline   Laci1959 

  • Foreman Of Engines
  • Group: Status: Contributing Member
  • Posts: 910
  • Joined: 01-March 15
  • Gender:Male
  • Simulator:Alföld
  • Country:

Posted 18 July 2021 - 09:10 AM

View PostDirtyRam, on 18 July 2021 - 08:55 AM, said:

Good day, I concur with Gerry, as I use his efforts and mod them to my needs. I don't know metric having left grade 12 and going to work for CP in 1974 and CN in 1988. At this time Canada went metric. Canadian railroads didn't convert to metric to stay compatable with the US. So they should default as m/s and n for the international users as well as still being able to read other measurements. IE: mph/lbf, etc.
Thanks, Mike


Hello
I am sorry to say the opposite, but km / h and kN are used on Eastern European railways. Many Czech, Slovak and Hungarian locomotives use the ORTSTractionCharacteristics table where km / h and kN are given. 0 - 200 km / h in 2.5 km / h increments per line. We have an electric locomotive that has 36 gears. The 81 × 36 data that should be overwritten. I make such tables myself so I protect this value.

Sincerely, Laci 1959

#9 User is offline   Laci1959 

  • Foreman Of Engines
  • Group: Status: Contributing Member
  • Posts: 910
  • Joined: 01-March 15
  • Gender:Male
  • Simulator:Alföld
  • Country:

Posted 18 July 2021 - 09:39 AM

View PostWeter, on 18 July 2021 - 09:19 AM, said:

Western Europe too, Japan, whatever more...
But sorry, I don't see the problem here to regret.
Dear Laci, you only have to specify speeds with km/h and it will work correctly with same digits, or apply excel formula to recalculate at m/s. As you prefer.

In other words, program WILL ACCEPT our digits, but our task is telling to it, in which units they are measured.
For fair approach it was offered to consider SI units as default, and specify the rest.

Sorry if I misunderstood (google translates).
So if I give the units of measure (km / h, kN) then you can still interpret it.

#10 User is offline   Weter 

  • Member, Board of Directors
  • PipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 6,806
  • Joined: 01-June 20
  • Gender:Not Telling
  • Simulator:ORTS
  • Country:

Posted 18 July 2021 - 09:47 AM

Sure. See again post #9 above.
I added two links to your posts, that contain correctly specified data for tractive curves.
You wrote good code. It will work as defined without any problems.
Problem will be in that case, when someone didn't specify km/h - then program will read first digits of pair in miles per hour, or, if Peter will change parser's algorithm, in m/s

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