Common Variables for Modules in Router

[Athar]

Hi,

Please if anyone can guide me about global variable specific to one router. 

I have four modules in router (scheduler, inport , ouput port calculator and vc calculator) . I want to access one variable of type int to be accessible by all modules of every router (16 routers in Mesh).

I am trying with header file i.e. declared public variable in header file and added that header file in every module. And declared that variable as public in every module. But I don’t know the value doesn't remain same or constant. This is some thing related to C++ but still not able to use in OMNET.

Any suggestion will be highly appreciated.

Thank you.

[Rudolf Hornig]

What you are looking for is called static member variables (and has nothing to do with the access modifies (i.e. public)

http://www.learncpp.com/cpp-tutorial/811-static-member-variables/

as an added note: It is a very bad design decision to have global variables in a simulation. With perhaps the exception of global statistics variables (but global statistics also can be gathered with signal based statistics gathering). Generally, if you need a global variable, chances are that you are  doing something wrong...

Rudolf

[Athar]

Thank you so much for the help. I have declared a class (common.cc) and define a static variable in it. When i included the header file of this class in the class where i want to access it, it works fine. But when i included it in another class, it gave me the error that  "common" has not declared and simulator was not recognizing it and its int variable.

The variable of type int was accessed in the first class but i don't know why it is giving me error in second  class file.

(I also tried this with global.h file and this logic was working for global variables but as you said static variable is the right approach, so i was trying this logic with static variables)

Please guide.

Thank you.

Best Regards,

[Athar]

Problem solved. I just moved the #include "common.h" declaration to the top of all #include declarations. Strange solution but problem solved. 

Thank you.

[Humberto]

Dear Rudolf,

In my case I want to collect the network metrics at the very end of the simulation when all the finish() methods for all modules are called.
I though about a class that could contain a static metric, which should be updated each time a finish() method is called.
what do you exactly mean by signal based statistics gathering? Using what the chapter 4.14 describes?
I could inherate from cListener indeed and update the metrics as soon as the signals are being emitted. However,
 think about having 200 nodes and collecting metrics from 4 different layers (I use MiXiM).
 Don't you think that it could be slow? Could it be better a singleton pattern approach?
What is your opinion?

Kind regards

[Rudolf Hornig]

On Tuesday, 19 February 2013 11:31:49 UTC+1, Humberto wrote:

Dear Rudolf,

In my case I want to collect the network metrics at the very end of the simulation when all the finish() methods for all modules are called.
I though about a class that could contain a static metric, which should be updated each time a finish() method is called.

While this is feasible (perhaps that class should be a simple module itself at the network level) you will have an issue here: the order in which the finish methods are called at the end of simulation is undefined, so how do you know that ALL finish methods are called already and you have to write out your own global network statistic. (I admit you can do some tricks here like on each call to the global statistics module you increase a counter and you will now when the last call occurred (if you know the number of nodes in the network in advance), and after that call, you can write out also the global statistics. This is a bit hackish, but works.

i.e. you would have a networkStatistics simple module. It would have a parameter that tells how many calls can be made to its gatherStatistics() methods before it assumes that all modules has sent the values in and writes out the summary results. On the other hand if you gather a lot of data from a lot of different submodules inside a node, this becomes quite unmanageable. 

 

what do you exactly mean by signal based statistics gathering? Using what the chapter 4.14 describes?

Yes, but that chapter describes only the base mechanism of signals. Statistics are covered here:

http://www.omnetpp.org/doc/omnetpp/manual/usman.html#sec397

I could inherate from cListener indeed and update the metrics as soon as the signals are being emitted. However,
 think about having 200 nodes and collecting metrics from 4 different layers (I use MiXiM).

It depends really on what data you need. The question is: if you can do the network level statistics at the last step (i.e. in finish stage) why cant you do that AFTER the simulation has finished totally. (i.e. doing some post processing on the results itself). I admit it is not so pretty as you have to do an additional step in R or with some other approach.

 Don't you think that it could be slow?

No, signals are pretty fast and all of the statistics are already gathered at the module level, so gathering them at the network level just duplicates the amount of work required. please note also that you DO NOT have to do this manually. All you need is that you insert the needed @statistics definitions at the network level (i.e. copy it out from the NEd definitions from the modules).

Now unfortunately (after a quick look into MIXIM): it seems that mixim does not use the signal based statistics gathering at all so you are out of luck and cannot use the @statistics declarations :( (INET does use signals and it is much easier to gather signal network level stats)

Could it be better a singleton pattern approach?

For MIXIM, I think you should either 

- go with the singleton based one (although I would implement it as a separate simple module instead of using static variables)

- do some postprocessing on the results after the simulation finished

I do not recommend going with the litener/signal based approach (for MIXIM). For INET, signals would be the best choice.

[Humberto Escudero Argumanez]

Postprocessing is what I am trying to avoid in order to optimize the analysis of my results

Now I am trying to populate everything through static structs inside my external class, that does not inherits� from cSimpleModule. By now, compiles without troubles :D

For your remark ("order in which the finish methods are called at the end of simulation is undefined") I guess, I will use my GlobalMetrics::destructor().
I believe all the finish() methods had been already called once the simulation_main()� ends, right? but not the destructor.

I will let you know what happens.

PD: In case the static variables do not work out, I will go definitely with the singleton pattern.

On 19/02/13 12:00, Rudolf Hornig wrote:

On Tuesday, 19 February 2013 11:31:49 UTC+1, Humberto wrote:

Dear Rudolf,

In my case I want to collect the network metrics at the very end of the simulation when all the finish() methods for all modules are called.
I though about a class that could contain a static metric, which should be updated each time a finish() method is called.

While this is feasible (perhaps that class should be a simple module itself at the network level) you will have an issue here: the order in which the finish methods are called at the end of simulation is undefined, so how do you know that ALL finish methods are called already and you have to write out your own global network statistic.

(I admit you can do some tricks here like on each call to the global statistics module you increase a counter and you will now when the last call occurred (if you know the number of nodes in the network in advance), and after that call, you can write out also the global statistics. This is a bit hackish, but works.

i.e. you would have a networkStatistics simple module. It would have a parameter that tells how many calls can be made to its gatherStatistics() methods before it assumes that all modules has sent the values in and writes out the summary results. On the other hand if you gather a lot of data from a lot of different submodules inside a node, this becomes quite�unmanageable.�

�

what do you exactly mean by signal based statistics gathering? Using what the chapter 4.14 describes?

Yes, but that chapter�describes�only the base mechanism of signals. Statistics are covered here:

http://www.omnetpp.org/doc/omnetpp/manual/usman.html#sec397

I could inherate from cListener indeed and update the metrics as soon as the signals are being emitted. However,

�think about having 200 nodes and collecting metrics from 4 different layers (I use MiXiM).

It depends really on what data you need. The question is: if you can do the network level statistics at the last step (i.e. in finish stage) why cant you do that AFTER the simulation has finished totally. (i.e. doing some post processing on the results itself). I admit it is not so pretty as you have to do an additional step in R or with some other approach.

�Don't you think that it could be slow?

No, signals are pretty fast and all of the statistics are already gathered at the module level, so gathering them at the network level just duplicates the amount of work required. please note also that you DO NOT have to do this manually. All you need is that you insert the needed @statistics definitions at the network level (i.e. copy it out from the NEd definitions from the modules).

Now unfortunately (after a quick look into MIXIM): it seems that mixim does not use the signal based statistics gathering at all so you are out of luck and cannot use the @statistics declarations :( (INET does use signals and it is much easier to gather signal network level stats)

Could it be better a singleton pattern approach?

For MIXIM, I think you should either�

- go with the singleton based one (although I would implement it as a separate simple module instead of using static variables)

- do some postprocessing on the results after the simulation finished

I do not recommend going with the litener/signal based approach (for MIXIM). For INET, signals would be the best choice.

�

What is your opinion?

Kind regards

El lunes, 26 de noviembre de 2012 14:42:14 UTC+1, Rudolf Hornig escribi�:

What you are looking for is called static member variables (and has nothing to do with the access modifies (i.e. public)

http://www.learncpp.com/cpp-tutorial/811-static-member-variables/

as an added note: It is a very bad design decision to have global variables in a simulation. With perhaps the exception of global statistics variables (but global statistics also can be gathered with signal based statistics gathering). Generally, if you need a global variable, chances are that you are �doing something wrong...

Rudolf

On Monday, November 26, 2012 1:49:02 PM UTC+1, Athar wrote:

Hi,

Please if anyone can guide me about global variable specific to one router.�

I have four modules in router (scheduler, inport , ouput port calculator and vc calculator) . I want to access one variable of type int to be accessible by all modules of every router (16 routers in Mesh).

I am trying with header file i.e. declared public variable in header file and added that header file in every module. And declared that variable as public in every module. But I don�t know the value�doesn't�remain same or constant. This is some thing related to C++ but still not able to use in OMNET.

Any suggestion will be highly appreciated.

Thank you.

--
--
Sent from the OMNeT++ mailing list. To configure your membership,
visit http://groups.google.com/group/omnetpp
�
---
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
�
�

[Rudolf Hornig]

On Tuesday, 19 February 2013 16:40:38 UTC+1, Humberto wrote:

Postprocessing is what I am trying to avoid in order to optimize the analysis of my results

Now I am trying to populate everything through static structs inside my external class, that does not inherits� from cSimpleModule. By now, compiles without troubles :D

For your remark ("order in which the finish methods are called at the end of simulation is undefined") I guess, I will use my GlobalMetrics::destructor().
I believe all the finish() methods had been already called once the simulation_main()� ends, right? but not the destructor.

Yes, true. However you must be aware that finish() is called only on successful simulation finish, while the destructor is called even if the simulation failed to execute. An other issue might be the initialization of the static variables: while you can statically initilaize the variables, intheory omnet allows to run several simulations in the same process (using the -r command line argument). In this case the static variables will be initialized only before the first run. That's the reason why the singleton is recommended.

Rudolf

[Humberto Escudero Argumanez]

Please find my answer bellow...

On 20/02/13 10:36, Rudolf Hornig wrote:
> Yes, true. However you must be aware that finish() is called only on
> successful simulation finish, while the destructor is called even if
> the simulation failed to execute.

You are absolutely right

> An other issue might be the initialization of the static variables:
> while you can statically initilaize the variables,

This is actually the problem why I have finally left the static variables.
I posted it here
http://stackoverflow.com/questions/10065194/static-class-member-gets-undefined-reference-dont-know-why/14974704#14974704
I have not found still the solution to "how to properly declare and
initialize the members of a static struct variable"

> intheory omnet allows to run several simulations in the same process
> (using the -r command line argument). In this case the static
> variables will be initialized only before the first run. That's the
> reason why the singleton is recommended.

This I am not sure about it. We have to distinguish between definition
in the header file, declaration in the global scope (usually where main
or cpp is) and initialization. If your class inherits from
cSimpleModule, you have to ovewrite initialize(), so I assume (probably
I am wrong) omnet does the work of the initialization for you, or am I
wrong?

But, as I said, I decided to go for the singleton approach and now I
have face some other issues with the function findModule() as soon as I
get rid of it I let you know.