# Re-run the model in a previous time segment during a long run

**URL:** <https://brian.discourse.group/t/re-run-the-model-in-a-previous-time-segment-during-a-long-run/296>\
**Category:** Support\
**Created:** [16 February 2021 15:43 UTC](https://brian.discourse.group/t/re-run-the-model-in-a-previous-time-segment-during-a-long-run/296 "2021-02-16T15:43:15Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![mstimberg](https://yyz2.discourse-cdn.com/free1/user_avatar/brian.discourse.group/mstimberg/32/11_2.png) [@mstimberg](https://brian.discourse.group/u/mstimberg)\
**Post date:** [17 February 2021 09:56 UTC](https://brian.discourse.group/t/re-run-the-model-in-a-previous-time-segment-during-a-long-run/296/2 "2021-02-17T09:56:59Z")

</div>

This is very related to my comment here: [Multiple run in standalone mode - #9 by mstimberg](https://brian.discourse.group/t/multiple-run-in-standalone-mode/131/9)  
If you need this kind of logic, then using runtime mode is much more straightforward (you could either stop the simulation or implement the logic in a `network_operation`). If you want to do it in C++ standalone mode, then the only way I can think of is via C++ code that implements the logic. Instead of `rate = ta_img(t, i)*Hz` you’d use something like `rate = my_func(t, i)*Hz` and implement `my_func` in C++ so that it looks at the recent firing rate and decides whether to present the next stimulus or the same stimulus with a higher firing rate. This solution is not very “elegant”, though, because you’d have to access some Brian internals such as the names of arrays in the generated code. If you want to go down that road, have a look at this thread: [User-defined functions](https://brian.discourse.group/t/user-defined-functions/271)

---

_[View the full topic](https://brian.discourse.group/t/re-run-the-model-in-a-previous-time-segment-during-a-long-run/296)._