Announcement: OMNeT++ 5.0 beta 1 released

[Varga, András]

Dear all,

We are happy to announce the first preview release of OMNeT++ 5.0. The main
highlights of this release are extended logging facilities, and the new Canvas API
that allows your model to draw freely on the surface of a module.

This beta is should be sufficiently stable for daily use, but does not yet contain
all changes we have planned for the 5.0 release. More betas can be expected
in the next months, adding the missing pieces.

Changes in this release:

Core:

 - Added the Canvas API, a figure-based 2D drawing API. The Canvas API allows
   augmenting simulations with graphical elements. Item types include various
   shapes, text and image, including an SVG-like "path" item (a generalized
   polygon/polyline, with arcs and Bezier curves). Transformations (scaling,
   rotation, skewing) are supported, as well as transparency.

 - New logging API. It features six log levels (FATAL, ERROR, WARN, INFO,
   DETAIL, DEBUG, TRACE), category support, compile-time and runtime global
   and per-module log level thresholds.

   Also, much more information is passed with each log line to the user
   interface code, allowing one to display a wealth of information in the log
   prefix (log level, file/line, event number, simulation time, module name
   and type, object name and type, and so on).

   Incompatibilities:
     - lower-case ev<< is no longer legal, use EV<< instead
     - ev.printf() was removed, use the stream API (EV<<) instead

 - Introduced cEvent as a base class of cMessage. cEvent allows scheduling
   of arbitrary code for a simulation time that runs independent of modules.
   Override the execute() method of cEvent to specify the code. cEvent is
   not intended for use in simulation models; the primary motivation is to
   allow implementing simulation time limit with an "end-simulation" event,
   and to encapsulate foreign events (e.g. SystemC events and crunching)
   for seemless integration with the simulation event loop.

 - Added support for simulation lifecycle listeners. Listeners are called back
   before and after network setup, on network initialization, before and after
   network finalization, and so on. The motivation was to allow more flexibility
   when writing initialization and shutdown code for schedulers, result
   file managers and other extensions.

 - Channel objects made equal to modules in the sense that now they also have
   IDs (the getId() method was moved from cModule to cComponent, the common base
   class of modules and channels), and they are also registered with cSimulation.

 - cTopology improvements:
   - added factory methods for links and edges
   - added methods to manipulate the graph (e.g. build a graph from scratch)

 - Removed int8..int64 and uint8..uint64. Models should use the standard integer
   types from <stdint.h> that end in "_t": int8_t, uint8_t, etc.

 - check_and_cast<> improved; added check_and_cast_nullable<> that accepts NULL
   pointer as input

 - New fingerprint computation algorithm. The goal was to make the fingerprint
   less sensitive to uninteresting changes (e.g. removal of an inactive module),
   and more sensitive to interesting ones (e.g. change in packet lengths).
   To get the old fingerprints, define USE_OMNETPP4x_FINGERPRINTS when compiling
   OMNeT++.

 - cClassDescriptor interface changes (method renaming and arg list changes)

 - Code cleanup, including:
   - removal of 3.x backward compatilibity features (WITH_DOUBLE_SIMTIME,
     WITHOUT_CPACKET)
   - removal of deprecated classes, functions and macros (cLinkedList,
     cSimulation::operator[], Define_Function(), etc.)
   - cTopology: internals refactored (use STL instead of arrays, etc.)
   - error code enum members renamed from eXXX to E_XXX

Cmdenv:

 - Log lines can now be prefixed with information such as the module
   path; simulation time; event's class and object name; file/line
   of the log statement; class, name and pointer of the object
   containing the log statement; etc. The format of this prefix can be
   changed from ini files.

 - New inifile config options: cmdenv-log-format, cmdenv-log-level.

