1. ssh -o TCPKeepAlive=yes mark@localhost
 
or
 
2. 
Remember that 
ServerAliveInterval
is limited by
ServerAliveCountMax
and that ServerAliveCountMax is set to 3 by default!
That is, if you set ServerAliveInterval to 60 and ServerAliveCountMax is left to default value (3), after the client has sent 3 keep alive packets it will disconnect. That makes 60 x 3 = 180 seconds.
So if you want more time away, you set ServerAliveInterval to 60 and ServerAliveCountMax to the numer you want (for example: 100). The client will send one keep alive packet every 0 seconds for 100 times or, if you prefer, 100 keep alive packets, one every 60 seconds.  
You set this up in your $HOME/.ssh/config file.
Most of these options are explained in man ssh_config.
Thanks a lot to Cam for pointing us all in the right direction!!!!

java.io.IOException: no locks available

마운트시 -o nolock 옵션 적용

$> mount -t nfs -o nolock

fstab에 적용

$> vi /etc/fstab

XXX:/storageDir /local nfs nolock 0 0

---------------------------------------------------------

<rocks clusters>

nfs 파일 시스템에서 파일 lock 이 되지 않을 때
아래와 같이 수정하고 nfs 데몬 재시작, nfslock 데몬 재시작
(예상 관련 데몬: portmap, autofs)

[system]$ cat /etc/auto.home
user01  -fstype=nfs,nolock 111.111.111.111:/data/home/user01

Picard를 이용하여 MarkDuplicates 를 수행하는 데 있어서,

"Value was put into PairIntoMap more than once" 라는 에러메시지가 발생하고 프로세스가 죽는 경우 입니다.

이 문제에 대해 해결할 수 있는 방안을 찾은 것 같습니다.

이 문제는 BAM파일 내의 리드 정보가 first read와 second read 사이의 flag 및 맵핑 위치 정보가 서로 맞지 않아 발생되는 오류로 확인하였습니다.

이것은 앞서 시도한 BWA -A 옵션을 줌으로써 mate에 대한 정보를 보정해주지 않는 것이 문제를 일으킨것 같습니다.

따라서 BWA -A 을 수행한 후에는

samtools fixmate input.bam output.bam

을 수행한 다음 이 output.bam 을 이용해 MarkDuplicates 를 수행하면 됩니다.
 

또 다른 경우로 밤파일들을 머지 한 데이터를 사용할 경우 머지한 밤파일내에 리드아이디가 중복해서 존재하게 되면 또한 위와 같은 에러가 발생합니다.
이러한 경우는 머지를 할때 samtools merge 를 사용할 경우입니다.
Picard의 MergeSamFiles.jar 를 이용하면 개발 bam들이 동일한 RG ID를 갖고 있으면, 자동으로 RG_ID 뒤에  ".1" 과 같이 숫자 인덱스를 만들어주게 됩니다. 보통 bioscope 등을 이용하여 맵핑한 bam 파일들은 RG_ID 가 default라는 명칭으로 되어 있습니다.

따라서 정리하면 위와 같은 에러메시지가 발생할 경우

1. "Value was put into PairIntoMap more than once"  와 함께 나타나는 리드 아이디가 중복해서 존재하는지 확인한다.
2. 중복해서 존재할 경우에는 merge 하는 툴을 Picard를 이용한다.
3. 중복해서 존재하지 않을 경우에는 samtools fixmate 를 실행한 후 재분석한다.


이상//

bwa 를 이용한 pairing 에서 감당되지 않는 많은 시간이 소요되는 현상(4~5일 경과까지 지켜봄)이 나타납니다.

자세히 현상을 확인해본 결과

데이터 자체가 Pair-end 의 두 쌍의 데이터가 현저하게 떨어져 (insert size) 맵핑이 될때 문제가 발생되는 것으로 보입니다.

(아마 이것은 로우 데이터 자체에 문제가 있는 경우가 아닌가 생각됩니다.)

자세히 보면,

bwa 는 한쪽 end 가 unmapped 된 경우 이를 사용자가 넣은 max insert size 로 보정하는 단계가 있는 것으로 확인됩니다.

이로써 전체 데이터의 mapping rate, properly paired rate을 향상 시키고 잇는 것으로 확인됩니다.

간단하게 테스트 결과

read1, read2 에 각각 25만개의 리드가 있을 경우 chr22 레퍼런스에 맵핑하여 확인결과

1. max insert size 로 보정하는 단계를 스킵 (-A 옵션) 시킨경우

==> 198999 mapped (3.98%), 18295 properly paired (0.37%) 로 나타나지만,

2. max insert size (500) 로 보정할 경우

==> 207601 mapped (4.15%), 37214 properly paired (0.74%) 로 나타났습니다.

이 단계를 스킵하게 되면 전체적인 맵핑 통계수치가 낮게 나타나지만 속도 측면에서 큰 효과를 볼 수 있습니다.

특히 이 경우 처럼 Pair-end 의 두 쌍의 데이터가 현저하게 떨어져 맵핑이 된 상태의 데이터는 이 단계를 스킵으로 결과가 떨어지지만, 이 단계를 거치게 되면 일주일(?) 이상 소요됩니다.

[Rocks-Discuss]Cannot write to user home on compute node

• Previous message: [Rocks-Discuss]Cannot write to user home on compute node
• Next message: [Rocks-Discuss]IRC channel?
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Thu, 16 Feb 2006, Chuming Chen wrote:

Add no_root_squash to the options in /etc/exports and then restart the NFS 
services on the frontend.

Tim

Tim Carlson
Voice: (509) 376 3423
Email: Tim.Carlson at pnl.gov
Pacific Northwest National Laboratory
HPCaNS: High Performance Computing and Networking Services

> Hi,
>
> On the compute node, as the user, I can create file in my home. But as
> root, I failed. What would be wrong here?
>
> [chen at compute-0-0 ~]$ pwd
> /home/chen
> [chen at compute-0-0 ~]$ ls -l test
> ls: test: No such file or directory
> [chen at compute-0-0 ~]$ touch test
> [chen at compute-0-0 ~]$ ls -l test
> -rw-rw-r--  1 chen chen 0 Feb 16 13:50 test
>
> [root at compute-0-0 chen]# pwd
> /home/chen
> [root at compute-0-0 chen]# touch test
> touch: cannot touch `test': Permission denied
>
> Thanks a lot.
>
> Chuming Chen
>