FAQ

FRESHS uses console color markups, which might not display in your terminal. Try looking at your files with less -R instead of less.

In the FRESHS code, “ffs” refers to the direct FFS algortihm, and “perm_ffs” refers to an optimisation of this (Flat Histogram Pruned Enriched Rosenbluth Method, or flatPERM) which aims to improve the evenness of sampling. The only reason to retain the original “algorithm = ffs” choice is that “perm_ffs” increases the calculation by the server, and also the server-DB communication load, which might be a problem for runs having very large DBs.

SPRES is appropriate for full nonequilibrium calculations, where ffs and perm_ffs are only appropriate for nonequilibrium systems which have time-stationary behaviour. Needless to say, SPRES calculations are typically more expensive.

The performance can depend on node-to-node communication through the interconnect as for most codes, but also on the tolerance of the filesystem to multiple concurrent writes, as the client processes each have independent filesystem access.

Some tips:

• Most clusters have node-local filesystems, often on SSD, which are available to users as a scratch space. Try using this, and then copying your results onto the head filesystem at the end of the run.

• See if you can farm the database out to a different filesystem (eg NFS if LUSTRE is giving you problems, GPFS if NFS hits a wall) if your cluster has multiple disk spaces available to users. There are reports on the internet that SQL and NFS don't mix, but no-one has had any trouble with the SQLite3 implementation currently present in FRESHS.

• If opening large numbers of files is giving you problems, then try storing config information directly in the database. Conversely, if DB access by the server is a bottleneck, then try only storing filenames and leaving the config files as separate entities on the cluster filesystem.

• Tuning cluster filesystems for optimal performance is not as easy as it should be. If your cluster has never been under heavy filesystem load before, it is quite possible that settings like that max number of NFS threads are still at needlessly low default values. Have a word with your system administrators.

• If the comms load isn't too heavy (compared with the server database access load), you could try running the server on your desktop machine and the clients on the cluster.

• For small database sizes, it might be interesting to try and use a RAM disk. This is not documented as yet, but users have indicated that it was worthwhile for them.