Is your feature request related to a problem?
Related to #111
While IMDClient must have a timeout on blocking socket reads to prevent excessively long tailing-waits in analysis scripts, the timeout should be practically used as little as possible. In ensemble simulations, relying on a timeout to evaluate when the simulation has ended can effectively wipe out speed-related performance gains from using streaming since it adds a fixed time cost to each simulation (for low output frequency, potentially >5 seconds per simulation)
Describe the solution you'd like
Integration tests should test that the socket read failed because of a closed socket rather than a timeout on a blocked read- this ensures the simulation shut down properly at least in principle (though edge cases for simulation engine shutdown likely exist)
Additional context
Thanks to @jpkrowe for pointing this out- this test would ensure his WESTPA integration performs optimally
Is your feature request related to a problem?
Related to #111
While IMDClient must have a timeout on blocking socket reads to prevent excessively long tailing-waits in analysis scripts, the timeout should be practically used as little as possible. In ensemble simulations, relying on a timeout to evaluate when the simulation has ended can effectively wipe out speed-related performance gains from using streaming since it adds a fixed time cost to each simulation (for low output frequency, potentially >5 seconds per simulation)
Describe the solution you'd like
Integration tests should test that the socket read failed because of a closed socket rather than a timeout on a blocked read- this ensures the simulation shut down properly at least in principle (though edge cases for simulation engine shutdown likely exist)
Additional context
Thanks to @jpkrowe for pointing this out- this test would ensure his WESTPA integration performs optimally