I'm running mri_reface on a cluster via Sun Grid Engine. I want to use scratch space for working files instead of the /tmp/$tempdir and ~/.mcrCache9.12 cache directories mri_reface uses by default.
You can achieve this by setting environment variables to something like:
TMPDIR="${scratch_dir}/tmp"
MCR_CACHE_ROOT="${scratch_dir}/mcr_cache"
I am running using singularity, so I set these using the `--env` argument in the `singularity run` command.
It's probably not a big deal, since mri_reface does not write much to /tmp, and I think it deletes it afterwards, and the MCR cache is about 350 MB, not enough to threaten even the small quota my home directory gets on our server. I have done any rigorous testing to see if it improves speed on my cluster. I thought I'd share in case it saves anyone else a little time.
If your $MCR_CACHE_ROOT on $scratch_dir is shared across multiple jobs, you may run into difficulties where two jobs start at roughly the same time, causing one to delete the cache that the other just unpacked. Ideally you would seed time or jobID into the scratch_dir name to avoid collisions, but 350MB x n jobs may be more scratch than your node has available. It's an unfortunately tricky balance inherent to deployed matlab applications.
Our nodes don't have enough scratch to avoid overlaps, so we have this in a wrapper script:
while ! stat "$MCR_CACHE_ROOT" > /dev/null 2>&1;
do
echo "Waiting for $MCR_CACHE_ROOT to be
accessible..."
sleep 1 # Wait 1 second before checking
again
done
Originally posted by Christopher Schwarz:
If your $MCR_CACHE_ROOT on $scratch_dir is shared across multiple jobs, you may run into difficulties where two jobs start at roughly the same time, causing one to delete the cache that the other just unpacked. Ideally you would seed time or jobID into the scratch_dir name to avoid collisions, but 350MB x n jobs may be more scratch than your node has available. It's an unfortunately tricky balance inherent to deployed matlab applications.
Yes, I currently have:
