Improve default directory locations

Issue #469 new
Ian Hinder created an issue

It is usually desirable to set the user's source base directory to be in their home directory. On many systems, this can be inferred from the user name; e.g. /home/@USER@. However, on systems with very large numbers of users, the home directory is sometimes not predictable in this way. For example, /home1/00915/@USER@ (this is on LoneStar), where the numbers are different for different users. This also happens on Kraken (see ticket #382). Having to specify these details manually for each machine that you want to use is an extra step in configuring SimFactory which we would like to avoid.

Option 1: Provide a @HOME@ definition which is determined automatically from the user's home directory.

This would be possible, but it only solves the problem for the home directory. On some systems (again, LoneStar and Kraken), the home directory might not be large enough to use as a source base directory, and instead you might want to use the "work" directory instead (this is the current simfactory setting for LoneStar). This directory also suffers from the same unpredictable numbering problems. As the home directory is available in the HOME environment variable, the work directory is available in the WORK environment variable.

Option 2: Provide a general method for accessing environment variables and storing them in definitions. For example, you could write @ENV(HOME)@ or @ENV(WORK)@. This requires the environment to have been correctly set up (for remote operation, this requires a login shell, but I think we have that already). In fact it looks like there is preliminary code in simsubs.py, but it is incomplete and is not called from anywhere.

I would favour option 2. Thoughts?

Keyword:

Comments (2)

  1. Erik Schnetter
    • removed comment

    In some places one can write $HOME or $WORK in the directories; since these strings are usually passed to a shell, they will be expanded. I used to use this in some places -- I don't know whether this use is still there.

    I favour option 2 as well. This seems to be a reasonable solution to a long-standing problem.

  2. Roland Haas

    Option 2, expanding ENV variables in simfactory, exists. It does however not solve this problem due to not working when simfactory’s --remote option is used or even to set up the target directory for a sim sync command which needs to know the “00915” part on the user’s laptop (to make it part of an rsync command line) where $HOME etc. the laptop’s and not the cluster’s.

  3. Log in to comment