Add timeout option about epinow2 HOT 6 CLOSED

Sorry yes, I missed that before. Done

from epinow2.

I have only put the timeout in the regional_epinow function which always returns a result set from the epinow call - this might mean we can sidestep the re-loading from disk issue.

from epinow2.

To give visibility of processes being killed this needs a mechanism to return the identity of any failures

from epinow2.

good news! Rstan does indeed seem to be killed and die.
bad news - funnily enough the summary processing doesn't handle missing data very well!

@seabbs do you have any feeling about how we should represent No Data Available / timeout in the estimate summary? I think the regional epinow route is using the out object to hold the data so it doesn't re-load from disk, and it also has the full list of locations in the region.

from epinow2.

That is great news and yes I can imagine.

So at the moment, the expectation is that when read in from the out object subregions that have failed will have NULL. These then get thrown away in regional_summary and everything continues as normal. When using regional_summary and reading in from disk I think it may be less fault-tolerant (with this bit of code:

Could continue this for subregions that have been timed out with an informative log entry or add a message to the out object/into the results folder but this would then add a bit of a headache for results processing.

When saving it would make sense to save a killed due to time-out flag definitely.

When outputting results (we stick with this duality, by the way, to stay being CRAN compliant + acting like a normal package whilst also supporting saving to folders in order to make producing regional results more independent) we could add another list entry on the top level to the out object. At the moment it has $regional and $summary. Could also add $timeout and list subregions that have been timed out (could do the same thing for regions that have errored). If going with this approach I guess it would make sense to save this information into the summary folder (though that adds complexity in passing objects into regional_summary whilst trying to maintain interoperability between reading in from disk and passing in objects).

Sorry - a bit of ramble - happy to clarify any of the above that is unclear.

from epinow2.

@seabbs Please could you add @JAllen42 so he can put a bit of work in on this? Thanks

from epinow2.