3
$\begingroup$

Snakemake is not really designed to store temporary files to local disk, but in the documentation, they suggest a workaround using "shadow rules".

The problem I have is, that our front node does not have /scratch/.. directory and therefore snakemake complains right away

snakemake my_result.tsv -p --jobs 10 --shadow-prefix /scratch/$USER --cluster "qsub "
   ...
   PermissionError: [Errno 13] Permission denied: '/scratch'

Every single computational node does have the directory, only the frontend does not. Is there any easy workaround?

--- edit ---

I will try to clarify where I think is the problem.

The head node does not have anything mounted to /scratch, I think that's why I am getting that error. I sort of expected that snakemake will attempt do create the shadow environments for individual executed jobs, because if it does, everything would be fine. All the computing nodes do have their local disks mounted to /scratch.

Of course, I could use a different shadow directory, but all the directories that are mounted both at the front-end and computing nodes are NOT local disks of individual nodes, which would cause more network traveling of the temporary data.

--- edit 2 ---

Thanks @Chris_Rands for finding the relevant lines. I opened an Issue on Snakemake GitHub. Once I will know more, I will get back with the answer here.

Improve this question
$\endgroup$
7
  • $\begingroup$ Not familiar with snakemake but, can you run the snakemake script from a node & reserve minimal resources for it as to not clog up your cluster? I suppose you might not be able to qsub while on a node. $\endgroup$
    – Pallie
    Jul 28, 2020 at 14:59
  • $\begingroup$ Yeah, jobs can be submitted only from the frontend. $\endgroup$
    – Kamil S Jaron
    Jul 28, 2020 at 16:12
  • $\begingroup$ can you set --shadow-prefix to a different directory path? $\endgroup$
    – Chris_Rands
    Jul 28, 2020 at 16:40
  • 1
    $\begingroup$ @Chris_Rands any other directory than /scratch/... is not a local directory on the computing nodes. If I pick a directory that is actually on the shared storage, all the temporary files will have to travel through networking. That's what I wanted to avoid with the shadow prefix. $\endgroup$
    – Kamil S Jaron
    Jul 28, 2020 at 20:37
  • 1
    $\begingroup$ @KamilSJaron Ok, understood- they create the dir here github.com/snakemake/snakemake/blob/… but probably it's not needed until here github.com/snakemake/snakemake/blob/… $\endgroup$
    – Chris_Rands
    Jul 29, 2020 at 9:59

1 Answer 1

Reset to default
0
$\begingroup$

What is happening is your Admin is not allowing you access to /scratch ... which is undertandable. Essentially you are attempting to access the headnode /scratch. If every user on the cluster had access, it would be a bit chaotic.

I am surprised by the error, not that I would use Snakemake I'd code it, because you would expect a data pipeline tool as established as Snakemake to have a solution to working on a cluster. What you are describing is a standard cluster set-up between headnode and 'sub-node' (the technical term is slavenode, but I hate that term). The headnode is mirrored across the cluster, hence the error. Once you submit via qsub the mirror will 'display' the headnode layout on the subnode.

  • You could ask your admin for permission to /scratch, this is root privilege. It is a bit unlikely they will say 'yes' but its worth a try.
  • Otherwise what about a virtual environment? When Perl suffers this problem I simply use 'perlbrew', anaconda has very nice virtual environments that are easy to setup
  • @Chris_Rand points out piping to a different output.
  • I bet there is a solution in '.profile' and thats how I solved comparable problems in the past.
  • Of course Snakemake do a Q&A interaction on Overflow SE (but please come back here!) ... they must know the work around.

Frankly I am astonished because the whole point of Snakemake, is the ease of constructing a data pipeline and data pipelines are processed on clusters, thus this error seems to up-end it, but who am I?

Improve this answer
$\endgroup$
6
  • $\begingroup$ Thanks, @Michael for the answer, but I don't think it solves really my problem. The /scratch directory does not exist on the head node at all and all the sub-nodes have thier local disks mapped there, to /scrach. I think the reason I am getting the errors is because snakemake is trying to verify that the directory exist at the frontend. That's quite strange to me, I would have guessed that the shadow directory will be created for every job individually when it's executed on the sub-node. I am not sure if I am clear. $\endgroup$
    – Kamil S Jaron
    Jul 28, 2020 at 20:50
  • $\begingroup$ The issue is that the headnode is mirrored across the cluster, thus you have a copy of a file on the headnode - this file is not physically present on all 'subnodes' (slavenodes). Thus, because /scratch and permissions therein is not on the headnode this is present as soon as you run the queue 'qsub' or whatever. $\endgroup$
    – M__ ♦
    Jul 28, 2020 at 20:55
  • $\begingroup$ If you physically logged into the subnode ('slavenode') there would be a /scratch (if you had permission to access it) and it would work. The thing is you access the subnode ('slavenode') via the mirrored queue. $\endgroup$
    – M__ ♦
    Jul 28, 2020 at 20:56
  • $\begingroup$ Do you say that If I do qsub <appropriate parameters> 'ls /scratch' it will complain? Because I am pretty sure it would work. $\endgroup$
    – Kamil S Jaron
    Jul 28, 2020 at 21:00
  • $\begingroup$ I am not sure if I follow the mirroring, but when I write non-snakemake jobs, I am using /scratch for temporary files all the time. $\endgroup$
    – Kamil S Jaron
    Jul 28, 2020 at 21:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.