Remote Monitoring of MATLAB during a month long process

I have a MATLAB data logging program that is runs for about a month. What I'd like to do is be able to see the current status of the process from a remote computer (i.e. home). I've looked into the TCP/IP but I don't want to have to stay connected the entire time, just every once in a while check in. Is there a way to do this?

Thanks, Ryan

[Sven]

What would you *see* if you were connected to the computer running this program?

If it's just text being printed to the screen, have you considered putting that text to somewhere else (such as a file on that computer, or even have MATLAB periodically send you a twitter update)?

[Ryan]

If I was connected to this computer I would see a gui that has some graphs of the data collected as well as the current state of the data collecting device ('sampling','waiting',etc). I'd like to able to see just that. I don't mind having to send just the raw data and reconstruct the graphs on the receiving end.

[Daniel Shub]

I would be pretty worried about running a MATLAB application for a month.

Answer 1

[Walter Roberson]

If MATLAB is running on an MS Windows system, then use VNC or Remote Desktop.

If MATLAB is running on a Linux system, then you can use a combination of a VNC server and "screen" to get it to work. You have to start the process within screen for this to function, I understand.

If MATLAB is running on OS-X and uses graphics, I am not presently aware of any mechanism that will work, as OS-X uses a variety of graphics interfaces that bypass X11. If command-line only then "screen" would probably work.

You could also consider using "diary" so that MATLAB writes the console output to a file. It does not flush the buffer per line, so it can be hours (days) after something is emitted and before it makes it to the diary file, but the technique can be valuable.

IMHO, what MATLAB really needs is a way to interrupt something running, examine variables, and then resume exactly where it left off. This is a common operating-system supported feature for compiled languages, and although MATLAB is not a compiled language, the lack of the feature is discouraging. Heck, even LISP has had it for over 30 years.

[Jason Ross]

On a Mac you can set up VNC or you can use Apple's Remote Desktop access. Note that it's not the same thing as Microsoft's Remote Access and only works from Mac to Mac.

Answer 2

[Jason Ross]

A cautionary note on anything running for 30 days -- you are putting a lot of eggs in one basket and you should really consider coming up with a method to interrupt and resume the process, as there are many things that can happen to a machine in 30 days and it's a real bummer when the power goes out or the machine crashes 26 days into the experiment and you need to start from the beginning.

You should also consider memory use (make sure it's not monotonically increasing), how big log files will grow (so you don't run out of disk space), where the log files will go (check the partition sizes to make sure they are adequate), etc.

[Ryan]

Thanks for the words of wisdom. That is definitely a major reason in my wanting to be able to monitor what is going on remotely.

[Walter Roberson]

A computational "checkpoint" system is a must for this kind of long running program. Each checkpoint file should be closed after it is written: if you hold it open, then it can get corrupted as the system goes down.

As data collection was mentioned, I take it that all data collected should be written to a log so that it can be read back in. You don't want to keep any one log open for too long, though, as there is always the risk of losing whatever is in the log. That risk is reduced if you used a journaling filesystem (I believe the standard MS Windows filesystem is journaled).

Checkpoint files: follow the "Rule of 3" that applies to backups. That is, always use at least 3 files: one that you are writing the current backup to, one in case the system crashed while writing the backup, and one because you forgot to put on the write-protect tab when you went to recover from the second dataset! (Yes, this is the voice of experience; learn from my mistakes!)

Graphs: if you aren't generating them frequently, then print or saveas or export_fig them to files. You can view the saved files.

Build your checkpoint + recovery system in from the very beginning, if possible. It will probably look like mini command language. It is far easier to build a graphics interface that formats a string and calls an internal command language, than it is to build a command language that stuffs variables into GUI elements and triggers callbacks to "replay" a session.