Bug 1059

Summary: Unable to load trace files created from SUMO and TraNS Lite
Product: ns-3 Reporter: Konstantinos Katsaros <dinos.katsaros>
Component: mobility modelsAssignee: Pavel Boyko <boyko>
Status: RESOLVED FIXED    
Severity: normal CC: andreev, jpelkey, ns-bugs
Priority: P5    
Version: ns-3.10   
Hardware: PC   
OS: Linux   

Description Konstantinos Katsaros 2011-02-21 14:34:47 UTC
I have a problem loading a mobility trace file generated from SUMO and TraNS-Lite. (but it works with trace files from Bonnmotion)

The two trace files look the same (as in syntax) but I get errors like this:
Line has not correct number of parameters (corrupted file?): $ns_ at 83.0
"$node_(21) setdest 495.05 948.64 9.95"

This error comes out for EVERY line of the file (mobility.tcl) when I use the Ns2MobilityHelper to load it, but not when I use a trace file from bonnmotion.

part of the mobilty.tcl (trace file from TraNS).
$node_(437)   set X_ 1004.9500122070312
$node_(437)   set Y_ 0.0
$node_(437)   set Z_ 0.0
$ns_ at 99.0 "$node_(361) setdest 495.05 2205.41 19.92"

Part from BonnMotion trace file. 
$node_(0) set X_ 243.38879593726568
$node_(0) set Y_ 1010.0
$ns_ at 0.0 "$node_(0) setdest 257.265606417154 1010.0 10.303363538002284"

In general they look the same. Bonnmotion does not initialize the Z-axis which for TraNS is always zero.

I looked inside the Ns2MobilityHelper which has the valid ns2 statements which are the same as those I have:
* Valid trace files use the following ns2 statements:
    $node set X_ x1
    $node set Y_ y1
    $node set Z_ z1
    $ns at $time $node setdest x2 y2 speed
    $ns at $time $node set X_ x1
    $ns at $time $node set Y_ Y1
    $ns at $time $node set Z_ Z1

I'm testing it with simple-wifi-adhoc-grid.cc but instead of building a grid, I use the trace files. If you need more information please ask.
Comment 1 Kirill Andreev 2011-12-12 07:24:40 UTC
Hi!

Could you, please, send some the whole mobility example which can not be loaded correctly?
I can find no errors in your examples:(
Comment 2 Kirill Andreev 2011-12-14 08:04:47 UTC
I think I have solved this problem:
All errors are caused by wrong end-line interpretation. The following two lines have a n only difference in end-of-line symbol:

-$ns_ at 0 "$node_(0) setdest 1 2 3" 
+$ns_ at 0 "$node_(0) setdest 1 2 3"^M

The first line is interpreted well while the secon one -- wrong.
The second case results in one more token of zero length.
Both strings look exactly the same
Comment 3 Kirill Andreev 2011-12-14 10:51:43 UTC
Removed zero-length tokens. Testcase added.
Changeset a86b1ca836e3
Comment 4 Konstantinos Katsaros 2011-12-14 14:20:21 UTC
(In reply to comment #2)
> I think I have solved this problem:
> All errors are caused by wrong end-line interpretation. The following two lines
> have a n only difference in end-of-line symbol:
> 
> -$ns_ at 0 "$node_(0) setdest 1 2 3" 
> +$ns_ at 0 "$node_(0) setdest 1 2 3"^M
> 
> The first line is interpreted well while the secon one -- wrong.
> The second case results in one more token of zero length.
> Both strings look exactly the same

Hi,

So this is basically an TraNS "error" and this has to be changed, or will it be modified within ns-3 so that the extra symbol at the end is interpreted?
Comment 5 Kirill Andreev 2011-12-14 14:34:05 UTC
(In reply to comment #4)
> (In reply to comment #2)
> > I think I have solved this problem:
> > All errors are caused by wrong end-line interpretation. The following two lines
> > have a n only difference in end-of-line symbol:
> > 
> > -$ns_ at 0 "$node_(0) setdest 1 2 3" 
> > +$ns_ at 0 "$node_(0) setdest 1 2 3"^M
> > 
> > The first line is interpreted well while the secon one -- wrong.
> > The second case results in one more token of zero length.
> > Both strings look exactly the same
> 
> Hi,
> 
> So this is basically an TraNS "error" and this has to be changed, or will it be
> modified within ns-3 so that the extra symbol at the end is interpreted?

Hi!

Try your scenario with the latest ns-3-dev:)