pNNMAKE compilation

Member Site Forums Rosetta 3 Rosetta 3 – General pNNMAKE compilation

Viewing 3 reply threads
  • Author
    Posts
    • #1474
      Anonymous

        Hello,
        I’m trying to make fragments using rosetta 3.2 in order to run membrane ab initio protocol.
        after trying to create pNNMAKE.gnu using “make” command I got this error:


        SYSTEM SETUP [make.system]
        COMPILER=gnu @ adva
        F77=g77
        FFLAGS=-finline-functions -funroll-loops -W -ffixed-line-length-132 -Wimplicit -O -ffast-math -malign-double
        FOPTIMFLAGS=-O -ffast-math -malign-double
        FDEBUGFLAGS=-g -Wall -Wimplicit -Wsurprising -Wformat -W
        FPROFILEFLAGS=-pg
        LINKFLAGS=


        g77 -finline-functions -funroll-loops -W -ffixed-line-length-132 -Wimplicit -O -ffast-math -malign-double -c -o .gnu.make_ss_nn.o make_ss_nn.f
        make_ss_nn:
        Error on line 15 of structure.h: unbalanced parentheses, statement skipped
        Error processing common blocks before line 19: Declaration error for best_nn: attempt to use undefined variable
        Error processing common blocks before line 19: Declaration error for total_residue: attempt to use undefined variable
        Error processing common blocks before line 19: Declaration error for acc: attempt to use undefined variable
        Error processing common blocks before line 19: Declaration error for best_nn_ss_typ: attempt to use undefined variable
        Error on line 32: subscripts on scalar variable best_nn
        Warning on line 43: local variable best_nn_ss_type never used
        /usr/bin/g77: aborting compilation
        make: *** [.gnu.make_ss_nn.o] Error 25

        Can anyone help me?

        Thanks,
        Adva

      • #8151
        Anonymous

          This system is deprecated (or at least, nobody who knows anything about it is willing to offer support for it). The logic of fragment selection was ported to Rosetta proper a while ago (I’m not sure if it was as early as 3.2): http://www.rosettacommons.org/manuals/archive/rosetta3.4_user_guide/dc/d10/app_fragment_picker.html

          There are also some demos for it in the demos directories: rosetta34/rosetta_demos/fragment_picker/BestFragmentsProtocol

        • #8153
          Anonymous

            The general recommendation, if you’re not doing a massive number of runs and aren’t doing anything too custom, is to avoid all the hassle and just use the Robetta server to do fragment picking. http://robetta.bakerlab.org/

            If you absolutely need to use NNMAKE to do fragment picking, I can probably track down someone to help you troubleshoot, but be advised that people have now moved over to the new fragment picker: http://www.rosettacommons.org/manuals/archive/rosetta3.4_user_guide/dc/d10/app_fragment_picker.html

          • #8154
            Anonymous

              I second Rocco…I’m a Rosetta developer and I almost always use Robetta instead of generating fragments myself. If it’s stock fragments, use Robetta!

            • #8224
              Anonymous

                I would be glad to use Robetta- if it was valid for membrane proteins…

              • #8229
                Anonymous

                  Understood. I’d still recommend looking into the new fragment picker for custom jobs. As Steven indicates, the people who knew NNMAKE have either stopped using it or have moved out of the Rosetta community entirely. If you need to replicate an old protocol exactly or the like, we can possibly get NNMAKE to work, but things will likely be much easier now and in the future if you use the new fragment picker instead.

                • #8232
                  Anonymous

                    I have no idea how to use fragment_picker for membrane proteins. With NNMAKE I simply edited the psipred file to match my own prediction- based on a consensus between several TM prediction methods (memsat, tmhmm, octopus, hmmtop etc.)
                    how can i do that with fragment_picker to make sure it will properly predict the TM helices?

                  • #8234
                    Anonymous

                      It will work the same way – you can manually edit the secondary structure prediction inputs to force the result you need. I’ve done the same thing, forcing helix in a region that SS prediction felt was loop but I had reason to believe was the C-terminus of a longer helix.

                    • #8250
                      Anonymous

                        I just talked with one of the local experts, and he guesses that running the fragment picker normally will probably work. The default vall does have membrane proteins in it, and if your protein is a typical membrane protein, the protocol will likely pick those fragments out.

                        The one caveat is that because the vall is dominated by soluble proteins, there’s a chance that you’ll pick up spurious soluble protein fragment hits. One way around that is to trim the vall to be membrane protein specific, but that’s probably only worth doing if the default fragment picking doesn’t produce acceptable results.

                      • #8253
                        Anonymous

                          ok, so what’s better- change the ss prediction file manually or filter vall for membrane proteins?

                        • #8254
                          Anonymous

                            The real answer is, “it’s empirical and system-dependent, you’ll have to try both to find out”.

                            The useful answer is, try the easiest one first and if it works, don’t bother with the other one. I suspect the ss prediction file is easier to modify than the vall.

                        Viewing 3 reply threads
                        • You must be logged in to reply to this topic.