Gate vector expansion suddenly not working

[phdavis1027]

Hi all,

This is kind of a multi-part question. Again, I have inherited a project and am working to dockerize it. It turns out that there are some version differences between the codebase as I have found it and the versions of inet/omnet distributed in the official Docker images (for example, the codebase originally reference EtherLinks as opposed to the more recent EthernetLink). As such, I am porting the code. The error I'm stuck on is this:

<!> Error: S[] gates are all connected, no gate left for '++' operator when connecting the gates on the inside (note that the network is built top-down), at /root/models/OWCeM/owcem/simulations/OWCellGrid/OWCellGrid.ned:75 -- in module (omnetpp::cModule) OWCellGrid.owcells[0] (id=11), during network setup

Now, this makes sense. The gate S is part of an unsized array in a top-level module, which documentation says shouldn't work. However, I know for a fact that this code works under some environment because I have run in it on a remote server. What I would like to figure out is why this code ever ran in the first place and what the best approach is for patching it. The relevant excerpt is:

            connections allowunconnected:
                for i=0..racks-2, for j=i+1..racks-1 { 
                    rack[i].g++ <--> Eth10G <--> rack[j].g++;
                }
                rack[0].g++ <--> N++ if (exists(N));
                rack[int(racks/2)].g++ <--> S++ if (exists(S));
                rack[int(racks/4)].g++ <--> E++ if (exists(E));
                rack[int(racks/2) + int(racks/4)].g++ <--> W++ if (exists(W));

Where rack.g is defined as

gates:
   inout g[];

and the other gates are

gates:
                
                inout N[];
                inout S[];
                inout E[];
               inout W[];
               
                inout NW[];
                inout SW[];
                inout NE[];
                inout SE[];

[rhornig]

In a compound module the same gates (including vector gates) are visible both from the inside and the outside of the module. As the network is built from top-down the size of a vector gate is determined by the outside world (i.e. how many connections you add to a vector). Once that is determined, inside the module, you should take care that all of the gates in the vector are connected also inside.

The gate++ syntax increases the size of the vector and connects the connection to the newly created gate. Now this implicitly means that it determines the size of the vector (i.e. by how many times ++ was called on the gate) so it should be used only from the outside.

Here the code clearly uses the ++ syntax inside a module to set the gate sizes and this can cause inconsistencies with the outside world (which was already set up because of the top-down setup).

Long story short, if you see something like gate++ (without a submodule prefix) that is suspicions and most likely incorrect because you are not using ++ on submodule's gate but on your own (out-facing) gate (from the inside). Inside a module you should usually use for loops, sizeof(gate) and direct indexing (gate[i]) because the size is already determined by the outside setup. Outside of the module you are free to use submodule.gate++

[phdavis1027]

I sort of suspected I would have to do some computation to figure out exactly how large gate arrays should be/which exact gates to hook up. Also I'm still confused about why this code (or anything even resembling it) ever worked in the first place, since the gates are declared as indeterminately sized wouldn't this break the rule against expanding gate vectors in modules all the time?

[rhornig]

The code would not throw an out of index error if the gate size defined outside of the module is greater than your assumed gate size in the inside. In that case you would not have connected all gates and there would be gates that are connected on the outside, but not on the inside. This is a fatal error and the simulation kernel would throw an error, but you have explicitly disabled this error check by the connections allowunconnected declaration. Had not you disabled that error check, the error would have surfaced immediately.

Generally, if you use allowunconnected you should really be very careful. There could be instances where its use is justified (like when you implement an abstract base module and only derived modules will connect the gates later). Also it's much better to add the @loose annotation to individiual gates as that disables this error checking ONLY on the specific gate instead of disabling it on all connections with the allowunconnected.