richard_walsh@csi_cuny_edu
New Member
All,
It seems likely to me that the Intel compiler has uncovered
an error in the definition and use the 'tadvect_ctype_passive_tracers'
characters array which has non-unit length.
This array is a public variable in the file mentioned in the subject
line of my message. It is declared as follows in the same routine:
character (char_len), dimension(3:nt) :: &
tadvect_ctype_passive_tracers
which creates a character array of strings of length 'char_len' which
is valued elsewhere a 256. The array is one dimensional, but
with non-default bounds, the lower bound being 3 and the under
bound being nt which is valued elsewhere as 3 also. This means
that we have a character string-base array with strings of length
256 that is one-dimensional and has only one element in it whose
ONLY index is 3. A weird construction indeed, but not in and of
itself a problem.
Later in the same routine the following line appears:
tadvect_ctype_passive_tracers(3:nt) = 'base_model'
As mentioned 'nt' is 3, so what does this line mean? Normally
the array's dimension appears first in expressions of character
string arrays, as in:
mycharray(dim)(str_begin:str_end)
and a colon would not be needed, only the array element into
which the assignment should be made. As this array is one-
dimensional and has only one member (index value = 3) the
colon is not needed, if the intent is to refer to the array's
index, rather than the bounds of the string. This assignment
is accepted as initializing the first 10 characters of the element
indexed by (3:3) which reduces to (3) I assume. The problem
comes later in the code here marked with the >>> at line
309:
if (ecosys_on) then
call ecosys_init(init_ts_file_fmt, read_restart_filename, &
tracer_d(ecosys_ind_begin:ecosys_ind_end), &
TRACER(:,:,:,ecosys_ind_begin:ecosys_ind_end,:,:), &
>>>>> tadvect_ctype_passive_tracers(ecosys_ind_begin:ecosys_ind_end), &
errorCode)
if (errorCode /= POP_Success) then
call POP_ErrorSet(errorCode, &
'init_passive_tracers: error in ecosys_init')
return
endif
end if
The compiler gets confused (because the presentation is confusing) ...
which use of the colon is intended here ... ?? It rejects the line with:
/home/cesm/cesmwrk/richard.walsh/b40.B2000/ocn/source/passive_tracers.F90(309)
error #7938: Character length argument mismatch. [TADVECT_CTYPE_PASSIVE_TRACERS]
tadvect_ctype_passive_tracers(ecosys_ind_begin:ecosys_ind_end), &
-----------------------^
compilation aborted for /home/cesm/cesmwrk/richard.walsh/b40.B2000/ocn/source/passive_tracers.F90 (code 1)
gmake: *** [passive_tracers.o] Error 1
which is corrected-disambiguated (compiler error goes away) by inserting the one-dimensional
array's indexed dimension, as follows:
if (ecosys_on) then
call ecosys_init(init_ts_file_fmt, read_restart_filename, &
tracer_d(ecosys_ind_begin:ecosys_ind_end), &
TRACER(:,:,:,ecosys_ind_begin:ecosys_ind_end,:,:), &
>>>>> tadvect_ctype_passive_tracers(nt)(ecosys_ind_begin:ecosys_ind_end), &
errorCode)
if (errorCode /= POP_Success) then
call POP_ErrorSet(errorCode, &
'init_passive_tracers: error in ecosys_init')
return
endif
end if
Unless ecosys_ind_begin and ecosys_ind_end are always equal and are somehow
intended to always refer to the index of the one-dimensional array, 3 this is
a problematic use.
I recommend you recode the entire set of statements to explicitly use both the
character array's dimension and any string start and end points in all expressions
that use 'tadvect_ctype_passive_tracers' and other character string arrays.
If I am some how confused and/or the Intel 12.1 compiler has its own
bug, please let me know. If this is indeed a bug in POP2, please provide
me with your revised and less ambiguous rendering as soon as it is available.
Sincerely,
Richard Walsh
Parallel Applications and Systems Manager
CUNY HPC Center, New York City
It seems likely to me that the Intel compiler has uncovered
an error in the definition and use the 'tadvect_ctype_passive_tracers'
characters array which has non-unit length.
This array is a public variable in the file mentioned in the subject
line of my message. It is declared as follows in the same routine:
character (char_len), dimension(3:nt) :: &
tadvect_ctype_passive_tracers
which creates a character array of strings of length 'char_len' which
is valued elsewhere a 256. The array is one dimensional, but
with non-default bounds, the lower bound being 3 and the under
bound being nt which is valued elsewhere as 3 also. This means
that we have a character string-base array with strings of length
256 that is one-dimensional and has only one element in it whose
ONLY index is 3. A weird construction indeed, but not in and of
itself a problem.
Later in the same routine the following line appears:
tadvect_ctype_passive_tracers(3:nt) = 'base_model'
As mentioned 'nt' is 3, so what does this line mean? Normally
the array's dimension appears first in expressions of character
string arrays, as in:
mycharray(dim)(str_begin:str_end)
and a colon would not be needed, only the array element into
which the assignment should be made. As this array is one-
dimensional and has only one member (index value = 3) the
colon is not needed, if the intent is to refer to the array's
index, rather than the bounds of the string. This assignment
is accepted as initializing the first 10 characters of the element
indexed by (3:3) which reduces to (3) I assume. The problem
comes later in the code here marked with the >>> at line
309:
if (ecosys_on) then
call ecosys_init(init_ts_file_fmt, read_restart_filename, &
tracer_d(ecosys_ind_begin:ecosys_ind_end), &
TRACER(:,:,:,ecosys_ind_begin:ecosys_ind_end,:,:), &
>>>>> tadvect_ctype_passive_tracers(ecosys_ind_begin:ecosys_ind_end), &
errorCode)
if (errorCode /= POP_Success) then
call POP_ErrorSet(errorCode, &
'init_passive_tracers: error in ecosys_init')
return
endif
end if
The compiler gets confused (because the presentation is confusing) ...
which use of the colon is intended here ... ?? It rejects the line with:
/home/cesm/cesmwrk/richard.walsh/b40.B2000/ocn/source/passive_tracers.F90(309)
error #7938: Character length argument mismatch. [TADVECT_CTYPE_PASSIVE_TRACERS]
tadvect_ctype_passive_tracers(ecosys_ind_begin:ecosys_ind_end), &
-----------------------^
compilation aborted for /home/cesm/cesmwrk/richard.walsh/b40.B2000/ocn/source/passive_tracers.F90 (code 1)
gmake: *** [passive_tracers.o] Error 1
which is corrected-disambiguated (compiler error goes away) by inserting the one-dimensional
array's indexed dimension, as follows:
if (ecosys_on) then
call ecosys_init(init_ts_file_fmt, read_restart_filename, &
tracer_d(ecosys_ind_begin:ecosys_ind_end), &
TRACER(:,:,:,ecosys_ind_begin:ecosys_ind_end,:,:), &
>>>>> tadvect_ctype_passive_tracers(nt)(ecosys_ind_begin:ecosys_ind_end), &
errorCode)
if (errorCode /= POP_Success) then
call POP_ErrorSet(errorCode, &
'init_passive_tracers: error in ecosys_init')
return
endif
end if
Unless ecosys_ind_begin and ecosys_ind_end are always equal and are somehow
intended to always refer to the index of the one-dimensional array, 3 this is
a problematic use.
I recommend you recode the entire set of statements to explicitly use both the
character array's dimension and any string start and end points in all expressions
that use 'tadvect_ctype_passive_tracers' and other character string arrays.
If I am some how confused and/or the Intel 12.1 compiler has its own
bug, please let me know. If this is indeed a bug in POP2, please provide
me with your revised and less ambiguous rendering as soon as it is available.
Sincerely,
Richard Walsh
Parallel Applications and Systems Manager
CUNY HPC Center, New York City