Hello everyone,
First of all thanks for such amazing tools.
Now to my issue, I am currently trying to deploy my application using CapRover and Trame. The example cone application works perfectly, but I can’t seem to make my own application work.
The build goes well without error, the server launches, but I get a page saying “Session did not start before timeout”.
Now, to find why, I did some digging and looked into the logs of my caprover docker. It seems like my code crashes because it can’t find a file that I am loading through pyvista.
When I run it local it works, so the file is well placed. It seems like my server loses track of the file?
To be frank, I am new to all this and did not modify the cone example to take into account that my own project has folders with files.
I believe there is something I have to change in configuration, but I can not figure out what…
After a bit of tinkering I think I fixed this error. I basically changed the path of my app.py, and added persistent folders (not sure if it does anything).
I do come along another error though. I add to modify the dockerfile to install some libraries (RUN apt-get update && apt-get install ffmpeg libsm6 libxext6 -y).
But now, I come across the fact that the app directly crashes (connection closed). I get from the log
/deploy/server/venv/lib/python3.9/site-packages/pyvista/plotting/plotter.py:149: UserWarning:
This system does not appear to be running an xserver.
PyVista will likely segfault when rendering.
Try starting a virtual frame buffer with xvfb, or using
``pyvista.start_xvfb()``
warnings.warn(
App running at:
- Local: http://0.0.0.0:9500/
- Network: http://10.0.1.69:9500/
Note that for multi-users you need to use and configure a launcher.
Installing the needed package seems to fix it, but it seems like this method is not meant to be used, since the template never mention any of this. I do get a very slow responding application when rendered server side. Clicking the button to have it render client side helps, but still generate some erratic camera movement, probably due to the link between the server side and client side.
Is there a way to have the application only be client side for the GUI part, and have the server only manage back-end things, like different field changes (as an example : Control Scalar Array — PyVista Tutorial)?
Welcome to the community and the Docker/web world.
So it seems you fixed the missing file by mounting a directory of your host into your docker, which is great.
The next thing you are hitting is the rendering of VTK within a headless system.
For that you will need either a osmesa or egl (for GPU) version of vtk. But PyVista has regular VTK as a dependency which means, you will have to uninstall vtk and then install its osmesa version
Ah I see, would that explain the weird/poor performances? I do notice that the example with cone-app does not use pyvista even. But if you tell me that tinkering with the vtk version helps, that would be great and avoid me to rewrite the whole app!
Currently for my setup director, I have as follow:
apps.yml (untouched. maybe too many questions, but I still wonder where is this script getting its {environment variables} from? I never specified them and it still seems to work?) :
requirements : (modified to add pv and scipy (I believe numpy is redundant but why not!))
trame
trame-vtk
trame-vuetify
numpy
pyvista
scipy
So I should find a way to uninstall vtk once pyvista is installed, and install the correct build?
Is there a way to use the same template as the app-cone, but to use the initialize.sh instead? (To which I would just add a 3rd and 4th line to pip uninstall and then pip install the correct vtk right?)
Just be aware that remote rendering will be slow due to osmesa using only your cpu. If you can, use VtkLocalView.
Ideally if you have a GPU (Nvidia) and you allow your docker to access it, if you were to install a vtk-egl, it will be as fast as running the app on your system without docker.
We don’t have an egl build of vtk but you could build it yourself. (Or use ParaView EGL to provide that vtk for you.)
Sorry for the last answer, I have been busy playing around Trame, what a great tool!
Thank you for the input, it actually works with your solution. Since my server only has a CPU, the performance are pretty bad but its a start.
Using the local rendering option, the visualisation is more responsive, but some artefacts tend to appear when the server changes the rendering view (adding mesh, modifying scalar, etc.).
In any case, thanks again for your help, I will look deeper into the framework to see if I can correct for the various behaviours I just mentionned!