You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, the framework components feature a "solver_history" which corresponds to the number of time steps a given call to the run method needs to have access to (e.g. a simple explicit backward Euler method will require a history of 2 [for t and t-1], but other methods may be multi-steps and require also t-2, t-3*, etc.).
Solver history is not currently a feature made very public because it only has impacts on the depth of the array storing the various timesteps of the component states. But I am wondering whether this should also impact on the depth of the arrays for the transfers between components, e.g. if a daily component needs to know about its internal temperature yesterday and the day before yesterday, does it also need to know about say the radiation from another component for the other component's timesteps overlapping with yesterday and the day before yesterday?
And if it should impact on the transfers, should the framework give the component the transfers for all the overlapping timesteps from the other components, or do some averaging over the time steps and give only one value?
The text was updated successfully, but these errors were encountered:
At the moment, the framework components feature a "solver_history" which corresponds to the number of time steps a given call to the
run
method needs to have access to (e.g. a simple explicit backward Euler method will require a history of 2 [for t and t-1], but other methods may be multi-steps and require also t-2, t-3*, etc.).Solver history is not currently a feature made very public because it only has impacts on the depth of the array storing the various timesteps of the component states. But I am wondering whether this should also impact on the depth of the arrays for the transfers between components, e.g. if a daily component needs to know about its internal temperature yesterday and the day before yesterday, does it also need to know about say the radiation from another component for the other component's timesteps overlapping with yesterday and the day before yesterday?
And if it should impact on the transfers, should the framework give the component the transfers for all the overlapping timesteps from the other components, or do some averaging over the time steps and give only one value?
The text was updated successfully, but these errors were encountered: