Order of including omp.h matters for compilation about ctf HOT 12 CLOSED

So I have no idea if this breaks anything, but if you include omp.h in ctf.hpp before any ctf specific headers, the compilation bug goes away.

from ctf.

Could you please post the compiler message(s)? I have a feeling it might
have to do with a conflicting implicit declaration.

On 10/4/16 9:57 AM, Kevin Hannon wrote:

So I have no idea if this breaks anything, but if you include omp.h in
ctf.hpp before any ctf specific headers, the compilation bug goes away.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/solomonik/ctf/issues/27#issuecomment-251413355,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFAMoXBDg4TEEyjrpuHczfcPqfC4yrH1ks5qwmlhgaJpZM4KNxSK.

from ctf.

Here is the error:

mock_ctf.cc: In function ‘int main(int, char**)’:
mock_ctf.cc:18:37: error: ‘omp_get_max_threads’ was not declared in this scope
   int nthread = omp_get_max_threads();
                                 ^
 mock_ctf.cc:18:37: note: suggested alternative:
 In file included from      /home/kannon/src/ctf/include/../src/interface/../contraction/../shared/util.h:132:0,
             from /home/kannon/src/ctf/include/../src/interface/../contraction/ctr_tsr.h:7,
             from /home/kannon/src/ctf/include/../src/interface/../contraction/contraction.h:5,
             from /home/kannon/src/ctf/include/../src/interface/functions.h:6,
             from /home/kannon/src/ctf/include/../src/interface/tensor.h:4,
             from /home/kannon/src/ctf/include/ctf.hpp:20,
             from /home/kannon/src/ctf/Build/include/ctf.hpp:1,
             from mock_ctf.cc:4:
 /usr/lib64/gcc/x86_64-suse-linux/4.9/include/omp.h:73:12: note:   ‘CTF_int::omp_get_max_threads’
 extern int omp_get_max_threads (void) __GOMP_NOTHROW;

from ctf.

It looks like omp.h is being #included inside the CTF_int namespace
(src/shared/util.h:132). Should be an easy fix, although I'm not
actually sure how it works at all as it is.

On 10/4/16 10:19 AM, Kevin Hannon wrote:

|mock_ctf.cc: In function ‘int main(int, char**)’: mock_ctf.cc:18:37:
error: ‘omp_get_max_threads’ was not declared in this scope int
nthread = omp_get_max_threads(); ^ mock_ctf.cc:18:37: note: suggested
alternative: In file included from
/home/kannon/src/ctf/include/../src/interface/../contraction/../shared/util.h:132:0,
from
/home/kannon/src/ctf/include/../src/interface/../contraction/ctr_tsr.h:7,
from
/home/kannon/src/ctf/include/../src/interface/../contraction/contraction.h:5,
from /home/kannon/src/ctf/include/../src/interface/functions.h:6, from
/home/kannon/src/ctf/include/../src/interface/tensor.h:4, from
/home/kannon/src/ctf/include/ctf.hpp:20, from
/home/kannon/src/ctf/Build/include/ctf.hpp:1, from mock_ctf.cc:4:
/usr/lib64/gcc/x86_64-suse-linux/4.9/include/omp.h:73:12: note:
‘CTF_int::omp_get_max_threads’ extern int omp_get_max_threads (void)
__GOMP_NOTHROW; |

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/solomonik/ctf/issues/27#issuecomment-251420213,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFAModlrm3JRCXxW0grX4Vg_ZFseS_AHks5qwm6ZgaJpZM4KNxSK.

from ctf.

mock_ctf.cc is not part of the CTF repo.

In any case, it seems that extern "C" { } might be required, or some other fix for the namespace issue.

from ctf.

src/shared/util.h has a lot of issues. omp.h is not the only include that needs to happen outside of the CTF_int namespace...

from ctf.

Thank you for the changes. mock_ctf.cc was what I called the test program I used.

from ctf.

Hi Kevin,

Thanks for the bug report. I just pushed a fix to master. As Jeff and Devin pointed out the omp.h include should not have been in the namespace CTF_int {} block. Moreover src/shared/util.h should not even be included from any interface files and is meant to be internal. I made changes to fix both.

Also, separately, you should initialize the random seed generator srand48(...) to something dependent on processor rank, before calling fill_random on CTF tensors. CTF does not perform any seeding itself, since its not evident how to do so robustly while preserving reproducibility.

Best regards,
Edgar

from ctf.

Thank you for your help.

from ctf.

Regarding srand48, C++11 has great features for RNG...

from ctf.

If C++11 can't be required, Boost works.

I know I am a big hypocrite for recommending C++11 and Boost now, given my position in ~2012, but C++ compilers have had 4 years to stop sucking.

from ctf.

(Sorry for the off-topic discussion.) CTF currently requires C++11. I am happy to learn C++11 has more robust support for RNGs and will keep that in mind. However, I am not sure they provide a solution to the underlying problem with parallel RNG generation for a library like CTF. One can just generate non-deterministically, but determinism is extremely valuable for reproducible testing. However, then one has to insure that different processors get a different seed and different tensors get a different seed, and it becomes not so clear how to do that (e.g. on a CTF instance basis or via global counter) and how to let the user control it.

I guess the right solution might be to have fill_random_nondeterministic and fill_random_preseeded. Then it remains to figure out whether fill_random_preseeded should have all processor ranks with the same seed or with a different seed, and how to handle the former, which is where C++11 RNGs may help. And what fill_random should do for backwards comp.

from ctf.