search

cea-trust-platform / icoco-coupling

Interface for Code Coupling
8 stars 1 forks source link

Méthodes stationnaires #1

Open cyril-patricot opened 5 months ago

cyril-patricot commented 5 months ago

Proposition : introduire solveSteadyState(), iterateSteadyState() et abortSteadyState(). Optionnel, uniquement pour les codes qui ont une méthode de résolution dédiée au stationnaire.

Étant donné qu'il n'y a pas d'ambiguïté entre différents instants comme pour les calculs transitoires (et pas de pas de temps à choisir), il me semble qu'il n'y aurait pas d'utilité à introduire initSteadyState() et validateSteadyState(). Un abort sans ces méthodes est peut-être bizarre, mais pouvoir nettoyer un état corrompu me semble important. Sans initSteadyState l'état auquel revenir n'est peut-être pas très clair. Sinon on peut laisser le mécanisme save/restore gérer le "nettoyage" ? Ou alors on dit qu'il faut carrément faire terminate() / initialize() ? Vous en pensez quoi ?

Tant qu'on ne passe pas à une nouvelle version majeure d'ICoCo il faudra maintenir le formalisme actuel pour faire un calcul stationnaire. A partir de la V3 je propose de supprimer la possibilité de faire initTimeStep(0.) en mode stationnaire pour faire un calcul stationnaire. Je pense que ces méthodes ne doivent pas interagir avec le mode stationnaire défini par setStationaryMode (qui à mon avis peut rester). Aujourd'hui j'implémenterais donc solveSteadyState() comme ça (excusez-moi d'écrire en python) :

mode = physics.getStationaryMode()
try :
  physics.setStationaryMode(True)
  physics.initTimeStep(0.)
  physics.solveTimeStep()
  physics.validateTimeStep()
finally:
  physics.setStationaryMode(mode)

Le débat est ouvert !

cyril-patricot commented 5 days ago

On se dirige vers une introduction de initSteadyState(), solveSteadyState(), iterateSteadyState(), abortSteadyState() et validateSteadyState() avec des sémantiques identiques à celle des calculs temporels.

Ces méthodes n'interagiraient pas avec le stationaryMode.