Fedsd fix self_id

[ChadliaJerad]

This PR fixes a bug that @jackykwok2024 reported when using fedsd utility with Python target.

Previously, we relied on the last event of a trace (after processing) not being about advancing time. A federate will send a resignation message after the last time advance. This behavior is valid in the C target, but it is not the case in the Python target.

In this PR, fedsd retrieves the correct self_id of a federate.

[edwardalee]

LGTM!

[lhstrh]

I looked at this, but I have to admit that I neither understand the original comment/code nor the change. In the new comment, it says that "'self_id' should not be -1," but the former is a string (which happens to be used as a key) and the latter is a number, so they can never be equal... I'm also unclear on what should means to convey. Are you trying to describe an invariant? I don't see an actual check where anything gets compared against -1, either, so I'm a bit confused... The for loop appears to assign to id the first 'Receiving' event that it can find. Could you explain why it does that?

[ChadliaJerad]

Sure!
Every federate trace file, after being converted to a csv file, is loaded as a dataframe (df).
A preprocessing will only keep the rows containing Sending messages, Receiving messages, or Scheduler advance time in df. Only these rows are needed to build the sequence diagram.

In order to identify the interacting components (federates and RTI), df uses the columns self_id and partner_id. The former specifies the federate whose trace is being processed, while the latter specifies the partner (which can be the RTI or another federate). The id of the RTI is -1, while the id of a federate is >= 0.

The event Scheduler advance time has -1 in self_id. Consequently, in order to identify whose trace file it is, we need to read the self_id of a sending or receiving message.
Note that initially, events have different interpretations of these values.

The fix checks that we are reading the self_id from a message event. Otherwise, the trace file will be misinterpreted as the RTI's. Before the fix, the last row was used, and the comment explicitly said: "# We rely on the fact that the first row of the csv file cannot be the end of advancing time" (first should be last, actually!)

A counter-example was found, that's why this fix correctly reads the actual self_id.

[lhstrh]

OK, thanks, that clear it up!

I would then make a change a long these lines:

    # Determine the the "self id" based on the first `Receiving` message (or use -1, the id of the rti, if there is none).
    id = -1
    for index, row in df.iterrows():
        if ('Sending' in row['event'] or 'Receiving' in row['event']) :
            id = row['self_id']
            break

Does that make sense?

[ChadliaJerad]

A minor tweak of the tweak:

# Determine the "self id" in the trace file based on the first `Receiving` or `Sending` message (or use -1, the id of the RTI, if there is none).

Ok?

[lhstrh]

A minor tweak of the tweak:

# Determine the "self id" in the trace file based on the first `Receiving` or `Sending` message (or use -1, the id of the RTI, if there is none).

Ok?

👍