Fabio Luporini
Fabio Luporini
This is due to the way the DSE works at the moment -- detecting and hoisting expressions in a greedy fashion as a sequence of steps. Eg: ``` a =...
This is a non-trivial optimisation. Basically, the compiler, in doing data dependence analysis, abstracts away SubDimensions as pure Dimensions; so `yleft`, `yi`, `yright` they all become `y` to the eyes...
this code ``` from devito import * grid = Grid(shape=(3, 3)) t = grid.stepping_dim time = grid.time_dim x, y = grid.dimensions T = Dimension(name='T') x1 = Dimension(name='x1') x2 = Dimension(name='x2')...
Current code generation with ``DSE=aggressive`` might break in some examples (e.g., TTI) if the backend compiler is not ICC, as GCC doesn't like ``#pragma omp simd`` if the following loop...
[this map](https://github.com/devitocodes/devito/blob/master/devito/types/grid.py#L217) may actually be an `{expr: float}` map rather than a `{symbol: float}` map. Reproducer is `test_dimension.py::TestConditionalDimension::test_subsampled_fd`. The ConditionalDimension's spacing is a Mul between its factor and the parent's...
see TODO in `test_gpu_common`'s `test_streaming_conddim_forward` and `test_streaming_conddim_backward`
The following will produce a wrong value for `points` (and eventually will produce a wrong local per-section GPts/s) ``` from devito import * grid = Grid(shape=(20, 20)) x, y =...
For example, if we do: ``` u.biharmonic(1/m) ``` and `m` was not initialized with "sufficient" space order, then OOB accesses will be generated, and segfaults will happen how to fix:...
it should rather be `abs(...)` not `fabs(...)` this causes compilation warnings which however shouldn't affect the correctness...
* [ ] reproducer 1: ``` f= VectorTimeFunction(name='f', grid=grid, space_order=2) g=TimeFunction(name='g', grid=grid) ``` now: ``` f+g ``` gives one type of error, while ``` f-g ``` a completely different one...