Rosetta 3.4 build error with

[malmstroem]

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.

[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

[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

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

[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));

[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);

[Anonymous]

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

[malmstroem]

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?

[Anonymous]

yep

[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…

[malmstroem]

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

[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?

[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…

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

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

[Anonymous]

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

[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…)

[Anonymous]

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

[Author]

Posts