1. Einstein Toolkit Avatar Einstein Toolkit
  2. Einstein Toolkit
  3. tickets
  4. Issues

Lorene: compilation error when using -warn all

Issue #1567 closed
Bruno Mundim created an issue

If I add the warning flag to fortran flags in my configuration option list, i.e.:

F77_WARN_FLAGS = -warn all F90_WARN_FLAGS = -warn all

Lorene's compilation abort with the following error messages:

... fcir2s.f(216): error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [NDEG1] CALL CIRX2S(NDEG1,NDIMR,NN64,ITCH,IDR,IND,C64,CC,CS,DENT) -------------------^ fcir2s.f(240): error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [NDEG1] CALL CIRX2S(NDEG1,NDIMR,NN64,ITCH,IDR,IND,C64,CC,CS,DENT) -------------------^ ...

gr2p3s.f(719): error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic. [SOM] CALL EXRM1S(NR,NDR,1,1,0,IPP,CC,VA1) -------------^ gr2p3s.f(720): error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic. [SOM] CALL EXRM1S(NR,NDR,1,1,1,IPP,CC,DE1) -------------^

The first compilation error above indicates that NDEG1 is an array with dimension 2 in the calling subroutine FCIR2S while NDEG has dimension 3 in the called subroutine CIRX2S. A suggestion to work around this issue can be found at:

http://software.intel.com/en-us/forums/topic/299025

and it boils down to make them both of the same dimension. Would you suggest a different workaround? Maybe make the dummy array dimension a (*)?

Regarding the second type of error above, I am not sure yet which argument is actually causing trouble. My local version of Lorene indicates different line number than the error line above but essentially the difference between the calls that the compiler complaints and the ones it doesn't is the following:

grep -i -n EXRM1S gr2p3s.f

gr2p3s.f:694: CALL EXRM1S(NR,NDR,LF1,1,0,IPP,CC,C64) gr2p3s.f:695: CALL EXRM1S(NR,NDR,LF1,1,1,IPP,CC,UGRAV) gr2p3s.f:718: CALL EXRM1S(NR,NDR,1,1,0,IPP,CC,VA1) gr2p3s.f:719: CALL EXRM1S(NR,NDR,1,1,1,IPP,CC,DE1)

On lines 694 and 695 there is no complaint from the compiler. While lines 718 and 719 do. So the dummy argument LF1 seems to prevent this compilation error in an earlier call. In any case, do you have any idea on how to fix this?

Note that a workaround I found was to disable the compiler check for the subroutine interfaces by adding the following flag:

F77_WARN_FLAGS = -warn all -warn nointerfaces F90_WARN_FLAGS = -warn all -warn nointerfaces

However I would rather have this issue addressed than let it go silently. Besides it might affect other fortran codes in ET which I haven't had the opportunity to investigate yet. I have posted a message on Lorene mailing list about this issue. If I don't hear from them, maybe we should come up with a patch on our own. Could someone more familiar with Lorene inner workings come up with a suggestion for this patch? I could work on it and test it.

Thanks, Bruno.

PS: I found this article useful: http://software.intel.com/en-us/blogs/2009/03/31/doctor-fortran-in-ive-come-here-for-an-argument

Keyword: Lorene
Keyword: ExternalLibraries

Comments (10)

  1. Erik Schnetter
    • removed comment

    The thorn Lorene contains a copy of the Lorene library http://www.lorene.obspm.fr; the Einstein Toolkit collaboration does not maintain this code.

    To address this issue, I would first update to a more recent version of Lorene, and if the error is still present there, would discuss this with the authors of Lorene. What you describe -- the mismatch of array sizes -- seems like a genuine bug that should be corrected, as you say.

    I don't think it's worthwhile to use () to "fix" this problem. Either we don't want to spend the time, and then not using "-warn all" would "solve" the problem just fine, or we need to find out what is wrong and correct the code. Using () would not do that.

  2. Bruno Mundim reporter
    • removed comment

    Hi Erik,

    thanks for your reply! I contacted the lorene developers yesterday through their mailing list and Jerome Novak addressed this issue. I have already tested successfully the newer version as a standalone code. I plan on testing it now as part of ET. I am not sure what is the path I should take to bring Lorene from its CVS repo to the ET distribution tar ball. I will look into this now, test it and propose the patch later here.

    Regarding the "-warn all" flag, I think it is useful to have it set. I wouldn't have caught this issue without it and it might help catching similar issues with ET thorns. The only thing I find strange is that this flag actually caught a code error. Why the compiler would choose not checking on the Fortran interfaces without the "-warn all" flag if it actually leads to wrong or dangerous code, I don't really know.

    Cheers, Bruno.

    Thanks, Bruno.

  3. Bruno Mundim reporter
    • removed comment

    Two of the patches provided by ET failed when patching the newest version of Lorene:

    patch -p0 < des.patch
patching file Lorene/C++/Source/Bin_hor/binhor_hh.C
patching file Lorene/C++/Source/Isol_hor/init_data.C
patching file Lorene/C++/Source/Time_slice/tslice_conf_init.C
Hunk #1 succeeded at 225 (offset 2 lines).
Hunk #2 succeeded at 238 (offset 2 lines).
Hunk #3 succeeded at 246 (offset 2 lines).
patching file Lorene/C++/Source/Time_slice/tslice_dirac_max_evolve.C
Hunk #1 FAILED at 673.
Hunk #2 FAILED at 695.
2 out of 2 hunks FAILED -- saving rejects to file Lorene/C++/Source/Time_slice/tslice_dirac_max_evolve.C.rej


patch -p0 <  pgplot.patch
patching file Lorene/C++/Makefile
Hunk #1 FAILED at 40.
1 out of 1 hunk FAILED -- saving rejects to file Lorene/C++/Makefile.rej

    I will try to fix them, but I would appreciate if the author of these patches could let us all know what these patches are about.

    Cheers, Bruno.

  4. Frank Löffler
    • removed comment

    I am not the author, but it looks like they remove two features in LORENE that are not needed in the ET, and which don't build on all systems.

  5. Bruno Mundim reporter
    • removed comment

    Thanks! It seems most of the patches are to avoid calls to a graphics device which I suspect is provided by pgplot which is really not widely supported. I am working on a patch fixing these patches. Let's see if it will work fine.

  7. Bruno Mundim reporter
    • removed comment

    Please let me know if the attached patch is good to be applied to the trunk and Noether release.

    Thanks, Bruno.

  11. Log in to comment
Assignee
–
Type
bug
Priority
minor
Status
closed
Component
EinsteinToolkit thorn
Milestone
ET_2014_05
Version
ET_2013_11
Votes
0
Watchers
0
Jira Software: the preferred issue tracker for Bitbucket. Join the team!