Transitions sur les bords de l'espace global. #4

New Issue

Open

opened 2023-10-16 15:10:02 +02:00 by neox · 0 comments

neox commented

2023-10-16 15:10:02 +02:00

Owner

Les deux opérations effectuées par les workers (évaluation d'une condition et modification d'un nombre de flèches) nécessitent chacune un accès à une localisation de l'espace global.

Cette localisation est obtenue en additionnant l'origine (ox, oy, oz) du worker à la coordonnée de la condition ou de l'action (x, y, z).

Pour simplifier, prenons l'exemple d'un modèle en une dimension avec 'r' le rayon (invariable) de l'espace local et size_x la taille de l'espace global.

Si les workers ne travaillent jamais au dela des bords (ox >= r et size_x - ox >= r), l'espace est dit 'borné'. Il n'y a rien de plus à faire.

Si les workers travaillent au dela des bords, l'espace n'est pas borné et les modifications effectuées au dela d'un bord apparaitront sur le bord opposé de l'espace.

Lorsqu'un worker travaille près du bord origine de cet espace (ox < r), l'addition de l'origine (ox) du worker à la coordonnée de la condition ou de l'action (x) donnera parfois un résultat négatif. Il suffit alors d'additioner size_x à ce résultat pour que la modification effectuée apparaisse près du bord opposé.

Inversement, lorsqu'un worker travaille près du bord extrême de l'espace global (size_x - ox < r), l'addition de l'origine (ox) du worker à la coordonnée de la condition ou de l'action (x) donnera parfois un résultat supérieur à size_x. Il suffit alors de soustraire size_x à ce résultat pour que la modification effectuée apparaisse près du bord origine.

Cette issue devrait remplacer l'issue #20 : Qui (scheduler ou worker) doit gérer les transitions ayant lieu sur les bords de l'espace global et comment ?
(qui est tellement confuse que je n'ai même pas le courage de la relire !)

Les deux opérations effectuées par les workers (évaluation d'une condition et modification d'un nombre de flèches) nécessitent chacune un accès à une localisation de l'espace global. Cette localisation est obtenue en additionnant l'origine (ox, oy, oz) du worker à la coordonnée de la condition ou de l'action (x, y, z). Pour simplifier, prenons l'exemple d'un modèle en une dimension avec 'r' le rayon (invariable) de l'espace local et size_x la taille de l'espace global. Si les workers ne travaillent jamais au dela des bords (ox >= r et size_x - ox >= r), l'espace est dit 'borné'. Il n'y a rien de plus à faire. --- Si les workers travaillent au dela des bords, l'espace n'est pas borné et les modifications effectuées au dela d'un bord apparaitront sur le bord opposé de l'espace. Lorsqu'un worker travaille près du bord origine de cet espace (ox < r), l'addition de l'origine (ox) du worker à la coordonnée de la condition ou de l'action (x) donnera parfois un résultat négatif. Il suffit alors d'additioner size_x à ce résultat pour que la modification effectuée apparaisse près du bord opposé. Inversement, lorsqu'un worker travaille près du bord extrême de l'espace global (size_x - ox < r), l'addition de l'origine (ox) du worker à la coordonnée de la condition ou de l'action (x) donnera parfois un résultat supérieur à size_x. Il suffit alors de soustraire size_x à ce résultat pour que la modification effectuée apparaisse près du bord origine. --- Cette issue devrait remplacer l'issue #20 : Qui (scheduler ou worker) doit gérer les transitions ayant lieu sur les bords de l'espace global et comment ? (qui est tellement confuse que je n'ai même pas le courage de la relire !)

No Label

BUG

Contrôle

Graphics/3D