search

firemodels / fds

Fire Dynamics Simulator
https://pages.nist.gov/fds-smv/
Other
625 stars 610 forks source link

gfortran 4.9 syntax error for !$OMP ATOMIC WRITE assignment in radi.f90 #2113

Closed gforney closed 9 years ago

gforney commented 9 years ago 
Please complete the following lines...

FDS Version: 6
SVN Revision Number: 19196
Compile Date: 14/5/14
Smokeview Version/Revision: -
Operating System: SLES 10.3

Describe details of the issue below:

% svn list -v FDS_Source/radi.f90
  18947 daniel.h        51346 Apr 13 02:27 radi.f90

% gfortran -c -fopenmp -m64 -O2 radi.f90
radi.f90:914.53:

                        WALL(IW)%ONE_D%ILW(N,IBND) = WALL(IW)%ONE_D%ILW(DLM(N,A
                                                     1
Error: expr in !$OMP ATOMIC WRITE assignment var = expr must be scalar and cannot reference
var at (1)
radi.f90:925.53:

                        WALL(IW)%ONE_D%ILW(N,IBND) = OUTRAD_W(IW) + RPI*(1._EB-
                                                     1
Error: expr in !$OMP ATOMIC WRITE assignment var = expr must be scalar and cannot reference
var at (1)

I hacked around this by replacing ATOMIC with OMP CRITICAL directives:

diff -cw ../FDS_Source/radi.f90-DIST  ../FDS_Source/radi.f90
*** ../FDS_Source/radi.f90-DIST    Tue May 13 11:05:09 2014
--- ../FDS_Source/radi.f90    Tue May 13 13:34:43 2014
***************
*** 906,935 ****
                 IF (.NOT.TWO_D .OR. ABS(IOR)/=2) THEN
                    SELECT CASE (WALL(IW)%BOUNDARY_TYPE)
                       CASE (OPEN_BOUNDARY)
!                         !$OMP ATOMIC WRITE
                          IL(II,JJ,KK) = BBFA*RPI_SIGMA*TMPA4
!                         !$OMP END ATOMIC
                       CASE (MIRROR_BOUNDARY)
!                         !$OMP ATOMIC WRITE
                          WALL(IW)%ONE_D%ILW(N,IBND) = WALL(IW)%ONE_D%ILW(DLM(N,ABS(IOR)),IBND)
!                         !$OMP END ATOMIC
!                         !$OMP ATOMIC WRITE
                          IL(II,JJ,KK) = WALL(IW)%ONE_D%ILW(N,IBND)
!                         !$OMP END ATOMIC
                       CASE (INTERPOLATED_BOUNDARY)
!                         !$OMP ATOMIC WRITE
                          IL(II,JJ,KK) = WALL(IW)%ONE_D%ILW(N,IBND)
!                         !$OMP END ATOMIC
                       CASE DEFAULT ! solid wall
!                         !$OMP ATOMIC WRITE
                          WALL(IW)%ONE_D%ILW(N,IBND) = OUTRAD_W(IW) + RPI*(1._EB-WALL(IW)%ONE_D%EMISSIVITY)*INRAD_W(IW)
!                         !$OMP END ATOMIC
                    END SELECT
                 ELSEIF (CYLINDRICAL) THEN
                    IF (WALL(IW)%BOUNDARY_TYPE==OPEN_BOUNDARY) CYCLE WALL_LOOP1
!                         !$OMP ATOMIC WRITE
                    IL(II,JJ,KK) = WALL(IW)%ONE_D%ILW(N,IBND)
!                         !$OMP END ATOMIC
                 ENDIF
              ENDDO WALL_LOOP1
              !$omp end parallel do
--- 906,935 ----
                 IF (.NOT.TWO_D .OR. ABS(IOR)/=2) THEN
                    SELECT CASE (WALL(IW)%BOUNDARY_TYPE)
                       CASE (OPEN_BOUNDARY)
!                         !$OMP CRITICAL
                          IL(II,JJ,KK) = BBFA*RPI_SIGMA*TMPA4
!                         !$OMP END CRITICAL
                       CASE (MIRROR_BOUNDARY)
!                         !$OMP CRITICAL
                          WALL(IW)%ONE_D%ILW(N,IBND) = WALL(IW)%ONE_D%ILW(DLM(N,ABS(IOR)),IBND)
!                         !$OMP END CRITICAL
!                         !$OMP CRITICAL
                          IL(II,JJ,KK) = WALL(IW)%ONE_D%ILW(N,IBND)
!                         !$OMP END CRITICAL
                       CASE (INTERPOLATED_BOUNDARY)
!                         !$OMP CRITICAL
                          IL(II,JJ,KK) = WALL(IW)%ONE_D%ILW(N,IBND)
!                         !$OMP END CRITICAL
                       CASE DEFAULT ! solid wall
!                         !$OMP CRITICAL
                          WALL(IW)%ONE_D%ILW(N,IBND) = OUTRAD_W(IW) + RPI*(1._EB-WALL(IW)%ONE_D%EMISSIVITY)*INRAD_W(IW)
!                         !$OMP END CRITICAL
                    END SELECT
                 ELSEIF (CYLINDRICAL) THEN
                    IF (WALL(IW)%BOUNDARY_TYPE==OPEN_BOUNDARY) CYCLE WALL_LOOP1
!                         !$OMP CRITICAL
                    IL(II,JJ,KK) = WALL(IW)%ONE_D%ILW(N,IBND)
!                         !$OMP END CRITICAL
                 ENDIF
              ENDDO WALL_LOOP1
              !$omp end parallel do

Original issue reported on code.google.com by adal493@nesi.org.nz on 2014-05-13 22:02:44

gforney commented 9 years ago 
Forgot to say this is on an IBM ppc64 machine.

Original issue reported on code.google.com by adal493@nesi.org.nz on 2014-05-13 22:04:54

gforney commented 9 years ago 
Daniel, can you take a look at this.

Original issue reported on code.google.com by mcgratta on 2014-05-14 12:06:59

gforney commented 9 years ago 
I'm on it. They had contacted me directly before submitting the Issue.

Could be gnarly, what with the ppc64 architecture.

Original issue reported on code.google.com by daniel.haarhoff on 2014-05-14 13:29:55

gforney commented 9 years ago 
I was mistaken. I appears that gfortran might be more strict here than ifort.

I have comitted an openmp_gnu_linux target to the FDS_Compilation folder and makefile.
This reproduced the error.

The latest commit also changes the two affected line to use CRITICAL.
This should fix the issue but doesn't explain why the two lines don't conform with
the spec. IMHO the expression only involves scalars. Maybe it is once again an issue
with the pointers to pointers to allocatables, since the other allocatables don't bother
the compiler.

From some brief profiling it seems that the introduction of critical doesn't introduce
significant changes in runtime for the loop.

@Kevin, Randy: Can we maybe add the GNU target to the daily builds? Maybe it will catch
other issues in the future. I'd also be happy to add a GNU debug target.

Original issue reported on code.google.com by daniel.haarhoff on 2014-05-20 10:53:08

gforney commented 9 years ago 
I'll ask Kris if it's possible to just do a debug compile of the GNU OpenMP just to
check for errors. Our daily verification is becoming longer and longer, so we have
to be careful to keep it to just a few hours overnight.

Original issue reported on code.google.com by mcgratta on 2014-05-20 12:35:11

gforney commented 9 years ago 
It is easy to add this to Firebot, but then we will have to maintain the GNU compilers
on blaze. This will be somewhat problematic on the version of CentOS that we currently
have, and it will be another item to maintain in addition to the Intel compilers and
other libraries that we update. I will hold off on this until after 6.1.0 is released,
and we can talk more about the best way to do this.

Original issue reported on code.google.com by koverholt on 2014-05-21 03:06:39

gforney commented 9 years ago 
This is also an issue using the pgi compiler, it also complains on the 
!$OMP END ATOMIC  directive when compiling for openmp.
As far I could understand from the documentation on openmp, the atomic directive is
only for the following statement, - so we do not need the 
!$OMP END ATOMIC statement in the code. This is just something the intel compiler does
not complain about.

I inserted a space in "! $OMP" in the lines with the !$OMP END ATOMIC to disable it.
After that the code compiled fine, - so I do not think it is necessary to replace the
atomic statement with a critical statement as done above.

/Bjarne

               IF (.NOT.TWO_D .OR. ABS(IOR)/=2) THEN
                  SELECT CASE (WALL(IW)%BOUNDARY_TYPE)
                     CASE (OPEN_BOUNDARY)
                        !$OMP ATOMIC WRITE
                        IL(II,JJ,KK) = BBFA*RPI_SIGMA*TMPA4
                        ! $OMP END ATOMIC
                     CASE (MIRROR_BOUNDARY)
                        !$OMP CRITICAL
                        WALL(IW)%ONE_D%ILW(N,IBND) = WALL(IW)%ONE_D%ILW(DLM(N,ABS(IOR)),IBND)
                        !$OMP END CRITICAL
                        !$OMP ATOMIC WRITE
                        IL(II,JJ,KK) = WALL(IW)%ONE_D%ILW(N,IBND)
                        ! $OMP END ATOMIC
                     CASE (INTERPOLATED_BOUNDARY)
                        !$OMP ATOMIC WRITE
                        IL(II,JJ,KK) = WALL(IW)%ONE_D%ILW(N,IBND)
                        ! $OMP END ATOMIC
                     CASE DEFAULT ! solid wall
                        !$OMP CRITICAL
                        WALL(IW)%ONE_D%ILW(N,IBND) = OUTRAD_W(IW) + RPI*(1._EB-WALL(IW)%ONE_D%EMISSIVITY)*INRAD_W(IW)
                        !$OMP END CRITICAL
                  END SELECT
               ELSEIF (CYLINDRICAL) THEN
                  IF (WALL(IW)%BOUNDARY_TYPE==OPEN_BOUNDARY) CYCLE WALL_LOOP1
                        !$OMP ATOMIC WRITE
                  IL(II,JJ,KK) = WALL(IW)%ONE_D%ILW(N,IBND)
                        ! $OMP END ATOMIC
               ENDIF

Original issue reported on code.google.com by bjarne.husted on 2014-10-17 11:24:57

gforney commented 9 years ago 
I removed the END ATOMIC statements and posted new source code to the repository. Let
me know if the code compiles cleanly now. We would rather you not have to make special
changes to the code in order to compile with a certain compiler.

Original issue reported on code.google.com by mcgratta on 2014-10-17 16:36:37

gforney commented 9 years ago 
Thanks for this.  radi.f90 compiles cleanly with IBM xlf2008_r but I still
needed to patch part.f90 and fire.f90 because of the OMP SHARED
and OMP PRIVATE statements - patches for this are attached.  I think that
at least this time around I'm not changing any semantics of the program.

Original issue reported on code.google.com by adal493@nesi.org.nz on 2014-10-22 02:40:19

gforney commented 9 years ago 
I think you forgot the attachments.

Original issue reported on code.google.com by daniel.haarhoff on 2014-10-22 07:16:56

gforney commented 9 years ago 
--Kevin, Thanks, I downloaded the latest version and now the radi.f90 compiles fine
with the pgi compiler 14.9. So the compilation issues for radi.f90 and pgi is solved.

I also have issues with the part.f90 file as well and the fire.f90 as mentioned in
comment #12.
One solution to part.f90 is to declare a number of variables in the private clause.

Line 2182 shown here and I added an extra line:
   !$OMP         I_BOIL,P_RATIO,T_BOIL_EFF,MESSAGE,PR_LIQUID,K_LIQUID,NU_LIQUID, &
   !$OMP         h_v_ref, pressure_zone, mu_liquid,gvec, constant_h_solid, pbar, beta_liquid,
p_stp)

Further I had to declare I as an integer.  

The additions written with small letters. So these extra variables are now declared
private. I am not sure on the implications of this for the code, but the pgi compiler
will now compile part.f90. 

Should a separate issue be opened for this?
/Bjarne

Original issue reported on code.google.com by bjarne.husted on 2014-10-23 14:33:23

gforney commented 9 years ago 
Here are the errors for the fire.f90 and the pgi compiler. 3 variables do not seem to
be declared plus 2 issues with mismatch of data type.

pgf90 -c -fast -tp bulldozer  -Mstandard -Ktrap=fp -mp ../FDS_Source/fire.f90
PGF90-S-0038-Symbol, combustion_ode, has not been explicitly declared (../FDS_Source/fire.f90:
68)
PGF90-S-0038-Symbol, reactants_present, has not been explicitly declared (../FDS_Source/fire.f90:
72)
PGF90-S-0038-Symbol, zz_min, has not been explicitly declared (../FDS_Source/fire.f90:
72)
PGF90-S-0076-Subscripts specified for non-array variable do_reaction (../FDS_Source/fire.f90:
82)
PGF90-S-0121-Operation requires logical or integer data types (../FDS_Source/fire.f90:
82)

Here are also some suggested changes to the fire.f90
Changes to line 69:
!$OMP SHARED(KBAR,JBAR,IBAR,SOLID,CELL_INDEX,N_TRACKED_SPECIES,N_REACTIONS,REACTION,COMBUSTION_ODE_SOLVER,Q,RSUM,TMP,PBAR,
&
Changed COMBUSTION_ODE to COMBUSTION_ODE_SOLVER

Line 73
!$OMP PRIVATE(K,J,I,ZZ_GET,DO_REACTION,NR,RN,REACTANTS_PRESENT,ZZ_MIN,Q_EXISTS,SM,CP,HDIFF,DZZ)
Removed REACTANTS_PRESENT. Not used here, but declared further down in the code and
declared there.  

Line 83
!$OMP DO SCHEDULE(STATIC) COLLAPSE(3)&
!$OMP PRIVATE(K,J,I,ZZ_GET,DO_REACTION,NR,RN,ZZ_MIN,Q_EXISTS,SM,CP,HDIFF,DZZ)
Removed ZZ_MIN as it is not used

Original issue reported on code.google.com by bjarne.husted on 2014-10-23 15:36:08

gforney commented 9 years ago 
I fixed these bugs and committed a new fire.f90. 

Daniel -- why doesn't the Intel compiler with -openmp catch these bugs?

Original issue reported on code.google.com by mcgratta on 2014-10-23 16:09:35

gforney commented 9 years ago 
Both part.f90 and fire.f90 shouldn't be compiled with OpenMP. Those modules are commented
out in the makefile.

When I started the rewrite I didn't remove all old OpenMP code. I only cleaned up the
files that I gradually uncommented in the makefile.

I never cleaned up part.f90 and fire.f90 because they didn't show up significantly
in my profiling.

Original issue reported on code.google.com by daniel.haarhoff on 2014-10-23 17:19:15

gforney commented 9 years ago 
Would it make sense to clean out all OpenMP constructs from fire.f90 and part.f90 and
start fresh when we decide to do it? I am very interested in ensuring that FDS can
compile with any compiler that conforms to the 2008 standard.

Original issue reported on code.google.com by mcgratta on 2014-10-23 17:22:11

gforney commented 9 years ago 
Thanks - The pgi can compile the code now with my changes to part.f90. Would someone
have time to look at those as well? See my post #14

Original issue reported on code.google.com by bjarne.husted on 2014-10-23 17:23:57

gforney commented 9 years ago 
I'd clean out all of the OpenMP statements in part and fire and remove their modules
from the OpenMP makefile section.

Since they where commented out they shouldn't have been compiled with OpenMP. Could
this be an issue with PGI and the makefile?

@bjarne: How did you compile the code? Did you use the provided makefile?

Original issue reported on code.google.com by daniel.haarhoff on 2014-10-23 17:30:55

gforney commented 9 years ago 
Sorry, I missed Comment #14. I just committed changes to part.f90. I could not find
the problem with I not being declared. Which line was that?

Original issue reported on code.google.com by mcgratta on 2014-10-23 17:35:43

gforney commented 9 years ago 
OK, I will let Bjarne try to compile one more time and then clean out the OpenMP statements
in fire.f90 and part.f90. I do not want to cause a conflict while Bjarne is updating
his local SVN repository.

Original issue reported on code.google.com by mcgratta on 2014-10-23 17:38:01

gforney commented 9 years ago 
--Daniel, - I use the provided makefile, - just modified with the -mp for openmp with
pgi and -tp bulldozer, which is the amd processor on our cluster.

When I tried to compile the part.f90 I got an error, but if the openmp statements are
going to be removed, it does not matter.

pgf90 -c -fast -tp bulldozer  -Mstandard -Ktrap=fp -mp ../FDS_Source/part.f90
PGF90-S-0023-Syntax error - unbalanced parentheses (../FDS_Source/part.f90: 2167)
PGF90-S-0023-Syntax error - unbalanced parentheses (../FDS_Source/part.f90: 2182

--Kevin, "the I not being declared". I just remembered I changed it last week, but
that could have been linked to one of the other errors in the part file.  I

Original issue reported on code.google.com by bjarne.husted on 2014-10-23 18:45:35

gforney commented 9 years ago 
I am going to remove the OpenMP statements from fire.f90 and part.f90 now.

Bjarne -- tell me the specific pgi makefile entry you use and I will change that too.
You should not have to change the entries. It is better that everyone uses the ones
that are in the repository.

Original issue reported on code.google.com by mcgratta on 2014-10-23 18:57:45

gforney commented 9 years ago 
fire.f90 and part.f90 should have no OpenMP statements now.

Original issue reported on code.google.com by mcgratta on 2014-10-23 19:02:12

gforney commented 9 years ago 
Thanks, --- the code compiles fine with the pgi compiler for both openmp and mpi. I
will do some performance tests on the cluster with the openmp version compiled with
the intel compile and the pgi compiler.

Original issue reported on code.google.com by bjarne.husted on 2014-10-23 20:14:02

gforney commented 9 years ago 
Great. Let me know if the compiler options for the PGI compiler in the file FDS_Compilation/makefile
are OK, or if we need to change them. We don't use the PGI compiler, but it would be
nice to have accurate compiler options.

Original issue reported on code.google.com by mcgratta on 2014-10-23 21:01:03

gforney commented 9 years ago 
Thanks, svn revision 20794 compiles cleanly now with IBM XL compilers (xlf2003_r and
xlf2008_r) on SLES11SP1, with just these trivial changes to the makefile:

diff -cw makefile-DIST makefile
*** makefile-DIST   Fri Oct 24 10:26:42 2014
--- makefile    Fri Oct 24 11:24:47 2014
***************
*** 371,382 ****
  mpi_pgi_linux_64 : $(obj_mpi)
    $(FCOMPL) $(FFLAGS) -o $(obj) $(obj_mpi)

! #XLF-Compiler, IBM Power6 Core, OpenMP, full optimized settings
! xlf_openmp : FFLAGS  = -O2 -qhot -q64 -qtune=pwr6 -qarch=pwr6 -qmaxmem=-1 -bdatapsize:64K
-bstackpsize:64K -btextpsize:64K -qsmp=omp
! xlf_openmp : FCOMPL  = xlf90_r
  xlf_openmp : obj     = fds_xlf_openmp
  xlf_openmp : $(obj_serial)
!   $(FCOMPL) $(FFLAGS) -o $(obj) $(obj_serial) 

  #XLF-Compiler, IBM Power6 Core, OpenMP, non-optimized setting
  xlf_openmp_nooptimization : FFLAGS  = -O0 -q64 -qsmp=omp
--- 371,383 ----
  mpi_pgi_linux_64 : $(obj_mpi)
    $(FCOMPL) $(FFLAGS) -o $(obj) $(obj_mpi)

! #XLF-Compiler, IBM Power7 Core, OpenMP, full optimized settings
! xlf_openmp : FFLAGS  = -O2 -qhot -q64 -qtune=pwr7 -qarch=pwr7 -qmaxmem=-1 -bdatapsize:64K
-bstackpsize:64K -btextpsize:64K -qsmp=omp
! xlf_openmp : LD      = xlf2008_r -O2 -qhot -q64 -qtune=pwr7 -qarch=pwr7 -qmaxmem=-1
-qsmp=omp
! xlf_openmp : FCOMPL  = xlf2008_r
  xlf_openmp : obj     = fds_xlf_openmp
  xlf_openmp : $(obj_serial)
!   $(LD) -o $(obj) $(obj_serial) 

  #XLF-Compiler, IBM Power6 Core, OpenMP, non-optimized setting
  xlf_openmp_nooptimization : FFLAGS  = -O0 -q64 -qsmp=omp

Original issue reported on code.google.com by adal493@nesi.org.nz on 2014-10-23 23:23:33

gforney commented 9 years ago 
I committed a new makefile. I changed your format slightly to conform to ours. In your
makefile, the FFLAGS were not being used.

Original issue reported on code.google.com by mcgratta on 2014-10-24 12:25:38

gforney commented 9 years ago 
With rev 20806 I can compile the code with the pgi compiler, but when I run fds on a
case and most debugging options turned on I get the following error:
0: Null pointer for p_zone_p (../FDS_Source/dump.f90: 6412)

Line 6412 writes the pressure to hrr file, (P_ZONE_P(I),I=1,N_ZONE_TMP) and for some
reason the number of pressure zones is equal to zero, since no memory is allocated
and hence the error.

Original issue reported on code.google.com by bjarne.husted on 2014-10-27 11:03:31

gforney commented 9 years ago 
Post a simple version of the case. This kind of thing is not unusual whenever we upgrade
our compiler or try another compiler. Some compilers have different default behavior
about allocating arrays, setting initial values, and so on. We try to code in such
a way as to avoid these problems, but there is always something that goes undetected
with one compiler and not another.

Original issue reported on code.google.com by mcgratta on 2014-10-27 12:39:05

gforney commented 9 years ago 
I compiled svn 20814 with the intel 14 compiler (openmp) and the pgi 14.3 compiler (serial
mode - no openmp). The code runs fine with intel compiler, but with the pgi get (as
previously stated):

 SVN Revision No. : 20814
 MPI Disabled
 OpenMP Disabled
 Job TITLE        : sp2_10_mesh1
 Job ID string    : sp2_10_mesh1
0: Null pointer for p_zone_p (../FDS_Source/dump.f90: 6412)

I use the following settings for the pgi: (basicly the svn version with added debug
info)
# AMD Opteron 64Bit PC
pgi_linux_64 : FFLAGS =  -tp bulldozer  -Mstandard  -Mbounds  -Mchkfpstk  -Mchkptr
 -Mchkptr -Mchkstk -g
pgi_linux_64 : FCOMPL = pgf90
pgi_linux_64 : LFLAGS  =  -tp bulldozer  -byteswapio -Bstatic  -lc -lgcc_eh 
pgi_linux_64 : obj = fds_pgi_Opteron64
pgi_linux_64 : $(obj_serial)
        $(FCOMPL) $(FFLAGS) -o $(obj) $(obj_serial)

I have attached the input file which I used for both the intel compiled fds and the
pgi compiled fds and also the terminaloutput.out file showing the error.

Original issue reported on code.google.com by bjarne.husted on 2014-10-28 08:27:57

gforney commented 9 years ago 
Fixed it. This is just the kind of bug we typically see. Intel allows it, other compilers
do not. We use the "check all" debugging feature, but I think it is the decision of
the compiler developer, not the standard, to flag these sorts of things as errors.
You will probably see more of these kinds of errors. You might want to fix them as
you find them, and then report them all at once to us. This will hopefully get you
going faster. These reports are good for us because they prevent possible future bugs.

Original issue reported on code.google.com by mcgratta on 2014-10-28 12:52:24

gforney commented 9 years ago 
--Kevin,  Now I got FDS to run, when I used the pgi 14.9. The pgi 14.3 produces a division
by zero on the first time step.

I had to do a few more changes on dump.f90 to get it going:

I put a comment on line 7317,  
!READ (MODULE_DATE,'(I5)') MODULE_REV  as this produces a type conversion error. 

At line 6418 I changed the write statement: (similar to you change in line 600 something
).
IF (N_ZONE_TMP>0) THEN
        WRITE(LU_HRR,TCFORM) STIME,0.001_EB*Q_DOT_TOTAL(1:N_Q_DOT),0.001_EB*SUM(Q_DOT_TOTAL(1:N_Q_DOT-1)),&
                             M_DOT_TOTAL(1),(P_ZONE_P(I),I=1,N_ZONE_TMP)
ELSE
        WRITE(LU_HRR,TCFORM) STIME,0.001_EB*Q_DOT_TOTAL(1:N_Q_DOT),0.001_EB*SUM(Q_DOT_TOTAL(1:N_Q_DOT-1)),&
                             M_DOT_TOTAL(1)
ENDIF

Original issue reported on code.google.com by bjarne.husted on 2014-10-28 15:27:12

gforney commented 9 years ago 
I fixed 6418. Same problem as before. I tried something to fix line 7317. Let me know
if it works. If it does, I need to fix this statement in each file.

Original issue reported on code.google.com by mcgratta on 2014-10-28 17:23:09

gforney commented 9 years ago 
Thanks - both fixes work. Also the openmp version with 1 thread runs, but using two
threads I get a out of bounds error.

 OpenMP thread   1 of   2 is running
 OpenMP thread   2 of   2 is running
0: Subscript out of range for array rho_h_s_p (../FDS_Source/divg881)
 883)
    subscript=210, lower bound=0, upper bound=209, dimension=1

Original issue reported on code.google.com by paulsenhusted on 2014-10-28 18:56:24

gforney commented 9 years ago 
I'll ask Daniel to look at this. We use a "thread checker" that comes with the Intel
compiler to check that the OpenMP calls in FDS are not causing conflicts. I don't know
what the equivalent tool is for the PGI compiler.

Original issue reported on code.google.com by mcgratta on 2014-10-28 19:57:37

gforney commented 9 years ago 
The equivalent tool for pgi (thread analyzer) is called pgdbg (graphical debugger).
I have not tried it on linux yet, - as I currently only have terminal access to our
different clusters.

Original issue reported on code.google.com by bjarne.husted on 2014-10-29 12:39:00

gforney commented 9 years ago 
Is there any progress on this issue?

Original issue reported on code.google.com by mcgratta on 2015-03-09 18:06:39

gforney commented 9 years ago 
Not from my side.

Original issue reported on code.google.com by daniel.haarhoff on 2015-03-13 14:39:19

gforney commented 9 years ago 
I got an mail from the portland group last week that an issues with I reported to them
with compilation of FDS has been solved in PGI 15.4 (their lastest version). This was
not directly related to the issue above, but I decided again to try with the PGI compiler
and openmp.

Using the PGI compiler version 15.4 on our linux cluster I can now compile svn 22343
without any major issues. Further I do not longer get the error mentioned in #37 

Therefore I think this issue can be marked as fixed.

Original issue reported on code.google.com by bjarne.husted on 2015-04-24 14:37:16

gforney commented 9 years ago 
Thanks for helping us with these compiling errors.

Original issue reported on code.google.com by mcgratta on 2015-04-24 15:14:21