Tkenv:

 - The bgs (background scaling) display string tag has been removed. It was
   originally introduced more or less as a default zoom level, but lost its
   significance since interactive zoom has been introduced.

 - Zooming no longer affects icon sizes on the screen (but you still have
   the Increase/Decrease Icon Size, Ctrl+I/Ctrl+O menu items in Tkenv).

 - Finished implementation of the Canvas API Tkenv rendering. The
   implementation is based on figure renderers (see FigureRenderer class)
   that can be registered for various figure classes.
   The implementation is based on the Tkpath Tcl/Tk extension, which was
   significantly enhanced by our team.

 - Tkpath is now also used internally for drawing submodules, connections
   and the like. Benefits include:
   - unlimited zooming of image backgrounds
   - antialiased drawing (Tk canvas didn't have antialiasing)
   - OS X: images are no longer forced into 1-bit transparency
   - labels are now outlined (have a "halo") to make them readable on noisy backgrounds
   - range indicator fill is now semi-transparent (because Tkpath supports that)
   - performance improvements e.g. on OS X, and with image backgrounds

 - Display log prefix; log prefix format and log level configurable via the Options dialog

IDE:

 - Several minor improvements. NED editor support for canvas items is pending.

Example simulations:

 - Added samples/canvas, a demo for the Canvas API

Bugs fixed: see http://dev.omnetpp.org/bugs/changelog_page.php?project_id=1

Feedback is welcome!

Best regards,

Andras and the OMNeT++ team

[Pedro Yébenes Segura]

Thank you, you are doing a great effort in improving OMNeT++.

Are the models made with OMNeT++ 4.x compatible with this new version?

Regards,

[Rudolf Hornig]

There are no big changes. Check the include/ChangeLog file. Mostly additional new APIs and some renaming.

INET 2.6 for example compiles just fine with both 4.6 and 5.0b1

Rudolf

[Christoph Sommer]

Varga, András wrote:
> - New logging API. It features six log levels (FATAL, ERROR, WARN, INFO,
> DETAIL, DEBUG, TRACE), category support, compile-time and runtime global
> and per-module log level thresholds.

Much appreciated! Setting the log level works smoothly on both the
command line and in tkenv, albeit with one exception:

I did not manage to get models to output information with log-level "TRACE".

Independent of which level I set cmdenv-log-level or the log-level in
Tkenv to, no output was generated for these statements. For any higher
level, things worked as expected: I could enable/disable printing of the
relevant levels by setting appropriate options.

I tried building and running both from command line and from the IDE,
always with the same effect.

Did I miss something that is needed to make EV_TRACE work?


Best,

Christoph


--
Dr. Christoph Sommer
Distributed Embedded Systems Group
University of Paderborn, Germany
http://www.ccs-labs.org/~sommer/

[Varga, András]

Hi Christoph,

There is also a per-component log level which defaults to DEBUG, so TRACE is filtered out. (Different log levels are in AND relationship.). Defaulting to DEBUG is probably a bad idea, it should  be TRACE, the most detailed level. Anyhow, adding

**.log-level = TRACE

to omnetpp.ini now should help...

Andras

--
You received this message because you are subscribed to the Google Groups "OMNeT++ Users" 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/d/optout.

[Christoph Sommer]

Varga, András wrote:
> There is also a per-component log level [and] Different log levels are in AND relationship

many thanks - things work just fine now!

Indeed, seeing as all three are in "and" relationship, I agree that it
might make sense to let all but the global one default to the highest
verbosity level.

[Doug]

FYIs

* Section 7.2 of Omnet manual refers to "ev" -- which is now gone.

* Both Manual.pdf and UserGuide.pdf have copyright of 2014.

* 3rdparty.txt references BLT which I think it no longer used.

##################

Where do I find information/documentation on new logging features? (I see info in API-changes.txt, is that the main source right now?)

Thanks - great release as always!

Doug

PS I noticed that omnet 5.0 is smarter concerning incorrect signal definitions!

[Doug]

I really like what I see with new canvas and animation capabilities in 5.0!

With these new capabilities, will INET 2.99 mobility models be changed in how they interact with canvas?  (Maybe better divorce or separate model dynamics from the animation of them?)

As I look at the "canvas" example, it would be easy to separate the CarAnimator module into 2 modules, one for drawing, the other for car movement/dynamics (model-view, named something like "CarMobility" and "CarAnimator" or "StreetView").

For INET, IMobility defines the contract for other modules to locate its mobility model and signal changes, but specific mobility models must ultimately subclass MobilityBase to properly "draw" them themselves into the canvas.  I do realize that I could subclass to do drawing and call a different module for dynamics, but then you have to ask yourself, is the mobility module really a 'mobility' module if the only thing it does is position and draw on the canvas?  (Which of course it should be named something like 'map' or something more akin to what is actually being drawn.)

I see this issue in the OS3 package which I'm updating -- satellite dynamics are modeled using SGP4 algorithms, but they are intermixed with 2 mobility modules "SatSGP4Mobility" and "SatSGP4FisheyeMobility" which really don't do any mobility calculations, they just call another module that calculates mobility/sgp4 routines.  So both "mobility" modules are not really mobility at all -- they simply position themselves to be drawn on a canvas to create a particular view (SatSGP4Mobility positions things assuming a world map view, SatSGP4FisheyeMobility positions things assuming a so-called fisheye view).  In fact to be more specific, the "SGP4" in both of those mobility modules is meaningless, they could call any module that supported a particular interface for model dynamics.  The very name in some way illustrates the intermixing of model-view.

Creating the separation could spawn a set of canvas/view oriented modules independent of the actual mobility movement characteristics.  The 'view' modules could in fact be the subscribers to the signals generated by the mobility modules analogous to how other INET modules interface with them.

Thanks - 5.0 has some really nice improvements!

Doug

[Rudolf Hornig]

On Wednesday, 25 March 2015 03:15:47 UTC+1, Doug wrote:

I really like what I see with new canvas and animation capabilities in 5.0!

With these new capabilities, will INET 2.99 mobility models be changed in how they interact with canvas?  (Maybe better divorce or separate model dynamics from the animation of them?)

Until now INET models were not really interacting with anything directly as there was no canvas at all. The animation/graphics was declarative until now using the display string (with some rare exceptions like the obstacles models (that were using a very ugly hack to "draw" on the module background)

From now on, we will keep the default declarative animation, but you will be able to use the canvas API to add anything extra you need. Check the new physical environment models in INET 2.99 which already use the new canvas API (in fact a preliminary canvas API was already included in OMNET 4.6, but it was not made "public"). 

 

As I look at the "canvas" example, it would be easy to separate the CarAnimator module into 2 modules, one for drawing, the other for car movement/dynamics (model-view, named something like "CarMobility" and "CarAnimator" or "StreetView").

You should not see the example as a design recomenndation. Obviously it mixed the movement and display code (not to mention that it does not contain anything useful that is actually simulated :)

You are right that in a proper framework the movement and the display/animation should be separated. The main reason is that your simulation result may and mostly does depend on the movement pattern of the nodes on the other hand it should never depend on a display code. i.e. your simulation must return exactly the same results if you are running it in Cmdenv.

This clearly means that we need to architect INET in a way that the two parts are separated. If we want to have a display code replacable by the user, then a saparate "animator" class is an obvious choice as you've suggested.

 

For INET, IMobility defines the contract for other modules to locate its mobility model and signal changes, but specific mobility models must ultimately subclass MobilityBase to properly "draw" them themselves into the canvas.

No, mobility should NEVER draw anything. Drawing must be separated from the actual model. Until now all drawing was separated (inside OMNeT++), with the canvas API you can create model specific graphics/animation that resides in the INET codebase, but for the above reasons it still have to be clearly separated.

 

 I do realize that I could subclass to do drawing and call a different module for dynamics, but then you have to ask yourself, is the mobility module really a 'mobility' module if the only thing it does is position and draw on the canvas?  (Which of course it should be named something like 'map' or something more akin to what is actually being drawn.)

As you have figured out, the proper way to customize the animation is to have a (by default empty) "animator" module that is replaceable by the user that hooks on the mobility's change signals. We will think about this. I would strongly suggest to check the exmaples/wireless/obstacles example as this is the first one that really uses the new canvas.

 

I see this issue in the OS3 package which I'm updating -- satellite dynamics are modeled using SGP4 algorithms, but they are intermixed with 2 mobility modules "SatSGP4Mobility" and "SatSGP4FisheyeMobility" which really don't do any mobility calculations, they just call another module that calculates mobility/sgp4 routines.  So both "mobility" modules are not really mobility at all -- they simply position themselves to be drawn on a canvas to create a particular view (SatSGP4Mobility positions things assuming a world map view, SatSGP4FisheyeMobility positions things assuming a so-called fisheye view).  In fact to be more specific, the "SGP4" in both of those mobility modules is meaningless, they could call any module that supported a particular interface for model dynamics.  The very name in some way illustrates the intermixing of model-view.

Yes OS3 is incorrectly designed in this regard. I've spotted this when I was reviewing the model 1-2 years ago. That fisheye thing is definitely not related to mobility. We have plans to work on the mobility API after INET 3.0 release (http://inet.omnetpp.org/Plans.html), but I suggest to open a new discussion about this on the INET contrib mailing list.

 

Creating the separation could spawn a set of canvas/view oriented modules independent of the actual mobility movement characteristics.  The 'view' modules could in fact be the subscribers to the signals generated by the mobility modules analogous to how other INET modules interface with them.

Yep. That's our plan too. Let's discuss this further on the contrib list.

Rudolf 

[Doug]

Thanks for the quick response -- I'll check out the other INET examples as you mentioned!

Doug