open-discussion > Changing location for working files
Showing 1-3 of 3 posts
Display:
Results per page:
May 13, 2026  01:05 PM | Paul Wright - University College London
Changing location for working files

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.


 

May 15, 2026  01:05 PM | Christopher Schwarz - Mayo Clinic
RE: Changing location for working files

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


 

  Edited (May 15, 2026  04:05 PM)
May 19, 2026  09:05 AM | Paul Wright - University College London
RE: Changing location for working files

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:



scratch_dir=/scratch0/${USER}/mri_reface_${JOB_ID}.${SGE_TASK_ID}

 

As you say, that means I have multiple copies of the MCR cache, even if they are short-lived. I agree it's a balancing act!