Changes between Initial Version and Version 1 of Ticket #5677
- Timestamp:
- 2019-10-29T22:55:10Z (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #5677 – Description
initial v1 57 57 58 58 However, this model satisfies the following properties: 59 - each one of the ports {{{vol[i,j,k].bottom}}}, {{{vol[i+1,j,k].top)}}} for {{{i in 1:N-1, j in 1:M, k in 1:P}}} only show up in one connect statement inside a nested for loop59 - each one of the ports {{{vol[i,j,k].bottom}}}, {{{vol[i+1,j,k].top)}}} for {{{i in 1:N-1, j in 1:M, k in 1:P}}} only show up once in one connect statement inside a nested for loop 60 60 - each one of the ports {{{vol[i,j,k].right}}}, {{{vol[i,j+1,k].left}}} for {{{i in 1:N, j in 1:M-1, k in 1:P}}} shows only up once in one connect statement inside a nested for loop 61 61 - each one of the ports {{{(vol[i,j,k].back}}}, {{{vol[i,j,k+1].front}}} for {{{i in 1:N, j in 1:M, k in 1:P-1}}} shows only up once in one connect statement inside a nested for loop … … 112 112 At the end of the parsing, all the connect statements involving ports that only show up once can be expanded into the corresponding flow and effort equations, while array equations corresponding to the trivial boundary conditions can be generated for those ports that do not show up anywhere. 113 113 114 The remaining connection sets involving more than two connectors could be handled by unrolling them fully to scalar equations. Since they are expected to be a modest number, particularly if compared to the main loops or arrays, this shouldn't cause any major impact on compile time.114 The remaining connection sets involving more than two connectors could be handled in general by unrolling them fully to scalar equations. Since they are expected to be a modest number, particularly if compared to the main loops or arrays, this shouldn't cause any major impact on compile time. Note that there are no such equations in the above-mentioned test case. 115 115 116 116 @perost, @adrpo, what do you think?
