Rosetta source + binaries

Member Site › Forums › Rosetta 3 › Rosetta 3 – Build/Install › Rosetta source + binaries

Viewing 1 reply thread
  • Author
    Posts
    • September 15, 2015 at 1:49 pm #2293
      Anonymous

        Dear Rosetta Users:

        I recently installed Rosetta 3.5 onto a linux box. There are two different building packages distributed online. One is “Rosetta source” and the other one is “Rosetta source + binaries for linux”. I downloaded the latter one and complied it successfully followed the instructions. But I am just wondering if I ever need to compile it if it came with binaries. Thank you very much!

        Regards,

        Zuodong

      • September 17, 2015 at 7:10 pm #11212
        Anonymous

          The version with the binaries shouldn’t need to be compiled. Hopefully it should work “right out of the box”. (There should be links to executables present in the main/source/bin directory, right?)

          That said, while we attempt to make Rosetta as self-contained as possible, it’s hard to control for all the variability of different systems. There’s a chance that the Rosetta binaries distributed in the pre-compiled version aren’t compatible with your particular system. In this case, you would need to recompile for your system.

        • September 18, 2015 at 4:35 pm #11216
          Anonymous

            Thank you very much for your reply. I did compile the version with binaries before I asked this. And there is a difference between compiled and uncompiled. In the uncompiled version, there are executables present in the main/source/bin directory. But their file size are all 0 bytes. After I compiled the source code, they all had non-zero size. So I am just not sure if this is the key here.

            I also have a question related to this. So in the “how to run rosetta” page, it says that all the applications are in the main/source/bin directory and the file format should be X.linuxgccrelease. But in the documentation for individual applications like RosettaRemodel, it says that the application is in rosetta/main/source/src/apps/public/. And the file format is X.cc.

            So are the X.cc and X.linuxgccrelease the same? If not, which one is the proper one to use?

            Thank you!

          • September 19, 2015 at 8:08 pm #11219
            Anonymous

              Depending on how things are compiled, the files in the bin/ directory are normally just symlinks to other files in the build/ directory. So depending on how your computer represents symlinks, you might see that the files in the bin/ directory are zero sized. The key test is to try running them and see if they work. (A simple program that doesn’t need any extra parameters is the “validate_database” one. It should run and give you some diagnostic output.)

              The X.cc and X.linuxgccrelease files are *not* the same. The X.cc are the C++ source code files which implement the programs. These C++ files need to be compiled with a C++ compiler, where they’re turned into the X.linuxgccrelease files, which are the ones which can actually run on your machine. The RosettaRemodel is simply pointing out the source code for the application, for those people who know C++ and wish to look into the details of how things work.

            • September 21, 2015 at 8:04 pm #11223
              Anonymous

                I see. Thank you very much! I tried the valibate_database program and both compiled and uncompiled version worked.

                I did not get any error messages when I compile the source code so I assume it compiled successfully. But I am wondering if I need to run the tests (unit and integration) to check things. My impression after reading the documentation on tests is that these tests are for Rosetta developers to run after they change the code. I would not be making any changes to the code, so are these tests still recommended to run after the first compilation?

              • September 21, 2015 at 10:18 pm #11230
                Anonymous

                  You are right that the tests are primarily for Rosetta developers to make sure that they don’t break anything after they make changes. – The tests are testing the code, rather than the compilation. – We run the tests (and make sure they pass) before we package the weekly releases, so there shouldn’t be any code-level issues in the weekly releases. (Or at least nothing that the current set of tests would catch.)

                  The only reason the tests might fail is if there’s some major issue with compilation which makes Rosetta crash. But generally you’ll see that in standard runs as well. If you don’t get errors from your regular runs, you’re probably fine. (I certainly haven’t ever run any tests after I’ve compiled the weekly release versions .) 

                  But the tests are there if you’re paranoid and want to double check things. I certainly wouldn’t fault anyone for doing so, if they so desired. I just don’t think it’s rountinely necessary. (Even then, the integration tests aren’t less useful than the unit tests. The integration tests are set up to compare two revisions between each other. Without a reference revision, you’re just looking to make sure that Rosetta doesn’t crash on the test input.)

                • September 21, 2015 at 10:56 pm #11231
                  Anonymous

                    This is great. Thank you Dr. Moretti!

                • Author
                  Posts
                Viewing 1 reply thread
                • You must be logged in to reply to this topic.