Consistency of fortran string lengths

[jedwards4b]

I ran into a problem with the filename_base string setting in fv3 model_configure:
The length of this string as declared in io/module_fv3_io_def.F90 is 255, however in testing
we have found the length to be limited to 80 characters. It is very difficult to pinpoint exactly where this restriction is introduced as there is no consistency in the declaration of string lengths in fv3 - in this particular case I found that this variable is used in module_fcst_grid_comp.F90 with length 128 and in fv3_cap.F90 (variable fcstItemNameList) with length 80.

I would like to propose that all character lengths be declared as
character(len=lenvar)
where lenvar is defined in a module of constants and that variables of the form
character(nn) or character(len=nn) where nn is integer be removed from the current code and banned from future contributions.

[rsdunlapiv]

@junwang-noaa can you please comment on this

[junwang-noaa]

Rocky,

I do not know how the testing is done. But from the code, it looks to me the fieldname_base is defined in io/module_fv3_io_def.F90 as 255 character string:

character(255),dimension(:),allocatable :: filename_base

And it gets its value from ESMF calls in fv3_cap.F90, does not change value since then:

use module_fv3_io_def, only: num_pes_fcst,write_groups,app_domain, &
num_files, filename_base, ....
...
allocate(filename_base(num_files))
CALL ESMF_ConfigFindLabel(CF,'filename_base:',rc=RC)
do i=1,num_files
CALL ESMF_ConfigGetAttribute(config=CF,value=filename_base(i), rc=rc)
if (ESMF_LogFoundError(rcToCheck=rc, msg=ESMF_LOGERR_PASSTHRU, line=LINE, file=FILE)) return
enddo
if(mype == 0) print *,'af nems config,num_files=',num_files, &
'filename_base=',filename_base

It seems the ESMF call ESMF_ConfigGetAttribute has problem to get the 255 character string? Thanks

[jedwards4b]

For reasons that are not clear to me the field bundle names are associated with filename_base,
in fv3cap.F90 variable fcstItemNameList is declared with length 80 and used to set these names, it is in the cap, not in esmf where the restriction to 80 characters occurs.

[junwang-noaa]

In this issue, it's said the fieldname_base does not have 255 characters, so it actually does have 255 characters? Would you please check how the fcstItemNameList is changing the fieldname_base? I am confused what is the problem/bug in the issue. It seems you are checking the length of output file name? not the length of fieldname_base?

…

On Thu, Jan 9, 2020 at 2:52 PM jedwards4b ***@***.***> wrote: For reasons that are not clear to me the field bundle names are associated with filename_base, in fv3cap.F90 variable fcstItemNameList is declared with length 80 and used to set these names, it is in the cap, not in esmf where the restriction to 80 characters occurs. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#49?email_source=notifications&email_token=AI7D6TPEXAJE2E3FKDEY46DQ4557FA5CNFSM4KCSH67KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIRR4AA#issuecomment-572726784>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI7D6TJC5S4VCQDC7IBTFTTQ4557FANCNFSM4KCSH67A> .

[jedwards4b]

fcstItemNameList is not changing fieldname_base, on the contrary fieldname_base (with length 255) is used in the creation of fcstItemNameList (length 80) which presents a practical limit of 80 on the length of fieldname_base - if it is any longer you get an error due to the truncation of strings in fcstItemNameList.

[junwang-noaa]

So, if I understand correctly, you are trying to get 255 character fcstItemNameList, is it correct? If that is the case, please be aware that the fieldname_base is combined with strings for interpolation method to mark the field bundle name. In other words, setting fcstItemNameList string names to 255 won't guarantee you can set 255 characters in filename_base since the 255 fieldname_base may mess up the interpolation method. A solution might be not to combine the interpolation method with the field bundle names, instead set an attribute for the interpolation method for the corresponding field bundles.

[jedwards4b]

I opened the issue to point out a general problem - because there is no consistency in character string lengths the model is prone to errors of this nature that are very difficult to track down. The case of fieldname_base and fcstItemNameList is intended as an illustration of this more general issue.

[arunchawla-NOAA]

Is this a long term issue that can be addressed at a later date or needs to be tackled now for the release? I ask because of the limited time that we have

[jedwards4b]

The general problem does not need to be addressed prior to the release. However it would be very helpful if the PR that I have submitted to fv3atm were accepted into the ufs_release branch.

[climbfuji]

The PR was merged (NOAA-EMC/fv3atm#43), are you ok with closing this issue?

[jedwards4b]

The PR covered one particular case of something that is a pervasive problem in the model. The issue will not be resolved anytime soon.

[mvertens]

@dominikus Heinzeller - NOAA <[email protected]> - I think the issue should stay there with the label of post-release that we introduced yesterday. If we close the issue it will probably not be addressed in the future.

…

On Thu, Jan 30, 2020 at 9:45 AM jedwards4b ***@***.***> wrote: The PR covered one particular case of something that is a pervasive problem in the model. The issue will not be resolved anytime soon. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#49?email_source=notifications&email_token=AB4XCEY4EPJHNB5QMPSTJXTRAL737A5CNFSM4KCSH67KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKLV3EI#issuecomment-580345233>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4XCEZPMZRFHEN5UALIP23RAL737ANCNFSM4KCSH67A> .