# Rosetta 3.4 build error with

18 posts / 0 new
Rosetta 3.4 build error with
#1

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.

Post Situation:
Tue, 2012-04-17 16:11
aork

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.

Tue, 2012-04-17 16:56
smlewis

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

Tue, 2012-04-17 18:37
rmoretti

yep

Tue, 2012-04-17 18:50
smlewis

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?

Wed, 2012-04-18 10:06
aork

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...

Wed, 2012-04-18 10:19
smlewis

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

Fri, 2012-04-20 10:38
aork

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?

Fri, 2012-04-27 10:08

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...

Fri, 2012-04-27 19:29
smlewis

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....

Tue, 2012-05-01 19:12

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

Fri, 2012-06-29 08:17
inder

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 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.

Fri, 2012-06-29 10:17
rmoretti

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.

Fri, 2012-06-29 17:23
inder
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 elem(i, i+1);
double a = exchange_accepts_[elem];
double b = exchange_attempts_[elem];
core::Real frequency(core::Real(a)/core::Real(b));

Wed, 2012-07-11 10:20
merritt

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

Wed, 2012-07-11 12:27
smlewis

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...)

Wed, 2012-07-11 12:43
smlewis
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);

Fri, 2012-07-20 15:02
merritt

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

Sat, 2012-07-21 10:50
smlewis