Try this one. It's based on Xavier makefile and I guess it should work.

Hi,

We're having some trouble with the submission of our code. When we send our code without usage of openmp, the code compiles just fine. But when we put in the openmp part, the report says "couldn't compile submission". We are using the modified provided makefile. The only modification is that we added -fopenmp flag to FLAGS and LDFLAGS variable. We're using g++ compiler. The code compiles locally without problems with the same makefile.
We would appreciate any assistance.

Best regards,
Nenad

Did you run "make clean" after you modified the makefile?

Yes we did. The folder structure is clean, only main.cpp in src, obj is empty and makefile in root folder.

Instead of adding -fopenmp to FLAGS and to LDFLAGS try leaving they as they are in the sample makefile and adding -fopenmp to LDLIBS like this: LDLIBS = -fopenmp

Hi,

Thanks for the suggestion grilomoto, I think that it worked. It is a bit odd that it won't compile properly locally, it always says "warning: ignoring #pragma omp parallel". The benchmark servers would so far always indicate that the openmp is not included properly, but no warning of that kind this time, so I guess it's all rigth.
Thanks again, we'll post again if the problem persists.

Best regards,
Nenad

As I said on another thread, openMP doesn't really work like say TBB in which you link a library at the end.
You need to specify it in the object building phase (FLAGS). Specifying it in LDLIBS will only get ignored imho.

Nenad, WILD wild guess here. Since GCC_SUPPFLAGS is set by the building enviroment by Intel, try setting openmp before it, as such:
FLAGS ?= -std=c++0x -O3 -fopenmp -Wall $(GCC_SUPPFLAGS)

LDFLAGS seems ok to me.

Nickraptis, thanks for the advice, but we've already tried it, it didn't work. I've already posted that the addition to LDLIBS worked for us, or at least it seems that way for now. We tried your way earlier and it worked locally on our machine (adding the flag both to FLAGS and LDFLAGS), but the benchmarking server reported that it couldn't compile. We'll see how it'll go with this and I'll repost as soon as we're sure if it's really working, since the code itself is not printing the right results just yet.

Best regards,
Nenad

Still not working. Strange things are happening. When we try uploading one code with the -fopenmp flag added only to the LDLIBS, it works. We're still not sure since the code isn't working completely, but the benchmark server doesn't report any errors. When we try to upload a different piece of code with the exact same makefile, it says that the openmp is ignored and that we should add the -fopenmp flag. When we add -fopenmp flag to the FLAGS variable, the server reports "couldn't compile submission". We have tried everything from the posts so far.
Is anybody else having the same problem or is it just us? Has anybody else succeeded in uploading a g++ compiled openmp code to the benchmarking server?

Best regards,
Nenad

I'm sorry to hear that. :/

Hey, my code didn't run on the 40-core because of an error too, but it wasn't a compiler error.
I'm running a bit slow now, but when I get to the 40-core again I'll let you know.

"...with a Makefile as its root."

How can I do it?

I have found this:
http://software.intel.com/fr-fr/forums/showthread.php?t=104491&o=a&s=lr

but still not shure how to do it...

Means that not put the make file in a folder during compression i.e if you try to extract the the compressed file then the make file appears in the extraction directory .

I have done it.
Thanks mah.nabil for your advice.

Still wondering:
can someone list the changes that we have to make to the makefile, for:
1. OpenMP
2. CILK
3. TBB
?

For TBB just install tbb libraries (in Linux for example use package manager) and then uncomment 2nd line : #example if using Intel Threading Building Blocks : #LDLIBS = -ltbb -ltbbmalloc. So, LDLIBS = -ltbb -ltbbmalloc is everything you need for TBB. For CILK you must install Intel Parallel studio and then uncomment this : #COMPILER ?= $(ICC_PATH)icpc and this #FLAGS ?= -std=c++0x -U__GXX_EXPERIMENTAL_COMPILER0X__ -xHOST -fast -w1 $(ICC_SUPPFLAGS). I dont use OMP so i cant help you about that :)

