SEQanswers

SEQanswers (http://seqanswers.com/forums/index.php)
-   Bioinformatics (http://seqanswers.com/forums/forumdisplay.php?f=18)
-   -   Isaac2 genome index creation (http://seqanswers.com/forums/showthread.php?t=61539)

GenoMax 07-21-2015 08:28 AM

Isaac2 genome index creation
 
@semyon: Creating indexes for human genome for isaac2 is not trivial (as I am discovering). Process has been running for 24+ hours on a server and still going.

Making isaac2 indexes available as a download may also be a useful thing for human/mouse genomes.

EDIT: This thread was created by moving several posts that were originally in (http://seqanswers.com/forums/showthread.php?t=61208) but were solely focused on Isaac2 genome index creation issues.

skruglyak 07-21-2015 02:20 PM

Quote:

Originally Posted by GenoMax (Post 177812)
@semyon: Creating indexes for human genome for isaac2 is not trivial (as I am discovering). Process has been running for 24+ hours on a server and still going.

Making isaac2 indexes available as a download may also be a useful thing for human/mouse genomes.

Sorry that it has been a pain. It generally takes us about half a day to generate, but that is hardware dependent. I need to figure out a good place to host the index files. Will try to get human posted in the next few days.

GenoMax 07-21-2015 04:20 PM

Quote:

Originally Posted by skruglyak (Post 177831)
Sorry that it has been a pain. It generally takes us about half a day to generate, but that is hardware dependent. I need to figure out a good place to host the index files. Will try to get human posted in the next few days.

I am not complaining. Just trying to make you aware of how many of us access shared compute resources and how isaac1/2 may come across as a surprise to new users.

Isaac1/2 are written in a way to take over entire hardware from a server/node in question (it is documented, as I remember). Unfortunately this is not something that works well in shared compute environments. It is also hard to make Isaac1/2 behave with job schedulers since the original thread spawns multiple sub-jobs over time.

sklages 07-21-2015 10:47 PM

Quote:

Originally Posted by GenoMax (Post 177835)
Isaac1/2 are written in a way to take over entire hardware from a server/node in question (it is documented, as I remember). Unfortunately this is not something that works well in shared compute environments.

I thought this would be handled by -j in both isaac1/2.
Code:

2015-07-22 08:40:21    [7f15a156c7c0]    Version: iSAAC-02.15.07.16
  -j [ --jobs ] arg (=4)  Maximum number of compute threads to run in parallel


GenoMax 07-22-2015 03:36 AM

Quote:

Originally Posted by sklages (Post 177843)
I thought this would be handled by -j in both isaac1/2.
Code:

2015-07-22 08:40:21    [7f15a156c7c0]    Version: iSAAC-02.15.07.16
  -j [ --jobs ] arg (=4)  Maximum number of compute threads to run in parallel


I will have to verify it again (am just trying to get the index built without overstepping limits set by my job scheduler) but even when I specified -j 1 in an earlier try, the job still spawned as many threads as there were cores on the node.

Have you successfully used the -j option in that manner?

sklages 07-22-2015 03:48 AM

I thought I did for isaac1 .. though I will "re-test" this as well.
I haven't tried isaac2 yet.

Did the format of the index files change from isaac1 to isaac2?
I still have my isaac1 index files ... :-)

GenoMax 07-22-2015 04:05 AM

Quote:

Originally Posted by sklages (Post 177866)
Did the format of the index files change from isaac1 to isaac2?
I still have my isaac1 index files ... :-)

Even if the format hasn't changed I did not build the index last time (used Illumina's). With the assertion that isaac2 can be used for any genome I thought it would be a good idea to get that experience under my belt. Indexing job is still running (2 days, 32 cores, TB RAM). UCSC hg19 from iGenomes.

Illumina must be using all flash storage/newest multi-core xeons etc to get their index built in under a half day.

sklages 07-22-2015 04:22 AM

I started to build a new index for hg19 on 32 cores on a fast (local) RAID.

Using "--jobs 32" on a 48 core machine results in 48 threads. So you are right ...
But this is a bug. Otherwise "--jobs N" does not make any sense.
So let's see how long it takes to build hg19 index ..

UPDATE:
For now I have cancelled building the index.
The average load on that machine raised beyond 52 with peaks over 128 ... I need to investigate first :-)

