Problem with an old fortran program on a new machine

[gerges__joseph]

Hello ,

I'm a noob in fortran

I used to use an old fortran program on a unix machine (5 Years ago)

I'm tryig to reuse now on a windows machine. I'm trying to compile it in vain (usign ifort .in an intel compiler using : ifort mkmodel.f)

I know i should use fft libraries but i don't know how.

This is the program i'm trying to compile.

Thanks in advance

[Steve_Lionel]

It builds fine for me. What errors are you seeing? Please paste in the exact and complete text of the error messages.

[mecej4]

You wrote that you needed to use FFT libraries, but I don't see why. The code can be compiled and linked with any Fortran compiler on Windows or Linux, with a minor correction: replace the format descriptor X with 1X in a couple of WRITE statements (this is not needed for Intel Fortran 19.1).

If you need more help, state how you attempted to compile and link the code, and report any error messages that you saw.

[gerges__joseph]

Thank you for the reply.

When i compile with gfortran and i launch the code with an input file (see joint file) i get this error:

'''''''''''''''''''''''

jgerges@JGerges:/mnt/c/Users/jgerges/Desktop/research/oxylene$ mkmodel_opls.x <mxylene_cx.def
 make CONFIG & FIELD for DL-POLY
 VERSION 2
 Output dl-poly config : CONFIG
 Output dl-poly field  : FIELD
 ########
 # cx mxylene  12 sites (2 CH3 super atoms)
 #  meta xylene  K.Shankland
 ########
 mxylene
       a       b       c   alpha    beta   gamma mx my mz Z spe
  10.516   7.596  16.868  90.000  90.000  90.000  3  3  3  4  1
 Box =
  10.51600   0.00000   0.00000
   0.00000   7.59600   0.00000
   0.00000   0.00000  16.86800

 Force Field = OPLS_
Rescale 1-4 interaction factor =  0.50 0.50
... Physical Unit Read = kcal

 SPEC : mxylene1              12
 atom        x        y        z     mass        q
At line 218 of file mkmodel_opls.f (unit = 5, file = 'stdin')
Fortran runtime error: Bad integer for item 2 in list input

Error termination. Backtrace:
#0  0x7f4f4743b31a
#1  0x7f4f4743bec5
#2  0x7f4f4743c68d
#3  0x7f4f475a8924
#4  0x7f4f475abc1a
#5  0x7f4f475ad0f9
#6  0x7f4f47c0e23c
#7  0x7f4f47c15071
#8  0x7f4f46ca1b96
#9  0x7f4f47c00db9
#10  0xffffffffffffffff

''''''''''''''''''''''''

When i compile using the intel compiler 19.1 (using ifort mkmodel-opls.f). I get an .exe file , that gives me nothing when i launch it.

Thnaks in advance;

Joseph

[mecej4]

Is the input file inputfile.txt in #4 the same as mxylene_cx.def as to contents?

Your program attempts to open the file /mnt/c/bin/FF/ff.list. Obviously, that file cannot exist in a Windows file system. Secondly, you need to provide that file.

The program has several large arrays, dimensioned (2, 999999, 9); as a result, a 32-bit EXE built out of this source file cannot be run. Such arrays, if unnecessarily large, can also hinder debugging the early versions of the program. For the input files that you are using, perhaps the 999999 can be replaced by something smaller?

[gerges__joseph]

Yeah , the input file is the same as mxyene ...def , i changed the format that i can uploade it (no .def is permitted.)

For the ff.list file , it does exist in the in  /mnt/c/bin/FF/ff.list .

The .list and .def files are not supported by windows ?

[mecej4]

When you ask for help with errors related to formatted input files, it is almost essential that you provide those input files. In this case, you should provide the file ff.list to forum readers if you want their help.

On your Windows system, that file must exist in the correct directory, i.e., one that is used in the OPEN statement for the file and consistently with Windows relative path conventions. In addition, the file should contain the correct data that your program needs and expects.

You can give your files any suffixes (such as .def, .list, etc.). Windows does not limit you as to suffixes.However, the software that runs this forum has some restrictions on file attachments. The simplest solution is to zip up all relevant files (source files, data files, instructions to build, batch files, etc.) and attach the zip file. If the zip file is very big, an alternative is to upload the zip file to a cloud account (Google Drive, Dropbox, etc.), enable public access to the uploaded zip file, and post a link to that file in a post in this forum.

[gerges__joseph]

Well noted;

I hereby send you the zip file containing the program, the input file and the FF file containing the ff.list and other files used in the program.

Best regards ;

Joseph

[Steve_Lionel]

I will note that your original problem description is incorrect - you aren't having any problem compiling this program.

[gerges__joseph]

Indeed, i changed the original title.

Best regards

Steve Lionel (Ret.) (Blackbelt) wrote:

I will note that your original problem description is incorrect - you aren't having any problem compiling this program.

[mecej4]

Here is the first input data error, on encountering which execution gets terminated (I tried four different compilers, getting the same termination point).

Line 217 of the source file contains:

            READ(*,*)
     $      CHEM_MMTK(IA,J), III,XK,YK,ZK,READ_Q,READ_ATOM,IREAD_VDW

The current input record, which is line 11 of the input file mxylene_cx.def, contains:

ca 0.5912754343 0.2289565419 0.2673319390 -0.11500 CA  145

The READ statement expects to read 1) the label CHEM_MMTK(IA,J), 2) the integer III, 3) etc.

The second field in the input record contains a decimal point, which is invalid for the integer value expected to be read into III.

It is possible that other errors occurred earlier, causing the wrong number of lines to be read. You will have to work your way through all the previous READ statements (in execution order, not necessarily by line number in source file), matching each READ to the data in the input file. We cannot help you with this part, since we do not know much about the technical domain that the program is related to.

In order to allow me to verify the program behavior using several different compilers, I replaced PARAMETER(N=999999) by PARAMETER(N=9999) throughout the program, and that did not seem to cause any problems. However, it would be a good idea to provide a reasonable value for N and add code to check if the input data is such that this value of N is sufficiently large.

A more modern way of handling this issue is not to declare fixed size arrays, but to use allocatable arrays. After reading part of the data input, the required value of N for that data set will have been defined, and that value could be used to allocate all the necessary arrays at that point.

[FortranFan]

gerges, joseph wrote:

.. I'm a noob in fortran ..

@gerges, joseph,

Given your statement in the original post and how the rest of the thread is going, you may find it helpful to review Fortran in books such as this one for a good introduction, https://www.amazon.com/FORTRAN-SCIENTISTS-ENGINEERS-Stephen-Chapman/dp/0073385891.

And if you're interested in advanced topics, you'll find the books in Dr Fortran Steve Lionel's blog very useful: https://stevelionel.com/drfortran/2013/12/30/doctor-fortran-in-its-a-modern-fortran-world/. 

Note Fortran is a relatively easy language to learn, you'll find just a few hours of focus on structured material like in a book more helpful in meeting your program needs by yourself than it takes in a lot of back and forth on forums constrained by the limited information one undoubtedly tends to type up in an original post or in subsequent comments describing what one is trying or seeks with their program(s).

[gerges__joseph]

Thank you. I was able to fix this problem by eliminating the III (there was a mismatch between the code and the input file).

However, another porblem occured. It appears that fortran is adding unecessary tabs in the path. See the following error:

Fortran runtime error: Cannot open file '/mnt/c/bin/FF       OPLS_/masse.tab': No such file or directory

As you can notice between FF and OPLS there is a space that is not detected in the source code. (note the mass.tab does exist in the OPLS_ folder)

Have you ever seen this prolem ?

Thank you again .

mecej4 (Blackbelt) wrote:

Here is the first input data error, on encountering which execution gets terminated (I tried four different compilers, getting the same termination point).

Line 217 of the source file contains:

            READ(*,*)
     $      CHEM_MMTK(IA,J), III,XK,YK,ZK,READ_Q,READ_ATOM,IREAD_VDW

The current input record, which is line 11 of the input file mxylene_cx.def, contains:

ca 0.5912754343 0.2289565419 0.2673319390 -0.11500 CA  145

The READ statement expects to read 1) the label CHEM_MMTK(IA,J), 2) the integer III, 3) etc.

The second field in the input record contains a decimal point, which is invalid for the integer value expected to be read into III.

It is possible that other errors occurred earlier, causing the wrong number of lines to be read. You will have to work your way through all the previous READ statements (in execution order, not necessarily by line number in source file), matching each READ to the data in the input file. We cannot help you with this part, since we do not know much about the technical domain that the program is related to.

In order to allow me to verify the program behavior using several different compilers, I replaced PARAMETER(N=999999) by PARAMETER(N=9999) throughout the program, and that did not seem to cause any problems. However, it would be a good idea to provide a reasonable value for N and add code to check if the input data is such that this value of N is sufficiently large.

A more modern way of handling this issue is not to declare fixed size arrays, but to use allocatable arrays. After reading part of the data input, the required value of N for that data set will have been defined, and that value could be used to allocate all the necessary arrays at that point.

[Steve_Lionel]

No, it's not adding tabs. Please attach a ZIP of your latest source so we can take a look.

[gerges__joseph]

Steve Lionel (Ret.) (Blackbelt) wrote:

No, it's not adding tabs. Please attach a ZIP of your latest source so we can take a look.

[gerges__joseph]

Their you go

Thank you

Steve Lionel (Ret.) (Blackbelt) wrote:

No, it's not adding tabs. Please attach a ZIP of your latest source so we can take a look.

[Steve_Lionel · Accepted solution]

Never mind - I see what you did in your earlier upload.

You have this in routine FF_PARAM:

C       FORCE_FIELD
        FF_file(1:20) = '/mnt/c/bin/FF'
        FF_file(21:25) = FF
        FF_file(26:26) = '/'
        FF_file(27:31) = INTRA_PROP
        FF_file(32:35) = '.tab'

That first assignment will insert 7 blanks after the 'FF', since the value is 13 characters and the substring is 20.

[gerges__joseph]

wow, thanks for the advice:

i changed this part to :

C       FORCE_FIELD
        FF_file(1:14) = '/mnt/c/bin/FF/'
        FF_file(15:19) = FF
        FF_file(20:20) = '/'
        FF_file(21:25) = INTRA_PROP
        FF_file(26:29) = '.tab'

It gives me this result : 

/mnt/c/bin/FF/OPLS_/masse.tab?'

How can i get rid of the final '?' after the tab ?

Great thanks for your help

Steve Lionel (Ret.) (Blackbelt) wrote:

Never mind - I see what you did in your earlier upload.

You have this in routine FF_PARAM:

C       FORCE_FIELD
        FF_file(1:20) = '/mnt/c/bin/FF'
        FF_file(21:25) = FF
        FF_file(26:26) = '/'
        FF_file(27:31) = INTRA_PROP
        FF_file(32:35) = '.tab'

That first assignment will insert 7 blanks after the 'FF', since the value is 13 characters and the substring is 20.

[Steve_Lionel]

Add before these lines:

FF_file = ''

[GVautier]

Hi
 

FF_file='/mnt/c/bin/FF'
FF_file(len_trim(FF_file)+1:)=FF
FF_file(len_trim(FF_file)+1:)='/'
FF_file(len_trim(FF_file)+1:)=INTRA_PROP
FF_file(len_trim(FF_file)+1:)='.tab'

or

FF_file='/mnt/c/bin/FF'//FF(1:len_trim(FF))//'/'//INTRA_PROP(1:len_trim(INTRA_PROP))//'.tab'

would be safer.

[Steve_Lionel]

I would use trim(FF), etc., rather than the more awkward use of len_trim, but the basic idea is good.