[dennisat]

I've been on the track of a speed NaN occuring in the Stanlow-Haydock Fuel Oil activity of the NWE V3 route. This has been discussed at uktrainsim. When the speed goes to NaN, OR freezes. I've tracked it back to the calculation of Gravity Force in TrainCar.cs where the function WorldPosition.XNAMatrix.M32 is occasionally returning a NaN value for a particular car. The car is an invisible spacer "NWE_158 Spacer". This car has dimensions of 0.001m x 0.001m x 0.001m.

Has anybody any idea why the XNAMatrix function should return a bad value?
The OR Log is attached, the OR level is 3199.

Dennis

My Trap

        public virtual void Update(float elapsedClockSeconds)
        {
            // gravity force, M32 is up component of forward vector
            GravityForceN = MassKG * GravitationalAccelerationMpS2 * WorldPosition.XNAMatrix.M32;
            if (float.IsNaN(GravityForceN))
            {
                Trace.TraceInformation("Gravity Force is Not a Number: Train {0} Car {1}, XNA Elevation {2}", Train.Number, Train.Cars.IndexOf(this), WorldPosition.XNAMatrix.M32);
                throw new InvalidDataException("Gravity Force is Not a Number");
            }

            CurrentElevationPercent = 100f * WorldPosition.XNAMatrix.M32;

Attached File(s)

•  OpenRails_NaN.Log.txt (20.94K)
  Number of downloads: 178

[Coolhand101]

I had something very similar with Tim Courts Class 50 "exhaust helper" locos.

I was getting "other dimension physics" ( ie the whole consist was standing still but OR was reporting the consist was moving at real speed and distance, if detached, the engine would end up in the route where the track monitor displayed where the train should have been ) when this ENG file was in a consist.
The size was 0.1m 0.05m 0.005m, and the mass was 2 tons.

I couldn't fix it, but later found out it was not needed as OR allows more than two exhaust in an ENG file.

Thanks

[ianmacmillan]

The problem is with the coupling being longer than the size.

The r0 value is 20cm. the size is 0.001m
This means thast the coupling is pushing against the size limit causing juddering.
The speed of the wagon is constantly varying even when it appears still messing up the maths.

[James Ross]

 dennisat, on 18 July 2015 - 11:56 PM, said:

Has anybody any idea why the XNAMatrix function should return a bad value?

XNAMatrix is simply a storage for matrix data, it has no functionality itself. The value coming out was put in by some other code, but it can often be challenging to trace values backwards.

[dennisat]

I have now tracked down the particular circumstances. The spacer wagon is only 1mm in length. CalculatePositionOfCars in train.cs assumes bogie spacing of 0.65 of car length, in this case 0.00065m. At the point of the crash, for some reason, traveller direction is backward (longitudinal oscillation?) and we are at the start of a section - trackOffset is zero. Following the Traveller Move logic, the resultant location of the back of the car thus coincides with the front. Also, calculation of the Move stops when within 1mm of the target. XNAMatrixFromMSTSCoordinates therefore ends up with a zero divided by zero calculation and thus the invalid WorldPosition.

Should a test for the zero/zero divide be put into XNAMatrixFromMSTSCoordinates or should people not design cars (invisible or otherwise) with lengths as small as 1mm!!

Dennis

[James Ross]

Very well debugged Dennis!

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

Should a test for the zero/zero divide be put into XNAMatrixFromMSTSCoordinates or should people not design cars (invisible or otherwise) with lengths as small as 1mm!!

Ideally people should not be making cars that short, but we should probably try and cope since they have created them. ;)

The safest way to cope with NaN is normally to check for is after doing the calculation and reset the value to something sane, but I'm not sure if there is such a thing here. That said, if we return the identity matrix we might be fine... these 1mm-long cars don't have anything visible, right? So their rotation is irrelevant, hopefully.

[dennisat]

 James Ross, on 30 July 2015 - 12:53 PM, said:

The safest way to cope with NaN is normally to check for is after doing the calculation and reset the value to something sane, but I'm not sure if there is such a thing here. That said, if we return the identity matrix we might be fine... these 1mm-long cars don't have anything visible, right? So their rotation is irrelevant, hopefully.

I think that a sensible position needs to be set otherwise the car might transport back and forth from remote locations with undesirable consequences. I won't be able to look into this for a week because I'll be away from my PC and any reliable internet connection :lol2: . I'll raise the bug report when I get back - unless anyone else feels like following this up.

Dennis

[copperpen]

To put this into context, the invisible wag in question was inserted into the player consist to overcome a problem in MSTS. This problem does not exist in Open Rails, but the NAN problem these shorties cause is exasperating. Nearly all FRED devices fall into this category as well. Freds should really be added to a dedicated end of train vehicle as a freightanim instead which would remove that particular part of the problem.

Invisi wag or eng items are fine on their own as sound carriers or "blocker" vehicles but really should have no place in a consist in Open Rails as they are not needed.

[James Ross]

 dennisat, on 31 July 2015 - 08:51 AM, said:

I think that a sensible position needs to be set otherwise the car might transport back and forth from remote locations with undesirable consequences.

Position, sure, but not rotation. So I think inside XNAMatrixFromMSTSCoordinates we can (in the case of NaN) replace xnaTilt and xnaRotation with the identity matrix - the calculation for xnaLocation should be fine.

[dennisat]

I've tested a patch to XNAMatrixFromMSTSCoordinates() that detects the zero divide condition that causes XNAMatrix to have bad values. The patch is on the bug report Bug 1484205. Since I've forgotten practically everything I learnt about matrices 45 years ago, I'm prepared for some adverse comments!

Dennis