GenoMax 07-22-2015 04:47 AM

Quote:

Originally Posted by sklages (Post 177873)
Using "--jobs 32" on a 48 core machine results in 48 threads. So you are right ...
But this is a bug. Otherwise "--jobs N" does not make any sense.
So let's see how long it takes to build hg19 index ..

HiSeq Analysis Software (HAS) which isaac was a part of always did this. It seems to pay no attention to -j directive (as I said yesterday HAS documentation does say that it will take over the node).

I suggest watching I/O on your RAID (especially if it is shared with some other users/nodes). HAS/Isaac can do some interesting things to storage too.

EDIT: Just saw your update. That kind of load is "normal". It is only periodic (and partly related to storage). Isaac will also not use all the cores all the time so that part is "normal" too. :D

sklages 07-22-2015 04:57 AM

Quote:

Originally Posted by GenoMax (Post 177875)
HiSeq Analysis Software (HAS) which isaac was a part of always did this. It seems to pay no attention to -j directive (as I said yesterday HAS documentation does say that it will take over the node).

I suggest watching I/O on your RAID (especially if it is shared with some other users/nodes). HAS/Isaac can do some interesting things to storage too.

EDIT: Just saw your update. That kind of load is "normal". It is only periodic (and partly related to storage). Isaac will also not use all the cores all the time so that part is "normal" too. :D

Ha, .. but as you said .. that makes it completely unusable for cluster environments, if you have no control over cpu usage / machine load. Bad people may call that "error by design". ;-)

I have written a ticket on github as I consider this a bug.

If this behaviour will not be changed I will never be able to test the aligner itself :-)

In the past I never used HAS as it was shipped with a very old version of the aligner ..

GenoMax 07-22-2015 05:10 AM

Quote:

Originally Posted by sklages (Post 177876)
Ha, .. but as you said .. that makes it completely unusable for cluster environments, if you have no control over cpu usage / machine load. Bad people may call that "error by design". ;-)

isaac is not meant to be used across a cluster (just on a single node in the cluster).

Quote:

If this behaviour will not be changed I will never be able to test the aligner itself :-)
You have to be creative. Request exclusive access to a node in your scheduler/limit the I/O. It will also involve conversations with your cluster admins so they don't have a heart attack on seeing those kinds of loads on a single server in the cluster.

sklages 07-22-2015 05:38 AM

Quote:

Originally Posted by GenoMax (Post 177877)
isaac is not meant to be used across a cluster (just on a single node in the cluster).

Sure, .. the job will be run on a single node. Nevertheless I need to know roughly about the resources my job will use and I should be able to restrict resources as well, even if it runs on non-cluster server.

Quote:

You have to be creative. Request exclusive access to a node in your scheduler/limit the I/O. It will also involve conversations with your cluster admins so they don't have a heart attack on seeing those kinds of loads on a single server in the cluster.
These are only workarounds ... I do see the problem with the software being designed that way.
IMHO there is no reason to let the user without control over the resources a software uses ... there is always the argument "speed" and "efficiency" .. maybe. But sometimes it is not only speed that is important ..

Roman mentioned on github that at least the aligner may be restricted to a certain number of CPUs, but is not recommended for the sake of "efficiency of processing". Again, "efficiency" does not always mean "speed of single job". But that's just my 2p ;-)

GenoMax 07-22-2015 05:48 AM

I am with you all the way. Core infrastructure providers are left to fend for this sort of thing, which the end-users don't appreciate/care about.

This was one of the reasons I started this conversation so @semyon can take the real world observations back for internal discussion/improvements, especially if they want more users to use their software.

craczy 07-22-2015 10:06 AM

Quote:

Originally Posted by sklages (Post 177878)
Sure, .. the job will be run on a single node. Nevertheless I need to know roughly about the resources my job will use and I should be able to restrict resources as well, even if it runs on non-cluster server.

