i am trying to write a code for visualization of the data generated from 3D-MHD turbulent flow (pseudo spectral code)simulations.
the aim of this code is to create a .avsdat file which could be visualized using VISIT visualization software.
my code works well on intel13/composer_xe_2013.1.117, other higher versions of parallel studio give many errors.
i am using fftw/2.1.5_intel13 and mpich-220.127.116.11/ (just incase you want this info)
i have a lot of macros in the first part of the code, then the Program starts ( Code file attached).
when i compile this code... i get the following error stating from the the main program avsgen starts (line 153) and the "error is #6236 A specification statement cannot appear in the executable section" and this continues upto line 192.
then a warning "warning #6717: This name has not been given an explicit type." starts for every variable used in the Macro starting from line 71 and the compilation exits.. informing that there are too many errors.
i have tried all the previous solutions that were specified for this error on this forum.. but could not resolve the problem.
hence this post... to request a possible solution...
P.S.: this code used to work well on Aix, ifort of 2009 (when i was doing my phd) on IBM power 6 machine.. generating the necessary .avsdat files..
i now have a 2 node cluster built with 2 processors of Intel® Xeon® Processor E5-2630 v4 on master node and 16 of the same processors in the servant nodes .
thanking you in advance,
with best regards,
Shiva Kumar. Malapaka
the example that you provided is not complete. There are some input files (_param_ most likely, maybe also mpi.h) which are not provided. Hence, there are some declarations missing. In this way, we cannot compile your example.
i have provided the _param_ file in the forupload.zip...
mpif.h (thats seen in ns_mod.f90) is a standard file in /mpi/mpich/3.2.1/intel/2018/include/
hope you can use this info...
if you want i can try and attach the mpif.h
with best regards,
Nope, doesn't compile:
ns_mod.F90(97): error #6404: This name does not have a type, and must have an explicit type. [MY_PE] my_pey = Mod(my_pe(),1) -----------------------------^ ns_mod.F90(97): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [MOD] my_pey = Mod(my_pe(),1) -----------------------------^ ns_mod.F90(97): error #6363: The intrinsic data types of the arguments must be the same. [MOD] my_pey = Mod(my_pe(),1) -------------------------------------^ ns_mod.F90(97): error #6404: This name does not have a type, and must have an explicit type. [MOD] my_pey = Mod(my_pe(),1) -------------------------^ compilation aborted for ns_mod.F90 (code 1)
are you doing a Make (using the part for Linux)...
if you try to compile from command line... there will be issues as far as i know...
The Makefile seem to demand mpiifort which I don't have. Don't you have a minimal example that exhibits the problem? Otherwise you should contact the authors of the code and ask them.
i am one of the authors of the code. this code used to work well in 2009. i am now trying to re-use this code.. and getting the specified error and warning messages.
i do not have any simple piece of code showing the same errors... hence i could not provide that...
sorry about that
This sounds like an issue of an extension or standard violation that passed 10 yrs ago, but now compilers are stricter. What about serial compilation? What about other compilers?
That is a strong signal that the code might not be standard-compliant Fortran but is either using some compiler-specific extension or was relying on a compiler-specific bug (e.g. accepts-invalid).
it will take a lot of time to re-do the whole code... to comply with new Fortran compilers... so trying to fix this error..as the rest of the code (that was written in 2009 is doing fine and generating the necessary data !)
You wrote a code that worked ten years ago, which using a lot of preprocessor magic and compiler specifics, you didn't (apparently) continuously maintain your code, and now you expect somebody to debug it for you. What is the exact error message? To which line does it point? Start continuously commenting out more and more parts of your code in order to isolate the error.
Well Juergen.. i have completed all those steps.. and was unable to solve the error... hence i turned for help in this forum.
i presented the full code and attached all the other necessary files including the make file so that any other developer/ expert can see the problem; which is eluding me from some time ; in its full sense and probably give me a idea/ guide me on how to go about for the solution...
thats where i stand.. (by the way this problem has been with me for past 1.5 months and i have searched all the old threads but did not find any macros related issues... hence titled the problem as "Error #6236 in a code with Macros"...
Your makefile is broken: the symbol FF is never defined, so it is a null string, as you can see by using the command make -n or make -n ns_mod.o . As Juergen pointed out, your usage of IMPLICIT NONE and not declaring the type of my_pe makes the source file ns_mod.F90 impossible to compile after preprocessing by the GNU cpp preprocessor.
If you wish to take some non-standard Fortran source and pass it through an unsupported macro processor, you are responsible for checking all your user-defined macros and that the output Fortran source is standard-conforming, and to write a makefile that results in the correct commands to be issued. If the macro expansion depends on the quirks of a specific preprocessor (e.g., the AIX preprocessor) to work, you have to do the preprocessing on that platform and move the output file to Linux.
In contradiction to what you said, your problems have no recognizable connection to the version number of the Intel compiler. The makefile does not even cause a Fortran compiler to be called.
It may be time to pause and ask the question: "Is my reliance on macros and preprocessing causing more troubles than the savings (in lines of code)?"
I added integer, external :: my_pe to your ns_mod.F90, and Ifort 19U4 compiled the file fine on Windows with the command
ifort /Od /fpp /c ns_mod.F90 .
i do not understand .. my_pe is defined on line 46 of ns_mod.F90 and is not anywhere before that...
in the make file i am using the Macros for Linux and there FF is defined as FF=mpifort
and in my system.. i am able to compile the program and the error is #6236.
but thanks for the link to other forum...
hi mecje4... the same line Integer, external :: my_pe is present on line number 46.
the main problem is not in ns_mod.f90
i have trouble in avsgen file...
I do not have the same environment as you do, so I expect that many things will fail because shell expansions and macro expansions will not do what you wanted to happen.
Here is one such bug that I noticed. Lines 76-77 of avsgen1_modified.F90 read:
Call MPI_Send(localout,nxl,MPI_REAL8,0,0,MPI_COMM_WORLD,mpi_err)\ Endif;\
When these lines, which are part of a macro definition, get expanded by the Ifort FPP preprocessor, the result is
Call MPI_Send(localout,nxl,MPI_REAL8,0,0,MPI_COMM_WORLD,mpi_err)& Endif;&
To fix this output, either the terminating '&' of the first line has to be removed, or a preceding ';' inserted. Now you can see the disadvantage of using preprocessors: what are the change that I should make in the preprocessor input file to make these lines come out right?
I recommend that you send the preprocessor output to a file and carefully study that file to see if such errors are present. If, instead, you send the file through the Fortran compiler, the resulting error messages can be quite obscure and mystifying.
yes i dealt with this problem earlier...
and fixed it.. in my environment...
but i see your point of different environments...
as i mentioned in my problem definition... i am getting that error #6236.. and not these..any more.. as i could fix them myself..
As I wrote at the end of #18, you should look at the preprocessor output.
The file avsgen1_modified.F90 is missing a terminal '\' at the end of Line 70. As a result, the subsequent lines of the intended macro definition appear as statements in the output. The Fortran compiler has not seen any Subroutine, Function or Program declarations at this point, so it takes those statements as belonging to an unnamed main program. Later, it sees Program avsgen and complains that it sees two main programs.