start_time from get_mon_arrival totally off

[DanielaRichter]

Hi,

I am new to simmer and github, so I hope to post this correctly.

I have a simulation containing multiple branches, batches and clones with more than 500 lines of code. It runs fine. The logged times are giving meaningful results.

However, when I compare the monitored arrival times with the logged times (one log_ right after the start of the trajectory and one at the end), the times are off.
e.g. from the log I get
38563.1: patient_0: arrival
140381: patient_0: upload finished

but the monitoring gives me
start_time: 140369.2
end_time: 140380.8

as a consequence flow times etc. are off as well.
As the code is really long, I have not copied it here. Don't know how that is usually handled.

But does anyone have an idea where to look for a solution to the issue?

[Enchufa2]

Welcome! For large files, if your code can be shared, then you can drag and drop a text file in the comment box, and it will be attached to the conversation. It would be even better if you could reach a minimal example (few lines) showing a similar behaviour. In that case, you can directly paste your code in the comment box surrounded by blocks of 3 backticks as follows:

```
<some code>
```

[Enchufa2]

The activity_time seems to be fine though.

[DanielaRichter]

That's a pity. I will think about how to non-nest that it still makes sense. Two short questions (maybe you could point me in the right direction):

1. is there another way to induce parallel activities/trajectories other than cloning? like to trigger a generator from a trajectory at a certain point? I can then solve the synching via trap/send.
2. I might just take the log output, write it to file and look for the specific times, then plot it myself. This however might be challenging with multiple simulation runs, but I will see.

Thanks a lot for your reply! That's amazing.

[Enchufa2]

1. Yes, you could trigger a generator using activate, then wait for a signal. There's a helper function when_activated to have a generator stopped until activate is called, then generate one or more arrivals. See the examples in the docs. Note also that

clone (n = 2,
         ge,
         td %>%
         clone( n = 2,
            tde,
            tre) %>% 
         synchronize(wait = TRUE)) %>% 
  synchronize(wait = TRUE)

is equivalent to

clone (n = 3,
         ge,
         join(td, tde),
         join(td, tre)) %>%
  synchronize(wait = TRUE)

2. I don't recommend that. As a workaround, it would be much easier to use set_attribute and then take the output of get_mon_attributes (note that you need to set mon=2 in the corresponding generator to be able to monitor those).

[DanielaRichter]

1a. I will try that
1b. the only difference I see is that td gets triggered twice instead of once. As td seizes quite some resources that might change things for the model.
2. perfekt! thank you.

[Enchufa2]

FYI, nested clones seem to work just fine. The problem has to do with batch cloning. #285 has a simple example of the same issue without nested clones.