These are only workarounds ... I do see the problem with the software being designed that way.
IMHO there is no reason to let the user without control over the resources a software uses ... there is always the argument "speed" and "efficiency" .. maybe. But sometimes it is not only speed that is important ..

Roman mentioned on github that at least the aligner may be restricted to a certain number of CPUs, but is not recommended for the sake of "efficiency of processing". Again, "efficiency" does not always mean "speed of single job". But that's just my 2p ;-)

First of all sorry for the confusion around the meaning of the "-j" option across the different tools, and about the inconvenience that you experienced. To clarify:

- isaac-align: this is a single node and single process application and the "-j" option controls the maximum number of compute threads, which would effectively enable the user to control the CPU load on the node (the recommendation is to let the application figure out and use the available resources). As the user can also control the amount of memory used by the process, this should work fairly well in a cluster environment. If it causes trouble with your job scheduler, we would really like to better understand the issue so that we can effectively resolve it (it is a really important feature!).

- isaac-sort-reference: this is a multiprocess application. It can be distributed on multiple nodes but that requires explicit specification of the qrsh (or other) command line. The option "-j " is for the number of parallel operations (processes as opposed to threads). The recommendation is to execute it on a single node and to use "-j 1". At the moment, this application does not provide any control to the user for CPU and memory usage. Hopefully this inconvenience is mitigated by the fact that it need to run at most once per reference. If there really is a need to restrict resource usage, doing it with modern solutions like virtualization might be a good option.

Regarding the time and resources required to run "isaac-sort-reference", a server with 150GB memory is required. A dual CPU (mid-range or better) is recommended. It is also useful to have a reasonably good file system as the operation does quite a bit of IOs. With a mid-range server it should take about half a day. Again the "-j 1" option is important on a single node, otherwise the processes will compete for CPU, memory, swap, etc. If it takes much longer than that, it might be worth checking that the node is not stuck on IO waits or busy swapping.

Thanks a lot for your feedback on github!

Come

sklages 07-22-2015 11:42 AM

Thanks for the clarification ... good news on isaac-align ;-)

And as for isaac-sort-reference I still do not think that this is the right way; but you are probably right, as we only run it once for each reference, it might not be too much of a problem for an experienced user for the moment. Nevertheless you should consider changing or extending this behavior in that, that a user is able to restrict resources on a single node.
But format of index files has not changed from version 1 to 2?

craczy 07-22-2015 12:12 PM

Quote:

Originally Posted by sklages (Post 177917)
But format of index files has not changed from version 1 to 2?

Unfortunately it has. The index contains extra information about the reference and with isaac2 that information has changed. Specifically, in the isaac2 index we are keeping track for each position in the reference genome if there are similar sequences elsewhere in the reference.

GenoMax 07-23-2015 06:23 AM

I did not specify a value for seed-length so the process is creating all possible combinations [--annotation-seed-lengths arg (=16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80]. It looks like the end may be in sight today for the process I am running since the files for 80 are being made now.

@sven: Expect a multi-day turnaround.

sklages 07-23-2015 06:30 AM

I haven't neither .. should use 32.
But .. I am optmistic :-)

GenoMax 07-23-2015 04:18 PM

@Semyon/Come: Can one of you confirm if the following files represent the correct isaac2 index for hg19 genome? My isaac-sort-reference job appeared to have finished (no errors) but these are the only files I see in the top level directory (Temp directory is still there with files within)
Code:

1.1G 2uniqueness.16bpb.gz
 47G kmer-positions-32-0.dat
 50K sorted-reference.xml


sklages 07-23-2015 09:52 PM

Quote:

Originally Posted by sklages (Post 177973)
OK .. index creation is running for hg19 ... I'll report back tomorrow.

Well, .. for now .. the server crashed overnight, just three hours ago ..
We now have to investigate what event caused this crash. Maybe it is just "Murphy's Law" .. we'll see.


All times are GMT -8. The time now is 02:49 AM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2020, vBulletin Solutions, Inc.