gforney
commented
9 years ago Timo,
The error is for an evac file.Original issue reported on code.google.com by drjfloyd on 2015-06-18 16:48:30
Closed gforney closed 6 years ago
gforney
commented
9 years ago Timo,
The error is for an evac file.Original issue reported on code.google.com by drjfloyd on 2015-06-18 16:48:30
gforney
commented
9 years ago Ok. I'll check this. Which operating system etc are you using?
I was not able to crash the case with the DOS 64bit executable
that comes with the installation package.
Fire Dynamics Simulator
Compilation Date : Sat, 11 Apr 2015
Current Date : June 22, 2015 09:03:15
Version : FDS 6.2.0
SVN Revision No. : 22343
MPI Enabled; Number of MPI Processes: 1
OpenMP Enabled; Number of OpenMP Threads: 4
Job TITLE : Nht
Job ID string : NhtTimo
Time Step: 1, Simulation Time: 0.11 s
Time Step: 2, Simulation Time: 0.22 s
Time Step: 3, Simulation Time: 0.34 s
Time Step: 4, Simulation Time: 0.45 s
Time Step: 5, Simulation Time: 0.56 s
Time Step: 6, Simulation Time: 0.67 s
Time Step: 7, Simulation Time: 0.78 s
Time Step: 8, Simulation Time: 0.89 s
Time Step: 9, Simulation Time: 1.01 s
Time Step: 10, Simulation Time: 1.12 s
Time Step: 20, Simulation Time: 2.24 s
I try it next on our Linux cluster, compiled with Intel compiler
and using debug compiling options:
Current Date : June 22, 2015 11:07:35
Version : FDS 6.2.0
Revision : 22903
NewSmokey (~/FDS+Evac/HelpFdsEvac/Issue2486): ~/FDS_Source_Latest/fds_intel_linu
x_64_db NhtTimo.fds
OpenMP thread 0 of 3 is running
OpenMP thread 3 of 3 is running
OpenMP thread 2 of 3 is running
OpenMP thread 1 of 3 is running
forrtl: severe (408): fort: (2): Subscript #1 of the array IL_R has value 1030 w
hich is greater than the upper bound of 1024
Image PC Routine Line Source
fds_intel_linux_6 0000000001BF17FC radcompute_radiat 978 radi.f90
libiomp5.so 00002B208056C603 Unknown Unknown Unknown
So, got something wrong. Next the same version, but the input
file has (RADI RADIATION=.FALSE.):
Fire Dynamics Simulator
Revision Date : unknown
Compilation Date : unknown
Current Date : June 22, 2015 11:11:37
Version : FDS 6.2.0
Revision : 22903
MPI Disabled
OpenMP Enabled; Number of OpenMP Threads: 4
Job TITLE : Nht
Job ID string : NhtTimo
Time Step: 1, Simulation Time: 0.11 s
Time Step: 2, Simulation Time: 0.22 s
Time Step: 3, Simulation Time: 0.34 s
Time Step: 4, Simulation Time: 0.45 s
Time Step: 5, Simulation Time: 0.56 s
Time Step: 6, Simulation Time: 0.67 s
Time Step: 7, Simulation Time: 0.78 s
Time Step: 8, Simulation Time: 0.89 s
Time Step: 9, Simulation Time: 1.01 s
Time Step: 10, Simulation Time: 1.12 s
Time Step: 20, Simulation Time: 2.24 s
So, without radiation things seem to be fine. Well, I need to
do some test with the present SVN version. The above debug
version was my own, I am doing something for the ACTIVE_MESH,
i.e., try to get rid of it => means some modifications in
the main.f90 in my own version. So, next I'll check the
present SVN version and see, how it handles the input
file.
Timo
Original issue reported on code.google.com by tkorhon1 on 2015-06-22 08:26:21
gforney
commented
9 years ago Jason, there is no evacuation stuff in the input file.
It has just a line "!!! Evacuation", nothing more.
There is something in radi.f90, you get some error there
for the debug (serial) version in a Linux cluster using
Intel compiler. If you set RADIATION=.FALSE., you do
not get an error message at all.
Revision Date : unknown
Compilation Date : unknown
Current Date : June 22, 2015 11:43:52
Version : FDS 6.2.0
Revision : 22903
NewSmokey (~/FDS+Evac/HelpFdsEvac/Issue2486): ~/FDS_Source/fds_intel_linux_64_db
NhtTimo.fds
OpenMP thread 0 of 3 is running
OpenMP thread 1 of 3 is running
OpenMP thread 2 of 3 is running
OpenMP thread 3 of 3 is running
forrtl: severe (408): fort: (2): Subscript #1 of the array IL_R has value 1098 w
hich is greater than the upper bound of 1024
Image PC Routine Line Source
fds_intel_linux_6 0000000001BF17FC radcompute_radiat 978 radi.f90
libiomp5.so 00002B4D79DF1603 Unknown Unknown Unknown
NewSmokey (~/FDS+Evac/HelpFdsEvac/Issue2486):
TimoK
Original issue reported on code.google.com by tkorhon1 on 2015-06-22 08:47:35
gforney
commented
9 years ago Sorry, I totally forgot about the versions.
I have to use OpenSUSE 13.1 and compiled fds with gfortran (the version of my fortran
package is: 4.8-2.1.2 (so gcc 4.8)).
See the attached spec file how I build/package my version of fds.
I tried a newer version of fds but issue still remains in revision 22921.
Do you need some more information?Original issue reported on code.google.com by richard.poettler on 2015-06-22 12:00:17
gforney
commented
9 years ago As we cannot reproduce this error with the current release, this suggests some form
of compiler issue.
Make sure you have the latest release of the gnu compiler. 4.8 is almost two years
old now. Both 4.9 and 5 have since been released.
Make sure you are doing a clean build, delete all .o files prior to compiling
Have you tried modfying our makefile (which has linux gnu build option) to work on
your system?Original issue reported on code.google.com by drjfloyd on 2015-06-22 13:46:33
gforney
commented
9 years ago I always build my packages in a clean (freshly created) chroot environment.
I can ensure this by using mock on Fedora/CentOS and a custom made shell script:
https://github.com/poettler-ric/scripts/blob/master/susechroot.sh
I don't alter the sources provided by the fds project.
The revision 20564 of fds seems to be working. Even when compiled with gcc version
4.8.1.
I installed a clean (and updated) Fedora 22 host (kvm):
[admin@localhost fds]$ lsb_release -a
LSB Version: :core-4.1-amd64:core-4.1-noarch
Distributor ID: Fedora
Description: Fedora release 22 (Twenty Two)
Release: 22
Codename: TwentyTwo
[admin@localhost fds]$ uname -a
Linux localhost.localdomain 4.0.5-300.fc22.x86_64 #1 SMP Mon Jun 8 16:15:26 UTC 2015
x86_64 x86_64 x86_64 GNU/Linux
And was able to reproduce the issue with it:
[admin@localhost fds]$ fds Nht.fds
OpenMP thread 3 of 7 is running
OpenMP thread 5 of 7 is running
OpenMP thread 0 of 7 is running
OpenMP thread 6 of 7 is running
OpenMP thread 1 of 7 is running
OpenMP thread 2 of 7 is running
OpenMP thread 4 of 7 is running
OpenMP thread 7 of 7 is running
Fire Dynamics Simulator
Revision Date : unknown
Compilation Date : unknown
Current Date : June 23, 2015 09:02:33
Version : FDS 6.2.0
Revision : 22921
MPI Disabled
OpenMP Enabled; Number of OpenMP Threads: 8
Job TITLE : Nht
Job ID string : Nht
Time Step: 1, Simulation Time: 0.11 s
Time Step: 2, Simulation Time: 0.22 s
Time Step: 3, Simulation Time: 0.34 s
Time Step: 4, Simulation Time: 0.45 s
Time Step: 5, Simulation Time: 0.56 s
Time Step: 6, Simulation Time: 0.67 s
Time Step: 7, Simulation Time: 0.78 s
Time Step: 8, Simulation Time: 0.89 s
Time Step: 9, Simulation Time: 1.01 s
Time Step: 10, Simulation Time: 1.12 s
At line 6946 of file ../FDS_Source/dump.f90 (unit = 19)
Fortran runtime error: Specified UNIT in FLUSH is not connected
Fedora reports following gcc version:
[admin@localhost fds]$ gcc --version
gcc (GCC) 5.1.1 20150612 (Red Hat 5.1.1-3)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This is how I compile the sources like this:
cd FDS_Compilation
make -j8 gnu_linux
%__make clean
# load mpi environment and compile with mpi on suse
export PATH=/usr/lib64/mpi/gcc/openmpi/bin:$PATH
%__make -j$RPM_BUILD_NCPUS mpi_gnu_linux
# or load mpi environment and compile with mpi on fedora/rhel
module load mpi/openmpi-x86_64
%__make -j$RPM_BUILD_NCPUS FCOMPL=mpif90 mpi_gnu_linux
Then I only copy the produced binaries fds_gnu_linux and fds_mpi_gnu_linux
Do you need any additional information?
Kind regards
Richard PöttlerOriginal issue reported on code.google.com by richard.poettler on 2015-06-23 07:33:08
gforney
commented
9 years ago Dear all,
as I have experienced the same issues, I post here a (similar) issue protocol on an
OSX system.
It consist of:
- info about compiler, svn version, OS
- compilation protocol
- listing and execution of sample FDS input file
- not successful execution
- remove of IO, here SLCF
- successful execution
Best,
Lukas
==============================================================================
larnold@wlan-29-238:~
> sw_vers
ProductName: Mac OS X
ProductVersion: 10.9.5
BuildVersion: 13F1077
==============================================================================
larnold@wlan-29-238:~
> cd ~/Software/FDS_r22750
larnold@wlan-29-238:~/Software/FDS_r22750
> svn info
Path: .
Working Copy Root Path: /Users/larnold/Software/FDS_r22750
URL: http://fds-smv.googlecode.com/svn/trunk/FDS/trunk
Repository Root: http://fds-smv.googlecode.com/svn
Repository UUID: d1fd391b-682f-0410-ad1c-43d0e10d2734
Revision: 22750
Node Kind: directory
Schedule: normal
Last Changed Author: drjfloyd@gmail.com
Last Changed Rev: 22750
Last Changed Date: 2015-05-29 13:13:14 +0200 (Fri, 29 May 2015)
==============================================================================
larnold@wlan-29-238:~/Software/FDS_r22750
> gfortran --version
GNU Fortran (MacPorts gcc5 5.1.0_1) 5.1.0
Copyright (C) 2015 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
==============================================================================
larnold@wlan-29-238:~/Software/FDS_r22750
> cd FDS_Compilation/gnu_osx/
larnold@wlan-29-238:~/Software/FDS_r22750/FDS_Compilation/gnu_osx
> sh make_fds.sh
Building gnu_osx
gfortran -c -O2 ../../FDS_Source/prec.f90
gfortran -c -O2 ../../FDS_Source/mpis.f90
gfortran -c -O2 ../../FDS_Source/cons.f90
gfortran -c -O2 ../../FDS_Source/devc.f90
gfortran -c -O2 -fopenmp ../../FDS_Source/type.f90
gfortran -c -O2 -fopenmp ../../FDS_Source/pois.f90
gfortran -c -O2 -fopenmp ../../FDS_Source/mesh.f90
gfortran -c -O2 -fopenmp ../../FDS_Source/func.f90
gfortran -c -O2 ../../FDS_Source/data.f90
gfortran -c -O2 ../../FDS_Source/smvv.f90
gfortran -c -O2 ../../FDS_Source/irad.f90
gfortran -c -O2 -fopenmp ../../FDS_Source/turb.f90
gfortran -c -O2 ../../FDS_Source/ieva.f90
gfortran -c -O2 ../../FDS_Source/scrc.f90
gfortran -c -O2 ../../FDS_Source/gsmv.f90
gfortran -c -O2 ../../FDS_Source/ctrl.f90
gfortran -c -O2 ../../FDS_Source/soot.f90
gfortran -c -O2 ../../FDS_Source/evac.f90
gfortran -c -O2 ../../FDS_Source/geom.f90
gfortran -c -O2 ../../FDS_Source/samr.f90
gfortran -c -O2 ../../FDS_Source/hvac.f90
gfortran -c -O2 -fopenmp ../../FDS_Source/mass.f90
gfortran -c -O2 -fopenmp ../../FDS_Source/velo.f90
gfortran -c -O2 -fopenmp ../../FDS_Source/radi.f90
gfortran -c -O2 ../../FDS_Source/part.f90
gfortran -c -O2 ../../FDS_Source/wall.f90
gfortran -c -O2 ../../FDS_Source/fire.f90
gfortran -c -O2 ../../FDS_Source/vege.f90
gfortran -c -O2 -fopenmp ../../FDS_Source/pres.f90
gfortran -c -O2 ../../FDS_Source/dump.f90
gfortran -c -O2 ../../FDS_Source/read.f90
gfortran -c -O2 -fopenmp ../../FDS_Source/divg.f90
gfortran -c -O2 ../../FDS_Source/init.f90
gfortran -c -O2 -fopenmp ../../FDS_Source/main.f90
gfortran -O2 -fopenmp -o fds_gnu_osx prec.o mpis.o cons.o devc.o data.o type.o mesh.o
func.o smvv.o irad.o turb.o soot.o ieva.o pois.o scrc.o radi.o evac.o gsmv.o geom.o
part.o vege.o ctrl.o samr.o dump.o hvac.o mass.o read.o wall.o fire.o divg.o velo.o
pres.o init.o main.o
==============================================================================
larnold@wlan-29-238:~/Software/FDS_r22750/FDS_Compilation/gnu_osx
> cd ~/tmp/io-issue/
larnold@wlan-29-238:~/tmp/io-issue
> cat io-issue.fds
&HEAD CHID='IO-issue', TITLE='IO-issue' /
&MESH IJK=16,16,32, XB=0.00,0.16, 0.00,0.16, 0.00,0.32 /
&TIME T_END=10.0 /
&SURF ID='BURNER', TMP_FRONT=150.0, COLOR='RASPBERRY' /
&VENT XB=0.05, 0.11, 0.05, 0.11, 0.01, 0.01, SURF_ID='BURNER' /
&OBST XB=0.05, 0.11, 0.05, 0.11, 0.00, 0.01 /
&VENT MB='XMIN', SURF_ID='OPEN' /
&VENT MB='XMAX', SURF_ID='OPEN' /
&VENT MB='YMIN', SURF_ID='OPEN' /
&VENT MB='YMAX', SURF_ID='OPEN' /
&VENT MB='ZMAX', SURF_ID='OPEN' /
&SLCF PBY=0.08, QUANTITY='TEMPERATURE' /
&TAIL /
==============================================================================
larnold@wlan-29-238:~/tmp/io-issue
> ~/Software/FDS_r22750/FDS_Compilation/gnu_osx/fds_gnu_osx io-issue.fds
OpenMP thread 1 of 1 is running
OpenMP thread 0 of 1 is running
Fire Dynamics Simulator
Revision Date : unknown
Compilation Date : unknown
Current Date : June 23, 2015 09:38:17
Version : FDS 6.2.0
Revision : 22748
MPI Disabled
OpenMP Enabled; Number of OpenMP Threads: 2
Job TITLE : IO-issue
Job ID string : IO-issue
Time Step: 1, Simulation Time: 0.03 s
At line 6973 of file ../../FDS_Source/dump.f90 (unit = 18)
Fortran runtime error: Specified UNIT in FLUSH is not connected
==============================================================================
larnold@wlan-29-238:~/tmp/io-issue
> cat IO-issue.out
Fire Dynamics Simulator
Revision Date : unknown
Compilation Date : unknown
Current Date : June 23, 2015 09:38:17
Version : FDS 6.2.0
Revision : 22748
MPI Disabled
OpenMP Enabled; Number of OpenMP Threads: 2
Job TITLE : IO-issue
Job ID string : IO-issue
Grid Dimensions, Mesh 1
Cells in the X Direction 16
Cells in the Y Direction 16
Cells in the Z Direction 32
Physical Dimensions, Mesh 1
Length (m) 0.160
Width (m) 0.160
Height (m) 0.320
Initial Time Step (s) 0.028
Miscellaneous Parameters
Simulation Start Time (s) 0.0
Simulation End Time (s) 10.0
LES Calculation
Deardorff Model (C_DEARDORFF) 0.10
Turbulent Prandtl Number 0.50
Turbulent Schmidt Number 0.50
Ambient Temperature (C) 20.00
Mass Fraction Transformation Matrix to Convert Species Mixtures (Columns) to Primitive
Species (Rows)
AIR
NITROGEN 0.763018
OXYGEN 0.231164
CARBON DIOXIDE 0.000592
WATER VAPOR 0.005226
Primitive Species Information
NITROGEN
Gas Species
Molecular Weight (g/mol) 28.01340
Ambient Density (kg/m^3) 1.165
Enthalpy of Formation (J/kg) 0.00E+00
OXYGEN
Gas Species
Molecular Weight (g/mol) 31.99880
Ambient Density (kg/m^3) 1.330
Enthalpy of Formation (J/kg) 0.00E+00
CARBON DIOXIDE
Gas Species
Molecular Weight (g/mol) 44.00950
Ambient Density (kg/m^3) 1.830
Enthalpy of Formation (J/kg) -8.94E+06
WATER VAPOR
Gas Species
Molecular Weight (g/mol) 18.01528
Ambient Density (kg/m^3) 0.749
Enthalpy of Formation (J/kg) -1.34E+07
Tracked (Lumped) Species Information
AIR
Molecular Weight (g/mol) 28.76431
Ambient Density (kg/m^3) 1.196
Initial Mass Fraction 1.000
Enthalpy of Formation (J/kg) -7.54E+04
Sub Species Mass Fraction Mole Fraction
NITROGEN 7.630183E-01 7.834714E-01
OXYGEN 2.311635E-01 2.077972E-01
CARBON DIOXIDE 5.918904E-04 3.868556E-04
WATER VAPOR 5.226257E-03 8.344566E-03
Viscosity (kg/m/s) Ambient (293 K): 1.80E-05
500 K: 2.61E-05
1000 K: 4.13E-05
1500 K: 5.37E-05
Therm. Cond. (W/m/K) Ambient (293 K): 2.55E-02
500 K: 3.80E-02
1000 K: 6.62E-02
1500 K: 9.20E-02
Spec. Heat (J/kg/K) Ambient (293 K): 1.01E+03
500 K: 1.04E+03
1000 K: 1.15E+03
1500 K: 1.22E+03
Diff. Coeff. (m^2/s) Ambient (293 K): 1.99E-05
500 K: 4.96E-05
1000 K: 1.58E-04
1500 K: 3.09E-04
Material Information
Surface Conditions
0 INERT (DEFAULT)
1 BURNER
Wall or Vent Temperature (C) 150.0
2 OPEN
Passive Vent to Atmosphere
3 MIRROR
Symmetry Plane
4 INTERPOLATED
5 PERIODIC
6 HVAC
7 MASSLESS TRACER
8 DROPLET
9 VEGETATION
10 EVACUATION_OUTFLOW
Normal Velocity (m/s) 0.000
11 MASSLESS TARGET
Slice File Information, Mesh 1
Sampling Interval (s) 0.010
1 Nodes: 0 16 8 8 0 32, Quantity: TEMPERATURE
Radiation Model Information
Number of control angles 104
Time step increment 3
Angle increment 5
Theta band N_phi Solid angle
1: 4 0.12
2: 12 0.11
3: 16 0.13
4: 20 0.12
5: 20 0.12
6: 16 0.13
7: 12 0.11
8: 4 0.12
Using gray gas absorption.
Mean beam length 0.050 m
Run Time Diagnostics
Time Step 1 June 23, 2015 09:38:17
Pressure Iterations: 1
Maximum Velocity Error: 0.17E-02 on Mesh 1 at ( 9 11 1)
---------------------------------------------------------------
CPU/step: 0.134E+01 s, Total CPU: 1.34 s
Time step: 0.280E-01 s, Total time: 0.03 s
Max CFL number: 0.49E-01 at ( 6, 7, 11)
Max divergence: 0.24E-02 at ( 9, 9, 2)
Min divergence: -0.11E-05 at ( 3, 14, 20)
Max VN number: 0.87E-01 at ( 10, 13, 19)
==============================================================================
larnold@wlan-29-238:~/tmp/io-issue
> sed "s/&SLCF/#OFF# SLCF/g" < io-issue.fds > io-issue-no-slcf.fds
larnold@wlan-29-238:~/tmp/io-issue
> cat io-issue-no-slcf.fds
&HEAD CHID='IO-issue', TITLE='IO-issue' /
&MESH IJK=16,16,32, XB=0.00,0.16, 0.00,0.16, 0.00,0.32 /
&TIME T_END=10.0 /
&SURF ID='BURNER', TMP_FRONT=150.0, COLOR='RASPBERRY' /
&VENT XB=0.05, 0.11, 0.05, 0.11, 0.01, 0.01, SURF_ID='BURNER' /
&OBST XB=0.05, 0.11, 0.05, 0.11, 0.00, 0.01 /
&VENT MB='XMIN', SURF_ID='OPEN' /
&VENT MB='XMAX', SURF_ID='OPEN' /
&VENT MB='YMIN', SURF_ID='OPEN' /
&VENT MB='YMAX', SURF_ID='OPEN' /
&VENT MB='ZMAX', SURF_ID='OPEN' /
#OFF# SLCF PBY=0.08, QUANTITY='TEMPERATURE' /
&TAIL /
==============================================================================
larnold@wlan-29-238:~/tmp/io-issue
> ~/Software/FDS_r22750/FDS_Compilation/gnu_osx/fds_gnu_osx io-issue-no-slcf.fds
OpenMP thread 1 of 1 is running
OpenMP thread 0 of 1 is running
Fire Dynamics Simulator
Revision Date : unknown
Compilation Date : unknown
Current Date : June 23, 2015 09:51:06
Version : FDS 6.2.0
Revision : 22748
MPI Disabled
OpenMP Enabled; Number of OpenMP Threads: 2
Job TITLE : IO-issue
Job ID string : IO-issue
Time Step: 1, Simulation Time: 0.03 s
Time Step: 2, Simulation Time: 0.06 s
Time Step: 3, Simulation Time: 0.08 s
Time Step: 4, Simulation Time: 0.11 s
Time Step: 5, Simulation Time: 0.14 s
Time Step: 6, Simulation Time: 0.17 s
Time Step: 7, Simulation Time: 0.20 s
Time Step: 8, Simulation Time: 0.22 s
Time Step: 9, Simulation Time: 0.25 s
Time Step: 10, Simulation Time: 0.28 s
Time Step: 20, Simulation Time: 0.56 s
Time Step: 30, Simulation Time: 0.84 s
Time Step: 40, Simulation Time: 1.12 s
Time Step: 50, Simulation Time: 1.40 s
Time Step: 60, Simulation Time: 1.67 s
Time Step: 70, Simulation Time: 1.90 s
Time Step: 80, Simulation Time: 2.12 s
Time Step: 90, Simulation Time: 2.34 s
Time Step: 100, Simulation Time: 2.56 s
Time Step: 200, Simulation Time: 4.54 s
Time Step: 300, Simulation Time: 6.80 s
Time Step: 400, Simulation Time: 9.06 s
Time Step: 442, Simulation Time: 10.01 s
STOP: FDS completed successfully (CHID: IO-issue)
Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
larnold@wlan-29-238:~/tmp/io-issue
>Original issue reported on code.google.com by hpc.on.fire on 2015-06-23 08:11:03
gforney
commented
9 years ago Try setting FLUSH_FILE_BUFFERS=.FALSE. on the DUMP line
&DUMP FLUSH_FILE_BUFFERS=.FALSE., ... /
Remember that there can only be one DUMP line in the file. This parameter stops FDS
from flushing the buffers. The downside is that you might have to wait for the simulation
to end before looking at the output in Smokeview. Let us know if this solves your problem.
We cannot reproduce this problem with the Intel Fortran compiler.Original issue reported on code.google.com by mcgratta on 2015-06-23 19:47:38
lu-kas
commented
9 years ago This issues got cut during migration. I repost the last comment here.
Found it.
Revision 22750, line numbers are +- a few lines (have added some diagnostics)
This issue might be a general one, but I have diagnosed only the slice files. The intended procedure is:
1) slc files get opened (dump.f90, INITIALIZE_MESH_DUMPS, l. 949) 2) slc files get written (somewhere) 3) slc files get flushed (dump.f90, FLUSH_LOCAL_BUFFERS, l. 6991) 4) slc files get closed (somewhere)
If you INQUIRE the file status at the FLUSHes, you will see, that the files are not opened anymore.
So, in the case, that no point3d data is written, the same file units as the one used above get opened and closed, see IF branch (dump.f90, DUMP_SLCF, l. 3846). This causes the errors at the FLUSH statement, but I do not understand why the WRITE statements work (for the disabled FLUSH calls).
Why the Intel compiler shows other behaviour, that I do not know.
Kevin, did you get the analysis above? Do you need more information to fix this issue?
Best, Lukas
rmcdermo
commented
9 years ago Lukas,
Thanks for checking.
Kevin,
Did you get this email?
Randy
On Mon, Jun 29, 2015 at 10:26 AM, Lukas notifications@github.com wrote:
This issues got cut during migration. I repost the last comment here.
Found it.
Revision 22750, line numbers are +- a few lines (have added some diagnostics)
This issue might be a general one, but I have diagnosed only the slice files. The intended procedure is:
1) slc files get opened (dump.f90, INITIALIZE_MESH_DUMPS, l. 949) 2) slc files get written (somewhere) 3) slc files get flushed (dump.f90, FLUSH_LOCAL_BUFFERS, l. 6991) 4) slc files get closed (somewhere)
If you INQUIRE the file status at the FLUSHes, you will see, that the files are not opened anymore.
So, in the case, that no point3d data is written, the same file units as the one used above get opened and closed, see IF branch (dump.f90, DUMP_SLCF, l. 3846). This causes the errors at the FLUSH statement, but I do not understand why the WRITE statements work (for the disabled FLUSH calls).
Why the Intel compiler shows other behaviour, that I do not know.
Kevin, did you get the analysis above? Do you need more information to fix this issue?
Best, Lukas
— Reply to this email directly or view it on GitHub https://github.com/firemodels/fds-smv/issues/2426#issuecomment-116700315 .
drjfloyd
commented
9 years ago I added INQUIRE statements before each FLUSH to make sure the file still shows as open. Lukas, does this fix your probmlem?
lu-kas
commented
9 years ago Jason,
I have not tried yet, but this will not help. With the INQUIRE you will only check if the file is open/connected. The flush will still fail and the following file writes might be corrupted as well. As described earlier, it is the close statement that bothers me.
Nevertheless I will try it for the protocol ;-)
Best, Lukas
On 30 Jun 2015, at 18:02, Jason Floyd notifications@github.com wrote:
I added INQUIRE statements before each FLUSH to make sure the file still shows as open. Lukas, does this fix your probmlem?
� Reply to this email directly or view it on GitHub.
lu-kas
commented
9 years ago Jason,
it works -- but I do not think it really solves the issue. In my previous response, I just read your text and did not look into the source code. I misinterpreted the part "make sure the file still shows as open". Now you basically do not FLUSH if the file is not open. This is now the same as globally turning flushing off.
I do not understand why you would want to call the flash routine if the target file is not open. I have the feeling, that there is something other that is wrong and is just caught by the FLUSH call. The target file gets closed (see previous comment) during execution, although it should stay open till the end of execution, right?
Thanks, Lukas
mcgratta
commented
9 years ago There's a history to the FLUSH feature. This was not standard Fortran until 2003 (I think), so we used to just do a CLOSE then OPEN to force the contents of the buffer to write out. I notice that there are still alot of instances of this in dump.f90.
drjfloyd
commented
9 years ago FLUSH only has meaning if the designated UNIT is connected (i.e. OPEN). If we are trying to FLUSH a file that has been closed, this is non-standard. Based on your earlier comment it appears the Intel compiler is just ignoring the error and continuing execution rather than aborting execution. The INQUIRE statement addition will make sure we aren't trying to FLUSH a closed file and wind up with a runtime error with other compilers.
lu-kas
commented
9 years ago Jason,
my point is: why would you want to call FLUSH on a closed file?
There is something wrong in the file IO logic. With the INQUIRE you just bypass a general issue. Having an INQUIRE at this point is fine -- for redundancy checking but not for bypassing. A "false" INQUIRE should trigger an error as the application wants to flush a file, therefore it assumes it is open, but in fact it got closed somewhere else.
Ok, but we do not have to take this further. I think the OP's issue is solved.
Thanks, Lukas
poettler-ric
commented
9 years ago Lukas,
I guess with OP you mean me. I think it depends on your philosophy. Yes, by disabling the dumping we were able to work around the "bug" but in my opinion the problem was only postponed since it seems the IO isn't handled correctly when solving certain problems and fds was compiled with gcc. Just working around the problem doesn't make the software more correct and sooner or later someone else (or we) might run into the same problem again with another calculation.
Just my 2 cents. Thanks for you efforts so far.
Kind regards Richard Pöttler
mcgratta
commented
6 years ago I don't even know if this is a problem anymore. If it is, start a new issue. This one is stale.
Avinashsingh17
commented
3 years ago Hi everyone, I am having this error while computing the thermal conductivity of Si using d3_tk.x in quantum espresso At line 181 of file nanoclock.f90 (unit = 6) Fortran runtime error: Specified UNIT in FLUSH is not connected
Error termination. Backtrace:
at /home/rajumenr/espresso+d3q_CHECK/D3Q/thermal2/nanoclock.f90:181
at /home/rajumenr/espresso+d3q_CHECK/D3Q/thermal2/variational_tk.f90:98
at /home/rajumenr/espresso+d3q_CHECK/D3Q/thermal2/PROGRAM_tk.f90:404
at /home/rajumenr/espresso+d3q_CHECK/D3Q/thermal2/PROGRAM_tk.f90:598
at /home/rajumenr/espresso+d3q_CHECK/D3Q/thermal2/PROGRAM_tk.f90:561
Can someone help me with this?
Original issue reported on code.google.com by
richard.poettleron 2015-06-18 12:54:07