Running debug SPEC version (dspec)

[jloizu]

Running dspec in both IPP and PPPL gives execution error of the kind:

INIT = 'S', but N and TRIGN array incompatible. ABNORMAL EXIT from NAG Library routine C06FUF: IFAIL = 5 ** NAG hard failure - execution terminated

[SRHudson]

Hi, I will try to debug this. Which "branch" of SPEC is this on? Do I need to execute:

git pull origin master to get the appropriate source, and do you have an example input?

[jloizu]

I think that the files have been reverted so that for now only the branch NAG_REPLACE should have this problem (@lazersos can you confirm?). I would try something like:

git checkout NAG_REPLACE git pull -u origin NAG_REPLACE make dspec ./dspec l2stell.sp

where l2stell.sp is the input file in the TESTCASES folder.

[lazersos]

@SRHudson @jloizu I did some digging yeasterday, but wasn't able to solve it. The problem exists for all branches of the code (although the NAG_REPLACE branch may no longer exhibit it, given @jbreslau recent mods). The issue specifically comes from the subroutine invfft in numrec.h. The behavior is as follows. When compiled in 'release' mode (xspec), no error is reported. When compiled in 'debug' mode (dspec), an error arrises from the call to NAG subroutine C06FUF. The specific error is: ** INIT = 'S', but N and TRIGN array incompatible. ** ABNORMAL EXIT from NAG Library routine C06FUF: IFAIL = 5 ** NAG hard failure - execution terminated However, that's as far as I got. For reference I'm compiling use the Layhey-Fujitsu compiler.

[SRHudson]

Sorry for not being in touch earlier. Presently my office is being painted and fitted with new carpet, the PPPL computer security have changed the authentication process, my home computer is so out-of-date that I cannot even download "NoMachine", and so on and so on, and I even have an injured knee so that it is hard to walk. Anyway, the problem is really easy to fix . . . (I think.)

I am working on it now, but let me tell you what I think the problem is. In the Makefile, my original idea was to have DFLAGS blank and to compile using RFLAGS + DFLAGS. Note that DFLAGS is not a substitution for RFLAGS. DFLAGS should be thought of as a suffix to RFLAGS. Then, if the user wanted to add additional debugging flags they could so by using the command line over-ride feature on make. e.g.

make dspec DFLAGS="-D DEBUG" would be a command-line over-ride of the internal setting of DFLAGS.

This was a flexible way of changing the compilation options without changing the Makefile. I like to have this flexibility. For example, I might be testing a new part of code. In the source I would enclose the new code with

ifdef NEWCODE

endif

for example, and then I would make using make dspec DFLAGS="-D NEWCODE". The Makefile would then compile everything with RFLAGS+"-D NEWCODE".

In the new Makefile, I see that the dspec is compiled with DFLAGS, and not with RFLAGS + DFLAGS. I think that this is the problem.

In particular, it seems that dspec is not being compiled with the appropriate flags that extend single precision reals to double precision. This will really screw the NAG routines.

I will proceed to make the changes to the Makefile. This might take an hour or so before I am through checking that the above comments are correct.

I also see that the object files etc. have been renamed depending on they are the "release" version orf the "debug" version, which seems like a good idea. Previously I had to delete all the object files when I would recompile with different flags.

[lazersos]

@SRHudson That would do it. There double precision flag was missing. Adding it back in fixed everything. I've updated the Makefile for all available compilers in the profile branch and committed it.

[jloizu]

OK, I will pull, compile and test that last version of the profile branch. If that works, and it also works in pppl (i.e., the debug SPEC version runs well) then we can close this issue.

[SRHudson]

Ok, changing DFLAGS to RFLAGS+DFLAGS in the Makefile seems to be working for me.

I am becoming more and more familiar with git each day, but still I am unsure how to proceed with all the branches. I am working in master. The changes that I made were almost trivial.

I have

git commit -am "changed DFLAGS to RFLAGS + DFLAGS in Makefile;" Next I think I need to git push origin master Is this correct?

Also, I have a question regarding the Makefile. On execution you will notice screen output such as

   :  compiled  : date    = Wed Jul 26 10:19:22 EDT 2017 ; 
   :            : dir     = /u/shudson/Gits/SPEC ; 
   :            : macros  = macros ; 
   :            : f90     = /usr/pppl/intel/11.0/081/bin/intel64/ifort ; 
   :            : flags   = -r8 -mcmodel=large -O3 . . . . 

This information is built into the executable on compilation, and I enable this using awk statements and you will see all the appropriate "source" in the Makefile. This is a nice feature, but it might be complicated and lead to problems in the future. You might see that I have also included timing variables for each subroutines, Tfiles, and input logical variables, Wfiles. The timing variables are probably irrelevant. I included these so that I could check exactly how long each subroutine was taking, but as you know there are better ways of doing this (that I didn't know how to use). Eliminating these will make the source shorter and easier to read. The input logical variables, Wfiles, I think are very useful. They enable detailed control of the screen output, and this is very useful for debugging.

Anyway, no action on these matters is required at present. I just thought I would mention to you why they are included so that we could make a group decision on whether to include this extra stuff in the Makefile or to delete it for simplicity.

[jloizu]

I tested the version committed by @lazersos on the profile branch and dspec runs now well.

Stuart, I would recommend NOT working on the master branch directly, always creating first a branch in which to make changes, commit, push, test, and then and only then merge to the master.

Also, it seems that both @SRHudson and @lazersos have resolved this "debug-spec-issue". However, the modifications of @lazersos may be more meaningful since I can imagine situations in which RFLAGS contains flags that are not wanted when compiling the debug-version, and so RFLAGS+DFLAGS may not be suitable in that case.

Anyway, we should decide upon one strategy.

[SRHudson]

Hi,

I did not push my changes, so there should be no conflict.

In future, I will create or contribute to an existing branch for making changes, etc. and only merge to the master when I am confident . . .

I am happy to let Sam take control of the Makefile. He has more experience operating codes on different compilers etc. My comments above were to explain my motivation for including some of the make features (such as identifying the time of compilation) were just to share information. It is probably a good idea to work towards having an easy-to-read Makefile that conforms to usual standards.

My next task is to work on ma00aa.h as we discussed in a different branch. I guess that this issue can now be closed? I will let someone else close this.

[jloizu]

OK then. Seems like this issue can be closed (and will be resolved in practice when the profile branch merges into the master).

Closing.