[Ns-developers] NS-3 GUI (visualization again)

[Jeremy]

Gustavo,

Again, great feedback.

5- The 'placement' files for wired nodes are also a PITA. ...
>

>From just a quick scan of graphviz I was not able to figure out if there was
a separate library. However, it does have command line tools that might be
able to be used in the absence of a library. If nothing else, a shell script
could be written and distributed with iNSpect so that graphviz can layout
the nodes and then have iNSpect run from that automatically. Obviously,
there are other options that could quite likely be better as well -- even
maybe creating an interpreter that reads straight from graphviz and a
command line option that attempts to fork graphviz and pipe information back
into iNSpect?

In any event, any of the options are probably going to need to wait a few
weeks until fall semester starts for the Toilers to do it alone. However, I
am going to put a ticket into bugzilla so that we at least look into it.

-Jeremy

On Thu, Jul 31, 2008 at 4:35 PM, Gustavo Carneiro <gjcarneiro at gmail.com>wrote:

>
>
> 2008/7/31 Gustavo Carneiro <gjcarneiro at gmail.com>
>
>
>>
>> 2008/7/31 Jeremy <jnorman at mines.edu>
>>
>>> Hey all,
>>>
>>> I am working with the Toilers on updating to NS-3 and have a few thoughts
>>> on
>>> the subject of visualization.
>>>
>>> First of all, I agree with using postmortum visualization argument for
>>> many
>>> of the reasons that have already been stated. The most important being
>>> fewer
>>> libraries. This is a big deal for those of us in research who are looking
>>> more and more at cloud computing or cluster computing in any way. Adding
>>> graphics library requirements just makes installation harder and more
>>> confusing.
>>
>>
>> I agree post-mortem is interesting.  I just don't agree post-mortem is
>> _all_ that is interesting. :-)
>>
>>
>>>
>>>
>>> Next, the latest version of iNSpect does compile and did when this
>>> conversation began (in fact the latest version is over a month old). It
>>> is
>>> version 4r2125 and at the bottom of the file list at
>>> http://alamode.mines.edu/~jnorman/toilers/inspect<http://alamode.mines.edu/%7Ejnorman/toilers/inspect>If you would like some
>>> help getting iNSpect to compile, we have documentation that is specific
>>> to
>>> many platforms at http://www.google.com/group/nsinspect. Additionally,
>>> I'd
>>> be glad to help anyone get going.
>>
>>
>> Thanks to your help, it now compiles for me as well.  Thank you.
>>
>>
>>>
>>>
>>> So let me fill everyone in on some of the advances of iNSpect since our
>>> last
>>> conversation. Many of them were specific to the questions at hand.
>>>
>>> Also, iNSpect has finally been made multi-threaded. The most interesting
>>> part of this is that the file readers are multi-threaded as well which
>>> allows the program to read separately from visualizing. The reason that
>>> we
>>> went through all the trouble of doing this was to make iNSpect able to
>>> read
>>> simulation information directly from a pipe and visualize real-time with
>>> the
>>> simulator. The only part left of the real time visualization is to
>>> connect
>>> the standard in to a file stream and get a trace file format that NS-3
>>> and
>>> iNSpect both understand.
>>> Using pipes addresses the issues of disk space and library dependencies
>>> by
>>> separating the two.
>>>
>>> As far as being customizable, we did not create a python/tcl/etc api for
>>> iNSpect, however, we have been working very hard to break iNSpect into
>>> clear
>>> MVC chunks which allow for representation of any information you need.
>>> There
>>> is now a data input API for reading from file streams, pipes, or SQL if
>>> necessary. Also, a model API which allows dynamic non simulation related
>>> information to be added. Finally we have a separate visualization API
>>> which
>>> allows new ways to visualize old data and easy ways to plug in new data.
>>> An example of how to add energy (on/off) information to the simulation is
>>> already up on the google group.
>>>
>>
>>>
>>> So for now, many of the features people want the most are nearly ready
>>> for
>>> use. Right now we are just in a lull because it is summer break on campus
>>> and are short on people. We welcome any help and especially insight into
>>> feature requests/etc to make sure that our tool is actually useful to
>>> people
>>> rather than just us.
>>>
>>> We expect to be wrapping up a lot of loose ends in the features I've
>>> mentioned and fully documenting them in the next month or so. There are
>>> only
>>> two serious steps left before it is a tool I would deem usable for NS-3:
>>> write a module to trace information we need out of the NS-3 API and get
>>> some
>>> more intense user-testing of the code.
>>
>>
>> I have been now trying to fire up iNSpect and my impressions are:
>>
>>   1- Lack of ns-3 integration, as you mention in that last paragraph.  I
>> was unable to get any ns-3 example to display in iNSpect.  So you're working
>> on it.  I get it.  However, I may not have time to wait for it, but that's
>> another matter;
>>
>>   2- Both command line and graphical interfaces are cluttered:
>>
>>       a) In the command line I need to run: ./iNSpect
>> sample/simple_wireless.conf   -l2 sample/simple.tr
>>           I have a problem with the configuration file: I hate
>> configuration files.  Why can't iNSpect just pick some default values and
>> make the customization optional?
>>
>>       b) The GUI has 3 windows, one with the animation, one with controls,
>> yet another with statistics.  Ideally it should be just one window with
>> everything.  Also the buttons are huge.
>>
>>   3- The matter of OpenGL I already discussed a few months back.  Besides
>> my lack of OpenGL coding skills (that's my own problem, I suppose), OpenGL
>> does not allow saving figures into vector graphics formats such as EPS, SVG,
>> or PDF.  A Cairo based renderer easily supports those formats.  On the other
>> hand, Cairo is usually slower than OpenGL for animations, I get that too :|
>>
>>   4- Being 100% C++ is a problem if I wanted to hack on it, as I am tired
>> of so much C++ lately :P  OK, maybe this is another personal quirk, and not
>> applicable to the project as a whole, I don't know.  Need do spend more time
>> coding Python and less C++ ;-)
>>
>
> I forgot one item:
>
>    5- The 'placement' files for wired nodes are also a PITA.  But I
> completely understand why you want it.  Wired simulations in NS-3 have no
> mobility models, and so nodes have no position.  Figuring out an optimum
> layout automatically for nodes with links to other nodes is a complicated
> problem, and one which a tool called graphviz is good at solving.  It also
> has a library, though I am not sure if the layout engine is exported by it,
> I'll check tomorrow.  So ideally a visualizer should be able to layout
> automatically even wired nodes, and get rid of the awful .placement file
> requirement.
>
> --
> Gustavo J. A. M. Carneiro
> INESC Porto, Telecommunications and Multimedia Unit
> "The universe is always one step beyond logic." -- Frank Herbert
>



-- 
Curiosity didn't kill the cat, it taught it something it didn't know before.