Makefile:66: .depend: No such file or directory.

How can I fix this?

I have only changed LDLIBS and FLAGS.

I've just tested these on my computer and on a submission using gcc(switch it on the sample code):

# using icc :
#COMPILER ?= $(ICC_PATH)icpc
# using gcc :
COMPILER ?= $(GCC_PATH)g++

# using icc :
#FLAGS ?= -std=c++0x -U__GXX_EXPERIMENTAL_COMPILER0X__ -xHOST -fast -w1 $(ICC_SUPPFLAGS)
# using gcc :
FLAGS ?= -std=c++0x -O3 -fopenmp -Wall $(GCC_SUPPFLAGS)

LDFLAGS ?= -g
LDLIBS = -fopenmp
#example if using Intel Threading Building Blocks :
#LDLIBS = -ltbb -ltbbmalloc

Obs.: if you wonder how i could know it worked on the submission, i first submited my code and it worked, then i re-submited it with the folowing at the start of the main:

int id;
#pragma omp parallel private(id)
{
id = omp_get_thread_num();
if(id == 6){
printf("Helo world! here is thread %d\n", id);}
}

in this way i've got a wrong output with 12 threads
that means that a thread with id 6 was generated, and so the pragma worked.

about the question on the clean comand:
it "executes" the clean part of the makefile.
In the makefile from the sample code, it deletes the objects in obj folder :

