Coarrays with WinMain()

[Chris_G_2]

I have a problem with coarrays using Intel Parallel Studio XE 2011 on Windows 7. I have written some coarray code which works well as a standalone program with an impressive speed increase using 2/4 or 8 cores. I am now trying to integrate it into an existing Windows application using

 integer function WinMain(hInstance, hPrevInstance, lpszCmdLine, nCmdShow)

This is compiled with the coarray option enabled. However, when I interrogate the program for num_images() it always returns a value of zero and not 8 which is the number of cores on this computer. this_image() is always returned as 1.

The environmental variable NUMBER_OR_PROCESSORS returns a value of 8.

Help would be much appreciated!

Chris

[Steven_L_Intel1]

I don't think this will work. Remember that with coarrays you have multiple copies of the whole program running in parallel. Can the application deal with that - when only "image 1" is connected to a display? We do need to figure out how to make coarrays work in a modular fashion - perhaps the proposal for "teams" being proposed for a future standard would help.

[Chris_G_2]

Thanks Steve. Is there any way I can integrate this program into a Windows application? Chris

[Steven_L_Intel1]

I need to discuss this with the developers - a lot may depend on what your program does and how you want it integrated. If it is just something that runs off by itself and uses files for input and output, you could build it as a console executable and use ShellExecute or CreateProcess to run it. Tell me more about how you'd like the integration to work - what information is passed to and from the coarray code?

[Chris_G_2]

Thanks again Steve. These comments are provoking a dicussion amongst the small team here. I'll get back to you.

[Chris_G_2]

What about DLLs (properly constructed). Can coarrays work with them? Chris

[Steven_L_Intel1]

No - sorry. The whole concept of coarrays is that it is whole-program oriented. If the executable is not written as a coarray application, you can't use coarrays. The standards committee recognizes that this is a limitation and is working on a proposal that would allow for libraries to use coarrays, but that's a long way off. The main issue as far as our implementation goes is that there is some "launch" code that needs to be executed when the program starts and an mpiexec call made on the program's behalf to run the whole program under the control of MPI.

[Chris_G_2]

Thanks yet again. I guess I'm asking too much of coarrays; after all they were designed to be the simplest possible parallel constructs for FOTRAN. I'm just rather excited by them. Once I mastered them, I found them easy to use, and very efficient as long as I kept the communications between images at a minimum.

[jimdempseyatthecove]

Have you considered using CreateProcess, hidden window, to run your coarray app. Setup a communication channel betwee the WinApp and coarray app. (pipe or memory mapped file). While you could also create an additional thread from within the WinApp, you would have an issue with console I/O and with initialization of FORTRAN. It would be easire for debugging to use the dual app approach since you can make the console window visible during test. Jim Dempsey

[Chris_G_2]

Jim, Thanks for this. Steve: this would work OK wouldn't it, and it would not create a console window? (Whatever I do her, the console window is a no-no!) Chris

[Steven_L_Intel1]

I'll need to test this - will be at least Tuesday before I can do so. I think it would work if you set the "standard handles" for the process the null device.

[Chris_G_2]

That would be really helpful. Many thanks. Chris

[jimdempseyatthecove]

>>Jim, Thanks for this. Steve: this would work OK wouldn't it, and it would not create a console window? You can create the process with a minimized window. The user would see another button on the task bar. If they click on it then they would see the console window. This too may be objectionable, but you can tell the operator that this is a status/diagnostic window that is not used during their normal operation (i.e. do not click on the button). I will writeup another (untested) hack that you can try out with little coding effort. I will be back in an hour or so. Jim

[jimdempseyatthecove]

Batery died, won't be going anywhere soon. Try compiling with OpenMP enabled (compiler and linker) Rename WinMain to WinMainMain Add WinMain(...) !$OMP PARALLEL if(omp_get_thread_num() == 0) call YourCoArrayMain() if(omp_get_thread_num() == 1) WinMain = WinMainMain(hInstance, hPrevInstance, lpszCmdLine, nCmdShow) ! all threads fall through here !$OMP END PARALLEL end function WinMain Tha above has the main thread, also team member 0 of parallel region, run YourCoArrayMain code while having OpenMP team member 1 of thread team run what was formerly your WinMain As to if this hack will work or not, I cannot say. But it shouldn't take you more than 10 minutes to try out. Jim Dempsey

[Chris_G_2]

Jim, Thanks for this. I'm getting a linker error: error LNK2019: unresolved external symbol _MAIN__ referenced in function _main Do you have time to see if I have done this properly? Code enclosed. Chris

[jimdempseyatthecove]

A Windows app does not have a _main, rather it has WinMain A console app will have a _main. Therefore the message would indicate you have tried to build a console app and the linker is expecting a main. Suggestions: Line 28, "integer WinMainMain" insert in front !DEC$ IF DEFINED(USE_OPENMP) line 51+1, in front of "include 'resource.fd'" !DEC$ ENDIF Note, USE_OPENMP is your symbol, leave it NOT defined. Compile as Windows app with OpenMP enabled (compiler and linker). What you should get is your faulty program .AS. a Windows app. If this does not produce a (faulty) running Windows app then there is something wrong with your project settings. After you fix the problem of producing a Windows app, then either define USE_OPENMP or remove the conditionals. Jim Dempsey

[jimdempseyatthecove]

Once you solve the WinApp issue you will have another issue to deal with. The system in which you launch this application, the operator will expect the dialog boxes. On the other systems, the operator will get annoyed at any dialog boxes popping up. You will have to add code to detect if your instance is not the main instance, and if so, do not launch the dialogs. Jim Dempsey

[Chris_G_2]

Jim Thanks. I have done all this and it compiles OK. However, the co-array code won't work. It's the same problem I had before: num_images()=0, and this_image() always=1 I guess this is a non-starter? Best wishes Chris

[Steven_L_Intel1]

Again, you need to have a Fortran main program compiled with /Qcoarray so that it can do the MPI "launch". Without that, you'll get the results you see,

[Chris_G_2]

I thought I had done this - will double check! Chris

[Chris_G_2]

I've checked: I have a single program for doing this and it is all compiled with /nologo /debug:full /Od /Qparallel /Qopenmp /standard-semantics /Qcoarray:shared /warn:interfaces /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc90.pdb" /traceback /check:bounds /libs:static /threads /dbglibs /winapp /c I can't see any OpenMP options for linking on my version of the Intel compiler (v12.0), but the compiled program seems to be linked OK since it recognises the OpenMP directives correctly. I have written a simple program that reads an array(:,:) and averages it. (It mimics what I am trying to do in real life quite well.) The code works fine until it hits the avarage() subroutine where coarrays are used for the first time: num_images() is zero at this point which is my originial problem. I apologise for being such a pain! Maybe I should re-code using OpenMP. Would this work?