# Antibody Homology Modeling - Antibody vs. Antibody_legacy

5 posts / 0 new
Antibody Homology Modeling - Antibody vs. Antibody_legacy
#1

Hello Rosetta users,

I have a few questions with respect to antibody modelling in Rosetta, specifically I am trying to replicate the worked example in the recently published Nature Protocols article “Modeling and docking of antibody structures with Rosetta” (doi:10.1038/nprot.2016.180).

I am having a problem at the first stage in the process – Antibody homology modelling. In the paper, they run the antibody binary with some flags to avoid ‘cheating’, since the crystal structure of the sequence already exists within the pdb:

antibody.macosclangrelease –fasta antibody.fasta -exclude_homologs -exclude_homologs_cdr_cutoff 95  -exclude_homologs_fr_cutoff 90 | tee grafting.log

The authors only state that they are using Rosetta3 and not which precise version they are using, and this is where my first issue is. I am using Rosetta 3.6 on linux which does not have the antibody.linuxrelease binary; however, it does contain the antibody_legacy.linuxrelease binary. Since I am fairly new to Rosetta, I was unsure if this was analogous – so I tried it with the same flags as in the tutorial. When I done this, I get the following output:

antibody_legacy.linuxgccrelease -fasta antibody.fasta -database $rdb -exclude_homologs -exclude_homologs_cdr_cutoff 95 -exclude_homologs_fr_cutoff 90 core.init: (0) Rosetta version exported from http://www.rosettacommons.org core.init: (0) command: antibody_legacy.linuxgccrelease -fasta antibody.fasta -database /usr/local/rosetta/main/database/ -exclude_homologs -exclude_homologs_cdr_cutoff 95 -exclude_homologs_fr_cutoff 90 core.init: (0) 'RNG device' seed mode, using '/dev/urandom', seed=782257618 seed_offset=0 real_seed=782257618 core.init.random: (0) RandomGenerator:init: Normal mode, seed=782257618 RG_type=mt19937 protocols.AntibodyModeler: (0) Setting up default settings protocols.AntibodyModeler: (0) Reading Options protocols.jobdist.JobDistributors: (0) Node: 0 next_job() protocols.jobdist.JobDistributors: (0) Master Node -- Waiting for job request; tag_ = 1 …and the job remains hung-up like this indefinitely, apparently waiting for something. At this point I thought, perhaps it is waiting because it needs more resources or cores, thus I ran the mpi version and got the following output: mpirun -np 2 antibody_legacy.mpi.linuxgccrelease -fasta antibody.fasta -database$rdb -exclude_homologs -exclude_homologs_cdr_cutoff 95 -exclude_homologs_fr_cutoff 90

core.init: (0) Rosetta version exported  from http://www.rosettacommons.org

core.init: (0) command: antibody_legacy.mpi.linuxgccrelease -fasta antibody.fasta -database /usr/local/rosetta/main/database/ -exclude_homologs -exclude_homologs_cdr_cutoff 95 -exclude_homologs_fr_cutoff 90

core.init: (1) Rosetta version exported  from http://www.rosettacommons.org

core.init: (1) command: antibody_legacy.mpi.linuxgccrelease -fasta antibody.fasta -database /usr/local/rosetta/main/database/ -exclude_homologs -exclude_homologs_cdr_cutoff 95 -exclude_homologs_fr_cutoff 90

core.init: (0) 'RNG device' seed mode, using '/dev/urandom', seed=1862415403 seed_offset=0 real_seed=1862415403

core.init.random: (0) RandomGenerator:init: Normal mode, seed=1862415403 RG_type=mt19937

protocols.AntibodyModeler: (0) Setting up default settings

protocols.jobdist.JobDistributors: (0) Node: 0 next_job()

protocols.jobdist.JobDistributors: (0) Master Node -- Waiting for job request; tag_ = 1

core.init: (1) 'RNG device' seed mode, using '/dev/urandom', seed=967867419 seed_offset=0 real_seed=1862415404

core.init.random: (1) RandomGenerator:init: Normal mode, seed=1862415404 RG_type=mt19937

protocols.jobdist.JobDistributors: (0) Master Node --available job? 0

protocols.jobdist.JobDistributors: (0) Master Node -- Spinning down node 1

protocols.jobdist.JobDistributors: (0) Node 0 -- ready to call mpi finalize

protocols.AntibodyModeler: (1) Setting up default settings

protocols.jobdist.JobDistributors: (1) Node: 1 next_job()

protocols.jobdist.JobDistributors: (1) Slave Node 1 -- requesting job from master node; tag_ 1

[neptune:01402] *** Process received signal ***

[neptune:01402] Signal: Segmentation fault (11)

[neptune:01402] Signal code: Address not mapped (1)

[neptune:01402] [ 1] /usr/lib64/libstdc++.so.6(_ZNSs6assignERKSs+0x8)[0x3fc0e9d4e8]

[neptune:01402] [ 3] /usr/local/rosetta/main/source/build/src/release/linux/2.6/64/x86/gcc/4.7/mpi/libprotocols.1.so(_ZN9protocols7jobdist16main_plain_moverERNS_5moves5MoverEb+0x2f7)[0x7f639a2c0827]

[neptune:01402] [ 4] antibody_legacy.mpi.linuxgccrelease[0x401a6e]

[neptune:01402] [ 5] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3fba21ed1d]

[neptune:01402] [ 6] antibody_legacy.mpi.linuxgccrelease[0x40219d]

[neptune:01402] *** End of error message ***

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

mpirun noticed that process rank 1 with PID 1402 on node neptune exited on signal 11 (Segmentation fault).

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

In this instance the failure is apparently due to “Address not mapped”; which address however is not clear to me since I have given the program the path to the Rosetta database folder.

So, I have four questions:

1. Is there a specific version of Rosetta 3 which contains the antibody.linuxrelease binary I need? From what I’ve read elsewhere, it is only in version 3.1 can someone confirm this?

2. Is the antibody_legacy binary analogous to the antibody one and can it be used in the same way?

3. Why would the antibody_legacy command be hung-up as if waiting for another job?

4. What address is the program referring to when I get the “Address not mapped” error when I run the mpi version?

Best Regards,

Dan

Post Situation:
Tue, 2017-02-14 05:53
cannond

1) Version: If you want to duplicate a paper published very recently, you will also need a recent version of Rosetta.  Try pulling the most recent weekly release.  3.6 is a year old.

3) It's hanging because you're running the MPI executable with only one processor.  The executables formatted like antibody.linuxgccrelease are symlinks to the most recent build, which in your case appears to be MPI.  Run whatever.default.linuxgccrelease for a non-mpi build, or whatever.mpi.linuxgccrelease for an mpi build.

4) It's a memory address - you're hitting a segfault because the program is trying to access memory outside of its allowed address space.  Usually this means the input isn't set up quite perfectly (antibody is very cranky about that sort of thing).  I can't diagnose it more specifically from the given message.

I've sent this along to the antibody folks.

Tue, 2017-02-14 07:39
smlewis

Hey Dan,

This is definitely a version issue. I would download the latest weekly release, before trying again (that should take care of the issues). FYI, MPI is not required for the antibody executable (which only does template selection), but it can be useful for antibody_h3 (which is a separate executable for modeling the CDR H3 loop).

Best,

Jeliazko

Tue, 2017-02-14 07:49
jeliazkov

Best Regards,

Dan

Tue, 2017-02-14 09:35
cannond

Hi Folks,

I have installed the latest version 2017.08 and have also updated my blastp version to 2.6.0 and it all seems to be working fine so far.