sasmodels dll cache directory confusion

[ibressler]

When loading sasmodels as python module (as in McSAS3) from a SasView installed elsewhere in the system, it searches built models in $HOME/.sasmodels/compiled_models ($HOME denoting the OS agnostic user directory here) whereas SasView, once started and the No OpenCL tests are run, it stores built models in $HOME/.sasview/compiled_models.

This seems like the sasmodels module is using an outdated path here - assuming the location in $HOME/.sasview is new behavior.

I am not entirely sure if this is intended or if it was just forgotten to update. Suppose, this is related to #1560 and #1534.

Note: Using the models built by SasView previously is more stable/reliable than figuring out how to make/built models from an external app. Therefore, the expected behavior of sasmodels is to use the binary models where SasView stored them recently, no?

[smk78]

Also see #1904

[pkienzle]

Behaving as intended but agree that it is confusing.

Nominally sasmodels is an independent package from sasview, so it would be a bit strange for it to write within the sasview configuration files. This is especially the case since sasview is distributed as an independent app with its own python environment and version of sasmodels. It is easy to imagine collisions where, for example, a version of sasmodels used in mantid which is different from that used in sasview. Figuring out why something is not working as expected on this user's machine will be challenging.

At least one version of sasmodels tagged files with a hash to avoid collisions (I have the hash tagged versions in my .sasmodels directory), but I'm not sure if it is in the current main. This solves the collision problem since the hash is computed from the generated source but it introduces other problems.

[Edit]: I verified that master has hashes on the .so files which may be enough to remove the version conflicts.

[pkienzle]

We could set up a cache for sasmodels using appdirs.user_cache_dir.

We are already doing this via pyopencl (see here). On my mac I see sasmodels kernels in ~/Library/Cache/pyopencl/…. Presumably something similar is happening for the cached CUDA files, though I didn't trace the code to see what it is using.

We might consider combining the caches for dll, opencl and cuda in the same place so we can tell users to clear the cache.

I don't know if the OS has any support for cleaning out the cache from time to time. We may want to remove entries when the cache gets big. This is especially the case if we start generating models on the fly with different levels of gaussian integration, or with combinations of structure and form factor in the same model file for local monodisperse structure factor approximations.