Trouble Compiling Modified Protocols

Member Site › Forums › Rosetta 3 › Rosetta 3 – Build/Install › Trouble Compiling Modified Protocols

Viewing 2 reply threads
  • Author
    Posts
    • August 9, 2016 at 4:52 am #2484
      Anonymous

        Hi All,

        I am trying to modify the apply function of a protocol and then use that protocol in RosettaScripts. I was able to modify the function and successfully compile the new protocol, but when I call the protocol in RosettaScripts, it seems to use the version of the protocol from before I modified it. I can successfully call the modified function from a freestanding pilot app, but the compiler does not seem to be properly incorporating the new version into the RosettaScripts framework. Currently, I have just tried compiling using the “scons” and “scons bin” commands. Is there something else I can do to make sure all updated protocols are included in RosettaScripts?

        Thanks,

        Sandy

      • August 11, 2016 at 6:49 pm #11783
        Anonymous

          Did you modify the code in place, or did you make a copy and modify the copy?  

           

          If the former, something is weird and wrong and I need more data.  Try deliberately breaking the code (just put the word “hello” on the beginning of the first line for a compiler error) and recompiling to ensure it’s compiling what you think it’s compiling.

           

          If the latter, you need to:

          A) make sure your new thing is registered in the relevant .ihh files in protocols/init (init.MoverCreators.ihh and init.MoverRegistrators.ihh, for example) – do this by analogy to the object you copied from.

          B) make sure your new thing is in the protocols?.src.settings file as appropriate (again, probably adjacent to the thing you copied from)

          C) make sure your new thing’s string name function (name, keyname, maybe both of those, maybe something else) has a NEW string name.

        • August 12, 2016 at 12:24 am #11785
          Anonymous

            Thanks for the reply. I modified the code in place. To be honest, I basically just replaced the apply function with the code I wanted to test because I was a bit confused about how to register a new mover with init.MoverCreators.ihh and init.MoverRegistrators.ihh. I know this is not a good standard, but I was more concerned with just seeing if my code worked. None the less, the apply function does work exactly as I want when called by my pilot app. There will be a compilation error if the mover’s code is not correct. Even further testing, I included code in the mover that refers to an nonexistent residue. This causes a crash when used with my pilot app but not when used with Rosettascripts, which makes me almost certain Rosettascripts is not using the right version.

            I think there may be something wrong in general with how my Rosetta package is compiling, when I try any option other than “scons”, “scons bin” or “scons pilot_apps_all” (or the release versions), I get an error “TypeError: list indices must be integers, not str”. “scons bin” has seemed work fine besides this problem however. Even more odd, while the mover that I changed (RollMover) still needs good code for “scons bin” to run, when I deliberatley broke the code of another protocol which should be hugely important (SingleFragmentMover) it did not (seemingly) cause any issue for scons or Rosettascripts. I know this is a lot, and thanks for any help you can give. Maybe I should just give up on this Rosetta package and try a fresh installation?

          • August 12, 2016 at 1:23 am #11786
            Anonymous

              I don’t really understand what’s going on either.  If some builds will compile and some won’t, then either:

              A) we have a misunderstanding about what is being compiled, and actually all are broken,

              or B) we have a compilation error that occurs only in release mode and not debug mode (that’s possible but pretty unlikely unless you were using the #NDEBUG processor flags).

              For case A, the correct behavior is, download Rosetta again, compile it, then modify just your one file, and try compiling again and see what happens.

              Part of the problem may be that if Rosetta is working, then you break the code and try to recompile, and the compile fails, the old binaries still work (they don’t get overwritten until the last step).  In fact, it’s possible that the rosetta_scripts binary is calling a differently compiled set of underlying code if it’s messed up in just the right way (although I think it would have to be statically built for that).

               

              For case B, the solution is, fix the compile errors :)

            • August 12, 2016 at 10:15 pm #11787
              Anonymous

                Sorry if I was not clear earlier. I meant that debug mode and release mode compiles give the same result. None the less, you were right about downloading a new Rosetta package. I downloaded the 3.6 source only version, modified the code and built it, and now RosettaScripts is using the modified protocol like it should. It also does not compile when I deliberately break the code. I am not sure what about the new download fixed my problem, but one thing I noticed is that the package I was working with before was a source and binaries package. Maybe something about the binaries already being in place at the start confused the compiler? Regardless, the problem is gone for now. Thanks a lot for the help.

              • August 13, 2016 at 6:02 pm #11788
                Anonymous

                  I don’t know exactly how the precompiled binaries are supplied, but it seems very likely that some confusion between the prebuilt binaries and the freshly built binaries could be the source of the problem.  We assume any user who wants prebuilt binaries isn’t going to then compile the code! Glad it’s fixed.

              • Author
                Posts
              Viewing 2 reply threads
              • You must be logged in to reply to this topic.