Opened 9 years ago

Closed 9 years ago

#627 closed help (fixed)

Compilation error with continuation lines

Reported by: luke Owned by: lois
Component: UM Model Keywords: fortran continuation line, compiler
Cc: emxin, ros Platform:
UM Version: 7.3

Description

Hello,

Xin in Cambridge is having problems compiling UKCA code on HECToR phase2b. The errors are all in files which compiled correctly last week, but since the 20th May have been having issues with fortran 90 continuation syntax - all the complaints are about & symbols in the argument list of the subroutine.

The error is first shown in the first line e.g.

SUBROUTINE asad_flux_put_stash(&

with the error:

pathf95-197 pathf90-3.2.99: ERROR ASAD_FLUX_PUT_STASH, File = /work/n02/n02/emxin/um/xfwgc/umbase/sr
c/UM/atmosphere/UKCA/asad_chem_flux_diags.F90, Line = 2757, Column = 36

Unexpected syntax: "dummy-arg-name" was expected but found "EOS".

following this line is an #include statement to argsts.h, which have &s as the first character of a line. Deleting this character from the include file causes the code to die elsewhere in the same way.

Has this behaviour been noticed before? Could there have been some system changes to HECToR, or hand-edit/UMUI changes which have made the fortran compiler behave differently? Is the solution simply to edit all the include files?

Any help would be appreciated!

Thanks,
Luke

Change History (10)

comment:1 Changed 9 years ago by lois

  • Owner changed from um_support to lois
  • Status changed from new to assigned

Hello Luke,

I don't think this is a problem with HECToR, there have been no changes and everyone else is working fine. I think it is a problem of editing files on a PC and then using them on Unix systems. We used to use the dos2unix command to change the carriage return character that Unix could not interpret. So my suggestion would be for Xin to see if he can change back to how he was editing files before the 20th May.

Let us know if we can help further with sorting this out.

Lois

comment:2 Changed 9 years ago by luke

Hi Lois,

Xin has been using vim on PUMA to edit files, and he has not changed how he edits them. Using emacs seems to result in the same issues. I'm attempting to replicate.

Thanks,
Luke

comment:3 Changed 9 years ago by willie

Hi Luke,

The problem seems to be with the include file argd1.h. If you delete the include line and enter the contents by hand it works fine. So probably some strange characters in the file. The simplest ting would be top clear out the file and type it in again.

Regards,

Willie

comment:4 Changed 9 years ago by willie

Hi Luke,

yes, if you use the command 'od -c <file>' you can see that there is a strange character in the file.

Regards

Willie

comment:5 Changed 9 years ago by luke

Hi Willie,

I've not used od - thanks for pointing that out to me! However, I have a near similar job which has the same problem in the argd1.h file

  0000000   !       A   R   G   D   1       s   t   a   r   t  \n        
  0000020                   !       I   N   /   O   U   T   :   A   d   d
  0000040   r   e   s   s   i   n   g       o   f       D   1       &    
  0000060   D   1       a   r   r   a   y  \n                       &    
  0000100       D   1   _   A   D   D   R   ,   D   1   ,   L   D   1   ,
  0000120   I   D   1   ,                                                
  0000140                                                                
  *
  0000200       &  \n   !       A   R   G   D   1       e   n   d  \n
  0000217

as Xin's has, but this works fine (in fact, a large number of the header files have this * character in it). Also, Xin hasn't touched these files, but the code has stoped compiling. My job using my branch compiles and runs, but my copy of Xin's job dies in the same way. Could a problem with a different file (i.e., apparently unconnected with the file being compiled) be causing the compiler to fall over in this way? I'm still playing around with my copy of his job, but I was wondering/hoping if anybody else has seen this before…?

Thanks,
Luke

comment:6 Changed 9 years ago by luke

Looking further into the code, it seems like the .svn directory is missing from the UKCA directory in src/atmosphere, and it also seems to be missing on my checked-out copy of Xin's branch (at an earlier revision). All other directories in atmosphere have the .svn directory. Could this be causing the problem? If so, how can it be corrected?

comment:7 Changed 9 years ago by ros

  • Cc ros added

Hi Luke,

I've managed to compile a copy of Xin's job without his working copy included so it is definitely something in the working copy that is causing a problem. Unfortunately, Xin hasn't committed his changes back to the repository for over 7 weeks which is making this harder to diagnose. It's always advisable to regularly commit changes back to the repository so it's possible to revert to an earlier version if needed. Is there a working copy anywhere that doesn't have all the include file changes to remove the &s so that we can regenerate the original error? I also notice that there are 'backup' copies of the include/argument directory which may also be causing FCM some confusion as it now has 2 copies of some of the include files.

Missing the /src off the end of the branch names causes compilation errors, so it is very probably that a missing .svn directory would cause similar symptoms. I'll take a look and see if I can see what's going on.

Cheers,
Ros.

comment:8 Changed 9 years ago by ros

In answer to your question re getting the .svn directory back.

If you do a clean checkout of Xin's branch you will get a .svn directory in the UKCA directory.

The only way, that I can think of, to get the correct .svn directory back into Xin's working copy, is for him to checkout a clean copy of his branch from the repository and then copy the contents of his UKCA directory into this newly checked-out version. It must be a 'cp' of the files into the directory and not a 'mv' of his UKCA directory.

comment:9 Changed 9 years ago by luke

Hi Ros,

Thanks for your help - I think we have the problem under control now. We took a new checkout of the code and manually copied the files in, and it's got past the previous compilation problem now!

Thanks to everyone for their help! I now know what might happen if the .svn directory goes missing!

Thanks,
Luke

comment:10 Changed 9 years ago by ros

  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.