Making Periodic Postprocessors more robust

[gsgall]

Periodic Objects Fix

As noted in #253 the periodic post processor objects initial implementation were fragile. While unable to replicate the results of these tests failing I have identified what I believe to be a potential issue in the initial design. In the initial design of these the value of the post processor was reset based on the difference between the the simulation time and the starting point of the next period being within the following criteria

std::abs(_t - _next_period_start) <= _dt * 1e-3 

I think this criteria was the cause of the periodic test failures since it is not a very robust check. I have updated the criteria to have what I believe to be a more robust check in the form

   (_t + _dt - _next_period_start) / _next_period_start >= 1e-6)

This criteria maintains the same behavior as the initial implementation but has a tighter tolerance on the check and also uses a relative difference to help alleviate potential precision issues that the initial implementation likely suffered from.

Additional clean up

I also took this opportunity to cleanup the tests of the post processors since all of the tests were named receiver for some reason, probably left over copy pasta, they were renamed to make more sense. Additionally, some of the parameters in the periodic objects were updated to be range checked to prevent misuse.

[moosebuild]

Job Documentation on df9b9b7 wanted to post the following:

View the site here

This comment will be updated on new commits.

[lindsayad]

thanks @gsgall for the quick work!

[gsgall]

thanks @gsgall for the quick work!

@lindsayad Happy to help!