I was looking at a Mass Haul job this week (a 100km Rail Job) where the user was wanting to compute the job at 5m intervals to get the most accurate result possible - this was taking a long time to compute and we were looking at ways to optimize that.
At 20m intervals the job computed fine, however at 5 and 10m it would not compute at all - so I posed the question why do we need to compute at 5m intervals? The answer was that in order to pick up some areas of detail they felt that the only way to get those was to do the calcs at 5m centers.
Anyhow drilling into the question I found the following
The Mass Haul will generate stations for the calculations at the Intervals you define eg 5m or 10m or 20m etc. at the start and end of the job and anywhere that you place a Null template followed by a Copy or reference template. It does not however generate calculated stations where you place just a Reference, Copy or Normal Template, nor does it generate any of the extra stations that a Corridor Earthwork Report computes for all the critical points from HALs, VALs, Tables, Supers, or the new Define Extra Stations functions. This is basically why the end user was using 5m when for large areas of the job 20m stations would be just fine for the earthworks volumes.
So for now if say you drop in a Null Template at Station 100.000 and then a Reference Template at Station 100.002 you will create a short 2mm gap in the corridor, but by doing so you will create a calculation of Earthworks from 100.000 back to the prior station and from 100.002 to the next station interval location. You can use this approach where ever you need to pick up a specific set of quantities because there “is a lot going on”
To avoid this in the future we have now updated the Mass Haul engine for next release (v5.40 I guess) that will allow you to use the Define Extra Stations command to create the extra stations that you require for the calcs - eliminating the need for all the extra templates and allowing you to use a larger interval setting for the remainder of the corridor.
We are also taking a look at the calculations engine to see what we can do to speed that up, it appears that we had some inefficient processes in the calcs that we will try to address also.