Rosetta 3.4 build error with

Member Site Forums Rosetta 3 Rosetta 3 – Build/Install Rosetta 3.4 build error with

Viewing 5 reply threads
  • Author
    Posts
    • #1240
      malmstroem
      Participant

        I’ve been trying to build Rosetta 3.4 on Ubuntu 10.04. I’ve tried compiling with both gcc 4.4.3 and 4.3.4. Both give me the following error:

        src/protocols/canonical_sampling/ParallelTempering.cc: In member function ‘virtual void protocols::canonical_sampling::ParallelTempering::finalize_simulation(core::pose::Pose&, const protocols::canonical_sampling::MetropolisHastingsMover&)’:
        src/protocols/canonical_sampling/ParallelTempering.cc:193: error: size of array ‘exchange_accepts_’ has non-integral type ‘std::pair
        scons: *** [build/src/release/linux/2.6/64/x86/gcc/4.4/protocols/canonical_sampling/ParallelTempering.os] Error 1
        scons: building terminated because of errors.

        Does anyone have any ideas of what could be causing this? Thank you much for your help.

      • #6978
        Anonymous

          No idea what’s causing it, beyond “different versions of GCC behave differently”.

          Looking at the code,the first thing I’d try to fix it is to add “#include

          ” into the headers list of src/protocols/canonical_sampling/ParallelTempering.hh. Since it doesn’t fail for me I can’t test it for you.
        • #7358
          Anonymous

            I am having the exact same problem with Ubuntu 10.04 and gcc 4.4.3. Since it’s a bit involved to install gcc 4.5, I’d be grateful if someone could show me how, in excruciating detail, to dummy out the offending code. Needless to say I’m a total noob at Rosetta and Ubuntu. TIA

          • #7366
            Anonymous

              Thanks very much. It compiled with the fix. Keep my fingers crossed and hope that it runs without a hitch. I put in the error message and commented out the block just in case someone like jadolfbr finds a fix for the bug.

            • #7397
              Anonymous

                I hit this problem also (gcc 4.4.3).
                I have no idea why the compiler is having trouble with type promotion, but the following work-around keeps it happy.


                // EAM - modified to work around compiler glitch with gcc 4.4.3
                for (core::Size i=0; i std::pair elem(i, i+1);
                double a = exchange_accepts_[elem];
                double b = exchange_attempts_[elem];
                core::Real frequency(core::Real(a)/core::Real(b));
              • #7431
                Anonymous

                  Yes, it compiles also if I replace with


                  for (core::Size i=0; i<n_temp_levels()-1; ++i) {
                  std::pair<int, int> elem(i, i+1);
                  core::Real const a = exchange_accepts_[elem];
                  core::Real const b = exchange_attempts_[elem];
                  core::Real frequency(a/b);
                • #6979
                  Anonymous

                    I assume Steven meant “#include <map>”, (include the C++ map header) but the forum ate his angle brackets.

                  • #6983
                    malmstroem
                    Participant

                      Thanks for the thought. I did try adding <map> into the headers list but the same error still came up. Any ideas why exchange_attempts_ and exchange_accepts_ aren’t being recognized as maps?

                    • #6980
                      Anonymous

                        yep

                      • #6984
                        Anonymous

                          No to your actual question.

                          If this is code you don’t intend to use, I think it may dummy out safely. It’s got a hard exit if not compiled in MPI, so it’s clearly not a widely-accessed bit of code – as far as I can tell it’s only accessed through the Parser if you are deliberately doing the canonical sampling MC stuff. If you think you aren’t going to use it, (and if you don’t know you intend to, you aren’t), try dummying out the functions with the calls that won’t compile (or just replace the map indicies with 1 or something). The code won’t work that way, but if you aren’t using it anyway…

                        • #6993
                          malmstroem
                          Participant

                            Dummying it out did allow the build to complete. I’m pretty sure I won’t be needing canonical sampling so that should work for now.
                            Thanks

                          • #7030
                            Anonymous

                              Hi Steven,
                              I’m having the same issue with 10.04. How do I dummy out the functions with the calls that won’t compile?

                            • #7031
                              Anonymous

                                Well…you, I think, know the codebase well enough to hope that since you can reproduce the bug, you’d take a stab at fixing it :)

                                Failing that – just comment out anything that GCC will let you comment. You’ll need to make sure the function has legal return values, but short of that you can comment out pretty much any line in the functions with no issues. You should probably leave the header alone, but you can start by commenting out any line of code that contains the offending references to exchange_accepts_ and then see what else has to go to get it to compile.

                                I don’t have code in front of me, but it may be possible to just remove the whole block from compilation – remove it from whichever .src.settings file it appears in, and any init files it appear in. If I recall correctly this code is only used via parser, so removing it from the .src.settings file and the init files will cleanly remove it from the code base.

                                Keep me updated if it’s giving you trouble – this may not be the clearest advice I could give, it’s a little late…

                              • #7059
                                Anonymous

                                  Thanks Steven,
                                  I wasn’t thinking about commenting out the function or removing it from src.settings in order to get it to run….wasn’t sure if ‘dummy’ it out was some fanciful scons or c++ term I had never heard of! I had trouble compiling rosetta3.3 as well, and was running into strange errors trying to get the fragment picker working as per brian’s tutorial on the wiki (CPU crashed and burned last week). I ended up upgrading to Ubuntu 12.04, and they both seem to be compiling fine with GCC 4.5….

                                • #7361
                                  Anonymous

                                    Simply open rosetta/rosetta_source/src/protocols/canonical_sampling/ParallelTempering.cc with your favorite text editor. Scroll down to about line 193. Then delete the “for {}” block:


                                    for (core::Size i=0; i std::pair elem(i, i+1);
                                    core::Real frequency(core::Real(exchange_accepts_[elem])/core::Real(exchange_attempts_[elem]));
                                    tr << temperature(i+1) << " <-> ” << temperature(i+2) << ": " << frequency
                                    << " (" << exchange_accepts_[elem] << " of " << exchange_attempts_[elem] << ")" << std::endl;
                                    }

                                    … or better yet, replace it with the following code (so if for some reason you run something that depends that needs the deleted code, you’ll be told about it):


                                    utility_exit_with_message( “Oops – tried to execute the code I edited out.” );

                                    Save the file with the changes, and then re-try compiling. With any luck, things will compile. If not, try repeating the process in location of the new error.

                                  • #7398
                                    Anonymous

                                      I am testing this against the development branch; assuming it doesn’t break anything I’ll put it in for 3.5.

                                    • #7399
                                      Anonymous

                                        Does it work if you replace “double a” and b with “core::Real const a” and b? I don’t want to introduce direct use of double into the codebase if I don’t have to. The way you’ve casted it makes me think you have tried that and it failed. core::Real is typedef’d to double. (I don’t have a system where it’s broken to test against…)

                                      • #7435
                                        Anonymous

                                          Excellent. It’s patched in the main codebase. Thanks!

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