taylor wrote:One question: you are running with the scratch directory DALTON_TMPDIR set to /scratch. I can readily imagine that /scratch is your scratch filesystem, but on most platforms it is more common to have directories like /scratch/taylor underneath which particular runs set up their scratch directories (e.g., something like /scratch/taylor/prop_vibave or similar). The failed test you posted clearly is unable to open a file in the designated scratch directory, so I was just wondering whether this might be a permissions issue with your scratch directory?
I should also add that unless you are likely to be the only person using your cluster, or at least the only person doing quantum chemistry, it is probably unwise to use /scratch as the TMPDIR. This is because sooner or later you are going to run a calculation named "water_VDZ", or similar, and the odds are someone else will want to use the same name, or even accidentally/unintentionally delete the directory if they have enough permissions!
/scratch should have the right permissions for the job to write there. I have just restarted the job and logged into the node, and I can see the files being created in /scratch, so that should not be a problem. Unless they become so big that they use all the /scratch space on the compute node, but I doubt that as there is currently about 804G free.
I (or others) are not going to get problems with more than one person using the same directory. When jobs are allocated nodes to run on, a temporary directory in /scratch on that node is created for each user and everything is run under that. If anything, I probably do not need to set this variable, as I can see that it ended up creating the following directory on the node:
where the second /scratch is (I think) due to the variable I have set.
But I agree, it does look like some sort of permission problem. I have really no idea why right now, but I will try change it to write to a different directory and see what happens.