phockett / open-photoionization-docker-stacks Goto Github PK

For test files currently getting lots of errors in standard error output, although final results seem fine. This is for UB22 Gfortran 9 builds.

Along lines of:

[3dfa5a6df0a1:00940] Read -1, expected 6560, errno = 1
[3dfa5a6df0a1:00937] Read -1, expected 6560, errno = 1
[3dfa5a6df0a1:00924] Read -1, expected 6544, errno = 1
[3dfa5a6df0a1:00926] Read -1, expected 6552, errno = 1
[3dfa5a6df0a1:00935] Read -1, expected 6560, errno = 1
[3dfa5a6df0a1:00929] Read -1, expected 6560, errno = 1
[3dfa5a6df0a1:00925] Read -1, expected 6544, errno = 1
[3dfa5a6df0a1:00924] Read -1, expected 13112, errno = 1
[3dfa5a6df0a1:00924] Read -1, expected 26240, errno = 1
[3dfa5a6df0a1:00926] Read -1, expected 13120, errno = 1
[3dfa5a6df0a1:00935] Read -1, expected 13120, errno = 1
[3dfa5a6df0a1:00959] Read -1, expected 6560, errno = 1
[3dfa5a6df0a1:00959] Read -1, expected 26200, errno = 1
[3dfa5a6df0a1:00929] Read -1, expected 13120, errno = 1
[3dfa5a6df0a1:00921] Read -1, expected 13088, errno = 1
[3dfa5a6df0a1:00966] Read -1, expected 6544, errno = 1

Encoding issue with test files, or something else?

May need to review/modify/update, and consolidate settings, especially for single-user remote use. (Probably should use Jupyter Hub!)

Current example: https://github.com/phockett/open-photoionization-docker-stacks/blob/main/luna/jupyterSettings.sh

Have had some container crashes with Tornado/HTTP issues.

Maybe better after modifying server config with:

c.ServerApp.allow_origin = '*'
c.ServerApp.allow_remote_access = True

Also note that in logs: 'ip' has moved from NotebookApp to ServerApp. This config will be passed to ServerApp. Be sure to update your config before our next release.

Notes to self: best methods for running computational containers as services?

• Spin up relevant containers on file system changes, requires a management container (e.g. https://github.com/coppit/docker-inotify-command plus docker.socks access). Main advantage is the ability to spin up multiple instances here (see also docker swarm for multi-machine usage, and sysbox for safer docker-from-docker methods).
• Keep containers running, with file system watchers per container, e.g. inotify, see also autonotebook. Note that Windows hosts might have issues with inotify.
• Keep containers running, trigger processes via network (cf. epsman). Requires management routines of some kind, but more secure than docker.socks access. Some options/discussion here (SSH and REST), latter uses flask-shell2http. For interactive cases, existing epsman code should work here, and container should simplify config.