Sémantique temporelle des grandeurs échangées

[cyril-patricot]

Il est envisagé de conserver une sémantique temporelle "libre" pour les grandeurs d'échange (get / set).

Il est également partagé qu'il doit être possible d'accéder à des valeurs mises à jour après résolution (iterateTimeStep() ou solveTimeStep()), sans attendre un validateTimeStep().

Il est également évoqué la possibilité d'accéder à cette sémantique de façon un peu standardisée. Cela pourrait permettre de piloter plus finement les grandeurs échangées, notamment lorsqu'il y a sous pas de temps par un des codes couplés.

[natgrein]

Concernant l'ajout de fonctionnalités indiquant si tel champ ou telle valeur demandée au temps t+dt correspond effectivement au champ ou à la valeur en t+dt, en t+dt/2, à une moyenne entre t et t+dt, etc. :

Il faut à mon avis en tout cas conserver le point de vue selon lequel, lorsqu'on fait appel e.g. à getOutputMEDDoubleField("x") au temps t+dt, on obtient le champ "x" au temps t+dt.

Si en fait x(t+dt) = f(y, t, t+dt), c'est bien de le savoir, mais c'est néanmoins bien x(t+dt) que le code nous a renvoyé.

[cyril-patricot]

Je ne suis pas sûr de comprendre ce que tu veux dire par "Si en fait x(t+dt) = f(y, t, t+dt) ..." ?

[natgrein]

Par exemple x(t+dt) = y(t) ou y(t+dt/2) ou \int_t^{t+dt} y(t').

[cyril-patricot]

Rien que y(t+dt/2) ne dépend pas que du temps final t+dt mais dépend indépendamment de t et de dt. Ce n'est pas qu'un changement de variable.

[natgrein]

Oui, nous sommes d'accord. Ah pardon, je viens seulement de comprendre ta remarque. Alors je rectifie : on récupère le champ x(t+dt, dt). :)

[cyril-patricot]

On semble se diriger vers une méthode d'introspection optionnelle de type getSemantiqueTemporelle(name) -> renvoie une valeur dans une liste préétablie.