clean:
rm -f obj/*

just for example:

if you coment those lines on the makefile the terminal wont reconize the comand.

or if you add below rm -f obj/* a line: rm -f run you will also delete the executable.

How can I fix this?

It's just normal behavior of our generic Makefile. You'll always see it after a dist-clean.

Just make again and it will go away.

i would say the problem is your hello world output. with this your output is different from the reference prog.

It didn't go away...
I have tried "make clean" twice, and it still stays the same...

Maybe I haven't understood what you meant, by saying: "Just make again and it will go away."...

Maybe I haven't understood what you meant, by saying: "Just make again and it will go away."...

The longer answer it is then :) Refer to the Makefile in the reference .zip for line numbers.

The .depend file gets created automatically by the Makefile (lines 62-64) and then it is included in line 66.

Now, the first time you unzip or after a clean-dist ('make submit' calls that too) the .depend file won't be there. So, 'make' issues the warning you are seeing and runs itself again this time having no problem because it just generated the file.

So, the big question is: Does 'make' build your executable or not? If it does, you can just ignore the warning. You shouldn't see it the next time. That's the behavior I'm seeing anyway.

Thanks for your great effort! It was all new for me... :)

dieter 84, what i'm saying is that the first piece of code in my previous post, if switched in the makefile from the sample code, will work. And I can say that for sure because of the test that i've made using the helo word code (if you do understand the openmp code on it, you may see that the wrong output message, was the proof that it woorked). I was just explaining how i've done for it to work and how i've tested it to know for sure that it worked.

grilomoto, I tried yout makefile, it didn't work for me. Still giving the error "couldn't compile submission" even though it does compile locally. I'm getting pretty sure this problem isn't due to the makefile... It's either because of the code or the benchmark server. But if it's because of the code, it shouldn't compile locally either... This is getting really annoying...

neshone :
src/main.cpp:85:5: error: reference to "ref" is ambiguous
src/main.cpp:43:10: error: candidates are: sequence ref

Thanks, Xavier. I don't know what the problem was, but I renamed the variable in question, so it's coming through now.
We now have another problem. The report says the output is different, but we've checked our code with a couple of different test inputs and it's the same as the sample code, everything sorted and filtered out. The report goes like this:

error on a 12-cores machine :
output is different than the expected one.

on a 12-cores machine, using 12 worker threads, running benchmark AE12CB-16325737234926730915:
invalid submission

on a 12-cores machine, using 12 worker threads, running benchmark AE12CB-7570939485803595530:
valid submission

It's the same for serial and parallel algorithm, so I don't think it's the threading issue and it's odd that one benchmark is valid and the other is invalid. We could really use some help...

Best regards,
Nenad

Hi,

>refseq
AAAATAAAA

>otherseq
AAA

the sample program returns :
2 4 1 3
7 9 1 3

your program :
1 3 2 4
1 3 7 9

Thank you very much for your help. I've dealt with that problem and the bug is fixed, but the problem persists. I'm really sorry, but can I ask you to take another look. Led by your example, I've ran our code through another set of sequneces and the output is the same as the sample code and I'm clearly missing something. Sorry, for the trouble I'm causing...

Best regards,
Nenad

Your matches are not exactly sorted by (last index in otherSeq, last index in refSeq) and there are some matches that can be shifted or are included inlonger ones. example from your program output : 121867 121882 1995 2010 121866 121882 1995 2011 it shoud be only: 121866 121882 1995 2011 please use the sample program on big inputs like the one we published on this forum with its expected output. If it takes too long, you can cut parts of it and test it with the sample program, you should be able to reproduce these problems.

Thanks a lot, I'll do that.
Again, sorry for the trouble.

Best regards,
Nenad

I'm really sorry to bother you again, but I'm flipping out here. My code executed locally, sequentially or in parallel, filters out all of the solutions specified. It gives the same output as the sample code, even when the input is the posted large file. I've checked my code and it specifically filters out everything you specified in the last post, you can see that for yourself if you take a look at the last 50 lines or so. My output is always sorted the same way it is in the sample code. I've tried to think of a sample input that would produce the troubling solutions and the only thing I could come up with is something like this:
refseq: TGAAAAAAAAAC
inputseq: CAAAAAAAGT
treshold: e.g. 5
and my code handles them just fine (as well as similair sequences I could come up with), locally. I don't understand what happens on the server. The sorting and the filtering part of the code is sequential, so no threading issues should cause this.
Are there any other test sequences I could try locally, because I'm banging my head against the wall here?
I'm REALLY sorry for the trouble I'm causing, but I don't know what else to do...

Best regards,
Nenad

Hehe, I wanted to hurt my head on the screen several times too. I finally try wrote those tests that were quite tricky and that gave me different output as the given program. Try it and let me know if it helped you. You will have to put the reference in a file and the input in an other :) >ref TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTAAAAAAAAAAAAATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT in TTTTTTTTTTTTTTTTTTTTTTTTTAAAAAAAAAAAAA ---------------------------------------------- >refbug TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTAATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT >Sequence TTTTTTTTTTTTTTTTTTTTTTTTT -------------------------------------------- >refbug TTTTTTTTTTTTTTTTAAAAAAAAAA >Sequence TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTAAAAAAAAAAAAAAAAAATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

refTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTAAAAAAAAAAAAATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTinTTTTTTTTTTTTTTTTTTTTTTTTTAAAAAAAAAAAAA
----------------------------------------------
>refbugTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTAATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT>SequenceTTTTTTTTTTTTTTTTTTTTTTTTT
--------------------------------------------
>refbugTTTTTTTTTTTTTTTTAAAAAAAAAA>SequenceTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTAAAAAAAAAAAAAAAAAATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

candreolli, you have my greatest thanks. Your sequences pointed out the bugs in my code. I don't really understand why yet, but they did. The bugs will hopefully be corrected and we will finally have our first benchmark results.
My thanks to Xavier too, for his patience with us.

Best regards,
Nenad

You're welcome :) It took me some time to understand what was going on in our results too.

Here is one more case which was making problems to us(different output on benchmark AE12CB-10353053912364647132).
Everything we tried was working just fine on our local machine. We even tried all those cases which you posted above and all of them were working fine. So I tried to somehow simulate problem and found the following:

>ref
TTTTTAAAAATTTTT

>in
TTTTAAAATTTT

minMatchLen = 4

In this particular case there is a matching on the end of the sequences, and that was what caused our problem.

Regards,
Nemanja