After data addition/change/removal, you have to regenerate the index cache.
To do so, simply delete the index.fb file in the SEAScope workspace (or at the location you specified in the configuration file) and restart SEAScope to regenerate an index file.
SEAScope requires direct access to a real GPU, not an emulated one – which is what most hypervisors (Qemu, VirtualBox, Parallel, etc..) provide by default.
The only way to run SEAScope in a VM with good performance is to configure PCI-passthrough and pass a physical GPU to the virtual machine (which is only possible on Windows Server 2016 with Hyper-V 2016 and ... on Linux). So it is strongly discouraged to run SEAScope in a VM at the moment and no support will be provided for this use case.
In short: it mostly depends on how much RAM you have.
SEAScope is a hungry beast: it consumes more RAM everytime new data (i.e.
data that were not already present in memory) are loaded for
visualisation purposes and only releases this memory when the application
shuts down.
So it is possible to saturate your RAM by loading too much data, when you
visualise high-resolution data, many variables or many datetimes without
restarting SEAScope.
You can somehow circumvent this limitation by extending the size of the
swap on your system: it will virtually have more memory available so
SEAScope should be able to load more data but its performance might
suffer from the transfers between disk and RAM caused by the swap
mechanism.
This lack of memory management is a major problem in the current version
and fixing this issue is our top priority for the next release.
The index still contains the old path of your data, so SEAScope cannot load them: you have to regenerate the index cache.
To do so, simply delete the index.fb file in the SEAScope workspace (or at the location you specified in the configuration file) and restart SEAScope to regenerate an index file.
SEAScope relies on the MESA library to retrieve the version of OpenGL supported by your system.
Some drivers report a wrong version number which leads to an error during SEAScope startup: it refuses to start because the erroneous reported version is lower than the one it requires.
To bypass this issue you can define the
MESA_GL_VERSION_OVERRIDE and
MESA_GLSL_VERSION_OVERRIDE environment variables to change
the OpenGL version publicized by the driver.
Using OpenGL version 3.3 is a sensible choice. For example, in bash, you can use:
export MESA_GL_VERSION_OVERRIDE=3.3
export MESA_GLSL_VERSION_OVERRIDE=330
We recommend that SEAScope be placed in /Applications or ~/Applications.
But it normally works fine if placed somewhere else on your computer.
See "How to open an app that hasn’t been notarized or is from an unidentified developer" section of Safely open apps on your Mac.
Maybe your environment (or a binary package) was built on a system which uses an encoding that is not compatible with yours.
This is not strictly related to SEAScope, but we encountered this issue on a chinese Windows 10 system while running a conda environment that we built on a french windows 10 machine. The solution might be obvious to Windows users but we don't use this OS on an eveyday-basis so it took us several tries before we found a workaround.
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: 65001
In order for this environment to work, the workaround we used consisted
in switching the system encoding to english and unticking the
"Beta: Use Unicode UTF-8 for worldwide language support" checkbox.
In order to get to the encoding configuration dialog:
The polygon used to extract data might be too wide or too close to the boundary between the globe and space. Try rotating the globe to place the polygon at the center of the screen before extracting data.
In some cases SEAScope cannot completely geolocate the bounding box of the extraction polygon and can only provide incomplete inputs to the get_lonlat method. This is a known issue, more information available on the forum