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
Currently, each Diagnostic has a compute_timestamp keyword argument that is supposed to tell PHARE how often a given diagnostics should be computed.
This comes in addition to the write_timestamps that says how often the diag should be dumped.
The idea behind the "compute" was that some diags may require computations more often than being written, like for instance a time averaged density field, could be the result of computing a running average density field every 10 simulated time steps but dumping the averaged value every 100 dt only.
However having these to timestamps set by the user require us to check they are compatible etc.
It should not be the user's problem to figure out how often a given thing should be computed, pharein should figure it out by itself given the type of the diagnostics and the write cadence.
This issue is therefore about:
removing compute_timetamps from the Diagnostics (and subclasses) interface
having diagnostics figuring out the compute cadence themselves.
The text was updated successfully, but these errors were encountered:
Currently, each Diagnostic has a
compute_timestamp
keyword argument that is supposed to tell PHARE how often a given diagnostics should be computed.This comes in addition to the
write_timestamps
that says how often the diag should be dumped.The idea behind the "compute" was that some diags may require computations more often than being written, like for instance a time averaged density field, could be the result of computing a running average density field every 10 simulated time steps but dumping the averaged value every 100 dt only.
However having these to timestamps set by the user require us to check they are compatible etc.
It should not be the user's problem to figure out how often a given thing should be computed, pharein should figure it out by itself given the type of the diagnostics and the write cadence.
This issue is therefore about:
compute_timetamps
from the Diagnostics (and subclasses) interfaceThe text was updated successfully, but these errors were encountered: