VCI and VEC files

646 views
Skip to first unread message

Juan-Carlos.M...@sophia.inria.fr

unread,
Nov 24, 2009, 8:13:39 AM11/24/09
to omnetpp
Hi all,


there is a way to record only VCI files and not VEC files???


vector-recording=false in the ini file disables both.. :(


cheers.


JcM

Rudolf Hornig

unread,
Nov 24, 2009, 8:22:14 AM11/24/09
to omn...@googlegroups.com
There is some misunderstanding here. VCI files are just index files that make the processing and accessing of data inthe VEC file mush faster. They are generated automatically by the system, but they do not contain any user accessible data. In fact if you delete the VCI file, it will be recreated the next time you access the VEC files from the IDE. So you cannot do anything with the VCI files alone...

Rudolf


--

You received this message because you are subscribed to the Google Groups "omnetpp" group.
To post to this group, send email to omn...@googlegroups.com.
To unsubscribe from this group, send email to omnetpp+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/omnetpp?hl=en.



Juan-Carlos.M...@sophia.inria.fr

unread,
Nov 24, 2009, 8:27:31 AM11/24/09
to omn...@googlegroups.com
Thanks rudolf for the answer..


but, i realize that some fields in the vci files are the vector value
recorded in a time interval. That information could be usefull to resume
vectors in a first approach.. So... The columns 6,7,8,9 and 10, they
are meaningless numbers or they are the time interval (6 and 7) and
values recorded (9 and 10)??? i'm just guessing.. so, you can tell me.


thanks


JcM


Rudolf Hornig wrote:

> There is some misunderstanding here. VCI files are just index files
> that make the processing and accessing of data inthe VEC file mush
> faster. They are generated automatically by the system, but they do
> not contain any user accessible data. In fact if you delete the VCI
> file, it will be recreated the next time you access the VEC files from
> the IDE. So you cannot do anything with the VCI files alone...
>
> Rudolf
>
> On Tue, Nov 24, 2009 at 2:13 PM,
> <Juan-Carlos.M...@sophia.inria.fr
> <mailto:Juan-Carlos.M...@sophia.inria.fr>> wrote:
>
> Hi all,
>
>
> there is a way to record only VCI files and not VEC files???
>
>
> vector-recording=false in the ini file disables both.. :(
>
>
> cheers.
>
>
> JcM
>
> --
>
> You received this message because you are subscribed to the Google
> Groups "omnetpp" group.
> To post to this group, send email to omn...@googlegroups.com
> <mailto:omn...@googlegroups.com>.
> To unsubscribe from this group, send email to
> omnetpp+u...@googlegroups.com
> <mailto:omnetpp%2Bunsu...@googlegroups.com>.

Juan-Carlos.M...@sophia.inria.fr

unread,
Nov 24, 2009, 8:34:47 AM11/24/09
to omn...@googlegroups.com
Hi,

Probably if i explain what i'm doing probably my question will have more
sense.

I'm comparing the output of the same model, same parametrization, same
rnd seed, but different machines.
I realized that the results diverge hardly in some cases. And to compare
vector by vector, number by number is too time consuming. So, i'm
trying to see if the vci files are enough to quantify how much both
executions differs.

Also another approach is describe each vector statically and compare
those numbers.. but, anyway.. if vci are a sort of resume of the
described vector.. probably it will add more information to compare and
so, to have a better estimation of the error.

JcM

Rudolf Hornig

unread,
Nov 24, 2009, 11:33:25 AM11/24/09
to omn...@googlegroups.com
 VCI files are internal and undocumented, their content is implementation dependent and we may change them at any time so it is best not to rely on them. And to answer the question, they are generated from the VEC files, so you cannot generate them without generating the VEC files.

I'm not sure what is the use-case you are trying to achive? You need less data in the vector files?
Rudolf

Juan-Carlos.M...@sophia.inria.fr

unread,
Nov 24, 2009, 11:43:47 AM11/24/09
to omn...@googlegroups.com
here is the explanation what i'm doing..


but never mind... i'm doing the comparison by means of an two-way anova
(using R) over all the data.. more time consuming, but more accurate.


thanks


JcM

Rudolf Hornig

unread,
Nov 24, 2009, 11:46:17 AM11/24/09
to omn...@googlegroups.com
Ok, forget my previous message :)

If you run the same model, with the same parameters with same seed, and the difference is ONLY the machine architecture, then the results MUST be the same... If they are not, then this is a BUG/ERROR and must be reported. OMNeT was designed in a way that simulations on different machines MUST generate the same result.

Now this is the theory, of course we and also model developers can make errors that can inject nasty bugs that introduce platform dependency... Also at some degree the hardware is limited too... For example if a processor is not implementing the IEEE floating point math correctly, then you MAY get different results...

To help ourself find these kind of regression bugs we have introduced 'fingerprinting' in 4.0. This is a HASH value that is calculated during the run from data we feel relevant to the simulation. At each event: the event id, module id, simulation time is used to create the CRC. At the end of the run you will get a CRC value. If the CRCs are similar on different platforms, you can be sure, that the simulation has followed the same trajectory on both machine. Any divergence will result in a different seed. Of course this gives only a digital go/nogo result.

Take a look at Manual 9.1.3 regarding fingerprints.

Rudolf

Juan-Carlos.M...@sophia.inria.fr

unread,
Nov 24, 2009, 12:06:02 PM11/24/09
to omn...@googlegroups.com
Hi Rudolf,


i write between lines:


Rudolf Hornig wrote:

> Ok, forget my previous message :)
>
no problem :D
> If you run the same model, with the same parameters with same seed,
> and the difference is ONLY the machine architecture, then the results
> MUST be the same... If they are not, then this is a BUG/ERROR and must
> be reported. OMNeT was designed in a way that simulations on different
> machines MUST generate the same result.
>
Bad news.... i ran exactly the same model, in two machines:

A: Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz (2 cpu)
Linux 2.6.27.37-170.2.104.fc10.i686 #1 SMP i686 i686 i386 GNU/Linux

B: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (8 cpu)
Linux 2.6.26.6-49.fc8 #1 SMP x86_64 x86_64 x86_64 GNU/Linux

and we have different results. i just finish the scripts to compare
statistically all the vectors.. it will take some time, since the
simulation that i use as reference is a long one (5 Gb each vector
file). But the results will tell us how different are the results (in
time and in value).

here an small insight of the comparison:

Average Bandwidth:
Time Serie: F = 3.6598e+32, p < 2.2e-16 ***
Residuals 1963734 2.965e-16
1.510e-22
Values Serie : F = 4.5147e+32, p < 2.2e-16 ***
Residuals 1963734 2.953e-08 1.504e-14
Then, they are quite similar, but not THE SAME.. the residual error is
small, but not 0.
for vector that are exactly equal, residuals are 0.

> Now this is the theory, of course we and also model developers can
> make errors that can inject nasty bugs that introduce platform
> dependency... Also at some degree the hardware is limited too... For
> example if a processor is not implementing the IEEE floating point
> math correctly, then you MAY get different results...
>
well.. probably this is the case.

> To help ourself find these kind of regression bugs we have introduced
> 'fingerprinting' in 4.0. This is a HASH value that is calculated
> during the run from data we feel relevant to the simulation. At each
> event: the event id, module id, simulation time is used to create the
> CRC. At the end of the run you will get a CRC value. If the CRCs are
> similar on different platforms, you can be sure, that the simulation
> has followed the same trajectory on both machine. Any divergence will
> result in a different seed. Of course this gives only a digital
> go/nogo result.
>
> Take a look at Manual 9.1.3 regarding fingerprints.
>
yep. i have seen the manual and the fingerprints stuff.. that is quite
good idea. i'm running now several replicas on the same model with that
option to see what happen.

i let you know.


> Rudolf
>
> On Tue, Nov 24, 2009 at 2:34 PM,
> <Juan-Carlos.M...@sophia.inria.fr
> <mailto:Juan-Carlos.M...@sophia.inria.fr>> wrote:
>
> Hi,
>
> Probably if i explain what i'm doing probably my question will
> have more
> sense.
>
> I'm comparing the output of the same model, same parametrization, same
> rnd seed, but different machines.
> I realized that the results diverge hardly in some cases. And to
> compare
> vector by vector, number by number is too time consuming. So, i'm
> trying to see if the vci files are enough to quantify how much both
> executions differs.
>
> Also another approach is describe each vector statically and compare
> those numbers.. but, anyway.. if vci are a sort of resume of the
> described vector.. probably it will add more information to
> compare and
> so, to have a better estimation of the error.
>
> JcM
>
>
> Juan-Carlos.M...@sophia.inria.fr
> >> <mailto:Juan-Carlos.M...@sophia.inria.fr
> <mailto:Juan-Carlos.M...@sophia.inria.fr>>> wrote:
> >>
> >> Hi all,
> >>
> >>
> >> there is a way to record only VCI files and not VEC files???
> >>
> >>
> >> vector-recording=false in the ini file disables both.. :(
> >>
> >>
> >> cheers.
> >>
> >>
> >> JcM
> >>
> >> --
> >>
> >> You received this message because you are subscribed to the
> Google
> >> Groups "omnetpp" group.
> >> To post to this group, send email to
> omn...@googlegroups.com <mailto:omn...@googlegroups.com>
> >> <mailto:omn...@googlegroups.com
> <mailto:omn...@googlegroups.com>>.
> >> To unsubscribe from this group, send email to
> >> omnetpp+u...@googlegroups.com
> <mailto:omnetpp%2Bunsu...@googlegroups.com>
> >> <mailto:omnetpp%2Bunsu...@googlegroups.com
> <mailto:omnetpp%252Buns...@googlegroups.com>>.

Laura Marie Feeney

unread,
Nov 24, 2009, 12:28:00 PM11/24/09
to omn...@googlegroups.com
Hi,

Another source of difference can be different compiler and system
libraries installed on the machines, e.g. gcc 3.X on one and gcc4.X
on the other. (The validation tests for Energy Framework had this issue.)

Laura

Juan-Carlos.M...@sophia.inria.fr

unread,
Nov 24, 2009, 12:30:20 PM11/24/09
to omn...@googlegroups.com
Thanks Laura for the tip...


also here the gcc versions are different.. i'm doing some scripts to
quantify how different are the outputs. So, in that way we could state :
compiler difference makes no/a lot of difference in results. or kernel,
or any factor you want to test. hopefully the difference will be not
that much. but if it is... is good to know how to measure it.


JcM
Reply all
Reply to author
Forward
0 new messages