Victor Leite

> is this patch really going to catch for example a situation like `u.dx.dx.dx.dx...` ? and, if so, can we add it to the test case It doesn't! I wasn't...

@FabioLuporini, I think I need some help on this issue. Please check if I’m going in the right direction [here](https://github.com/devitocodes/devito/pull/1598/commits/c58b4feaa7b264c803ba6e359958bd20acb75898). Note that, to avoid several errors, the proposed `oob` check...

Please check the current patch and tests. **Summary** * Dimensions with OOB indices are handled by shrinking the iteration space. No segfaults then. * This doesn’t cover SubDimensions * The...

> I now start thinking that it might just be better to raise an exception in case of OOB rather than "silently"shrinking the iteration space. If we're going to raise...

@FabioLuporini please check this again. Now I'm checking thickness in order to put the subdimension into `oobs`. I noticed thickness is used to express the outside offset in middle subdimensions,...

This is what happens on forward iterations. Last `p` calculated is `p[0]`. | Forward | m | | | | | M | |---------|:-:|---|---|---|---|:-:| | time | 0 | 1...

Ok, so the problem is when we use other functions that are accessed with the original `time` index (e.g. source or receiver functions). On these arrays, if we use `time_M...

So, if we need the last time step from a function previously calculated with `.forward`, and also we use a fixed time size function at the second operator, we need...

Assuming the user needs to be aware of time buffer behavior (especially about that implicit `time_m` shift) I think we could close this issue, since it isn't a bug but...

Hey guys, I think we have two topics related to this issue: 1) Similar formulations are resulting in different time-iteration loop arrangements (including more than one time-iteration loop within the...