GitLab

NOTES:
- torus does not use it, as it has some routing logic preventing direct usage.
  It probably can be done, but I'll leave that for later.
- collectives in torus, dragonfly don't use it yet.

Rather than model-net LPs directly sending messages to other model-net LPs, LPs
can route the intended message through the scheduler interface to be queued up
for reception by the receiver (see the diff of loggp.c). This has the benefit of
    enabling things like priority and fairness for N->1 communication patterns.
    Currently, no packetizing is supported, and I haven't yet wrote checks for
    it - beware.

Loggp is currently the only supported model. simplenet could also be supported
without much trouble, but I doubt there's any demand for it at the moment.  This
should NOT be used by the dragonfly/torus models, as they have their own routing
backend.

- previously, packet issues were done without any consideration for device
  availability - within epsilon, preventing any meaningful scheduling
- enabled for loggp only, other networks will be incorporated shortly

All configuration now proceeds on a per-LP level, and requires separate
registration and configuration calls, as seen in the test programs.
model_net_set_params is no longer used, and is replaced by model_net_register
and model_net_configure. The dragonfly network, having two LP types bundled in
the same code-path, is special-cased in the registration code.

LP-mapping in model-net now has the following defaults:
- counts via codes_mapping_get_lp_count are now with respect to the calling
  network LP's annotation.
- when looking up network LPs via
  codes_mapping_get_lp_info/codes_mapping_get_lp_id, the annotation of the
  calling network LP is used. Hence, routing now occurs only between LPs of the
  same annotation. If the destination LP's group specified by model_net_*event
  does not contain a modelnet LP with the same annotation as the modelnet LP in
  the sender's group, then an error will occur (in codes_mapping).

Known Issues:
- modelnet users currently cannot specify which modelnet LP to use in the case
  of multiple modelnet LPs in the sender's group. This will be fixed in future
  commits after a consensus is reached on the best way to expose this
  information.

Adding collective modeling functions in model-net (currently only dragonfly/torus models support it)

- pull itself not yet tested

This prevents simulations that run for a certain duration from
crashing rather than ending when simulation time is reached.

- not producing correct results yet

- also tweak temporary hard-coded network parameters in loggp method to
  look somewhat like Tukey IB network for quick sanity checking of
  output

- just a copy of simplenet with variables and functions renamed for now

Adding statistics collection using lp-io in model-net API (comes from the simple-net stats collection), works for simple-net, torus and the dragonfly network models

Updates to modelnet torus plugin: reporting torus average+maximum latency and hops traversed via model-net API function

Adding the torus network plugin with modelnet API, see model-net/README_MN_TEST.txt for instructions to run the test

Adding back the simplenet magic check (it works fine for the case where there the modelnet and server LPs are on the same PE)