Stopping long calculations and exiting long-calculation dialog boxes

[chfleming]

Occasionally the students want to interrupt long calculations (like model fitting) to go back and do something they forgot.

Related to this, the dialog box for long calculations can be closed, but the calculation keeps going without any indication of the progress. Is there any way to remove the close "X" button from those dialog boxes, or if a stop-calculation feature is implemented, to have the close button also stop the calculation.

[xhdong-umd]

I am not sure if there is a reliable way to stop calculations. In my development with parallel computation, hitting stop to stop r session often do not work completely, I often need to restart R.

I don't think it's possible to stop parallel computation and return back to app normally. Though I can take a look at it and try.

[chfleming]

If not, is there a way to remove the "X" close button from the calculation dialog windows?

[xhdong-umd]

I will look into it.

[xhdong-umd]

The dialog is a notification window, and the close button is an integrated part of that window. There is no option to remove the close button, unless we change the internal structure of the window extensively.

Conceptually, the window is just an notification, closing it should not mean stop the calculation. You can receive many notifications in all kinds of platform, turning off them usually doesn't mean to negate the action that notification is reporting, unless there is a specific "cancel" button.

One possible alternative approach for this challenge is to use the new shiny async feature. However that may not really solve the problem:

• The async feature is designed to be launching new tasks in new R sessions that don't block current R session (when using future, which is more relevant to our purpose here). I'm not sure if you can stop/cancel the task reliably and safely. From my experience, if the calculation was long I often have to terminate the R session forcefully. An unresponding R session is unlikely to stop elegantly.
• Our app need the calculation result to get to next step. To launch a modeling task then return to app, continue react to user input will not have benefit, but will confuse users instead.

[xhdong-umd]

There seemed to have new development in this aspect, namely async and ipc package. I can try to send the time consuming task to a sub process, thus make the task stoppable. When the task is running, there is not much user can do, maybe just explore around, but they really should not change anything that can change modeling input (as that will make the app status mismatch the original modeling input).

I think I can make a dialog always present and prevent user change page. The only use of the dialog is to make the task stoppable. This may work or not work as stopping a parallel process can be unpredictable.

[xhdong-umd]

That being said, one related question is whether we can provide more detailed progress report? Then user have more information to decide either wait or stop the task.

@chfleming If you can have some progress estimate inside your modeling function, you can add a function parameter setProgress, then set the progress value in various places:

setProgress(0.1) .. setProgress(0.8) .. setProgress(1.0)

setProgress can be a function to create txt progress bar in console, or a function to create shiny progress bar in shiny app.

[chfleming]

There are various stages in ctmm.select, but because ctmm.select is doing a kind of stepwise regression, there's no way to know a priori when it will terminate. With some kinds of models, you can put a bound on this, though.

Within ctmm.fit, which is run multiple times in ctmm.select, there are a few stages and the longest is the optimization. Within the custom optimizer, I can estimate the progress, but because this is an estimate it does not increase monotonically. I.e., estimated progress can decrease at times.

[chfleming]

So a complete progress report would entail:

1. The stage within ctmm.select
2. The stage within ctmm.fit
3. An estimate of the % complete within the optimizer.

[xhdong-umd]

I think progress estimates can be very rough. A 20 - 30% step will be helpful already. If the end is 100%, report a 20, 50, 80 somewhere (or even no 80 step if that's difficult).

With ctmm.fit we can report internal progress. Then when ctmm.select is calling ctmm.fit, we can use a different setProgress function parameter, which will rescale ctmm.fit reported progress value into the higher level progress value.

[xhdong-umd]

I may have to create a modal dialog with the model fitting process, and may need to create a separate progress dialog, as closing the shiny progress dialog usually don't stop anything.

[xhdong-umd]

Wait, reporting progress for parallel mode could be difficult, especially with the multiple individuals lapply type parallel... I will check if something can still be done in this mode.