search

cea-trust-platform / icoco-coupling

Interface for Code Coupling
8 stars 1 forks source link

Gérer un solveTimeStep qui ne calcule pas le pas de temps entier #3

Open cyril-patricot opened 5 months ago

cyril-patricot commented 5 months ago

CATHARE (mais aussi THEDI) sont susceptibles de sortir de solveTimeStep() après avoir "correctement" calculé un pas de temps plus petit que celui passé à initTimeStep(dt). Aujourd'hui c'est un mode d'échec, qui entraîne un abort.

Le fait est que si le pas de temps calculé était considéré comme réussi, cela ne gênerait pas l'écriture d'une boucle en temps ICoCo typique :

(dt, stop) = self.computeTimeStep()
while presentTime < tmax and not stop:
  self.initTimeStep(dt)
  ok = self.solveTimeStep()
  if ok:
      self.validateTimeStep()
      presentTime = self.presentTime()
      (dt, stop) = self.computeTimeStep()
  else:
      self.abortTimeStep()
      presentTime = self.presentTime()
      (dt2, stop) = self.computeTimeStep()
      if dt == dt2:
          raise on va pas y arriver
      dt = dt2

Si on dédit solveTimeStep() à l'écriture de cette boucle en temps, ce comportement pourrait être accepté.

Ce comportement me gêne aussi pour implémenter avec C3PO un certain type de couplage. Déjà il faut préciser que dans C3PO ICoCo est non seulement le moyen d'intégrer un code, mais c'est aussi (à peu de choses près) l'interface utilisée par la librairie elle-même. Tout est ICoCo dans C3PO. C'est peut-être ça qui pourrait être mis en cause aussi.

Donc dans C3PO, quand je couple des codes qui utilisent des pas de temps différents, je les mets chacun dans un objet TimeAccumulator qui leur fait faire une boucle en temps comme celle plus haut jusqu'à arriver au temps de "rendez-vous" des codes. Chaque TimeAccumulator se retrouve donc implémenter ICoCo, et un solveTimeStep() d'un TimeAccumulator consiste en un "macro pas de temps" de plusieurs pas de temps du code en-dessous. Si les points de rendez-vous sont connus à l'avance tout se passe bien. Mais si on veut faire quelque chose de plus dynamique, et s'arrêter sur un critère calculé "à la volée" (ce que computeTimeStep prévoit déjà !), et bien TimeAccumulator se retrouve gêné exactement comme CATHARE.

Qu'est-ce que ça vous inspire ?

cyril-patricot commented 2 months ago

Idée rejetée.