Elvas Tower: What is this NaN? - Elvas Tower

Jump to content

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

What is this NaN? Rate Topic: -----

#11 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 7,022
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 09 July 2015 - 11:44 AM

OK, I was able to reproduce it with the Acela and accelerating very much the time.
The problems seems to occur when Advanced Adhesion has been selected, and what is NaN is WheelSpeedMpS. This value is derived in Axle.cs through an integral, so it is clear that once the value is NaN, through integration it will remain NaN forever. So a first solution could be to check if the integral is NaN and in this case reset the integral. This cures the effects and not the causes, but it could be better than nothing. By the way in the integrating formula I see many composing parameters having NaN value, that is slipDerivationMpSS, SlipSpeedMpS, AxleForceN.
Opinions on my cure are welcome.

P.S. After further tests, I found that the initiator is AdhesionConditions, as computed in line 1233 of MSTSLocomotive.cs. It goes to the -1.70527178E+38 and to Infinity, which in turn causes a NaN in the computation of axleForceN in line 596 (or nearby, as I have added test lines) of Axle.cs. I will try to limit the excursion of AdhesionConditions. Maybe it is caused by high values of elapsedClockSeconds.

#12 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 7,022
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 10 July 2015 - 09:30 AM

After having performed some tests, I think that the AdhesionConditions filter does not perform well when elapsedTime is high, which may happen with very accelerated clock.
As in this case max and min values for AdhesionConditions are known, I have inserted a clamp, so that adhesion factor can't go below 0.05 and can't rise above 2.5. This way this type of NaN seems to be disappeared. If there are no objections by experts in train physics, I'll commit the patch.

#13 User is online   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,492
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 10 July 2015 - 11:04 AM

The long-planned and "correct" fix for these kinds of problems is a fixed time-step (or a very small variance time-step) simulation phase, but I don't think this is achievable yet as we've got too many things tied together in the same update code path, and it is simply not nearly fast enough as a result.

 Csantucci, on 10 July 2015 - 09:30 AM, said:

As in this case max and min values for AdhesionConditions are known, I have inserted a clamp, so that adhesion factor can't go below 0.05 and can't rise above 2.5. This way this type of NaN seems to be disappeared. If there are no objections by experts in train physics, I'll commit the patch.

If those are the right limits, it seems alright to do for now. Make sure that the infinity values are caught, as I'm not sure they obay the > and < operators.

#14 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 7,022
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 15 July 2015 - 08:16 AM

First fix in x.3196. Maybe this won't solve all NaN cases. Time will show that.
  • 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