Input parameter file and comments with keywords

[sspagnol]

Hi, could someone confirm whether having a keyword in a comment (which causes the non-commented keyword not to be read), is
1. not allowed at all
2. a problem with either inp_par.f decode_line function or
3. a problem with my compiler (ifort Version 11.0 Build 20090131 Package ID: l_cprof_p_11.0.081) running on a x86_64 GNU/Linux box.

example in my setup, the DT in the commented area causes NTIMES not to be read,

! Time-Stepping parameters.
NTIMES == 28800 ! @DT=60 = 20 days
DT == 60.0d0
NDTFAST == 20

Thanks,
Simon.

[kate]

Interesting. Parsing is line by line, checking keyword by keyword. The KeyWord should be only the first text in your input line, so I don't see how it's a bug in inp_par. You'll have to figure it out in the debugger.

[ggv]

I had the same problem commenting after NTIMES
NTIMES == 86400 ! "coment"

The only way the code reads the definition is with a <CR> after the definition

[arango]

Comments are allowed in any of the lines to be processed or decoded. All the input script files distributed in the ROMS/External directory have keywords values with comments. For example, ocean_upwelling.in has:

Code: Select all

          Lm == 41            ! Number of I-direction INTERIOR RHO-points
          Mm == 80            ! Number of J-direction INTERIOR RHO-points
           N == 16            ! Number of vertical levels

All ROMS user have run this application and nobody has reported this problem. I bet that the scripts that have this problem have TABS. Tabs are not allowed in any of processing scripts neither in any of the ROMS source code The distributed code in ROMS is free of tabs. You will only find tabs in the makefile and friends. Here the tabs are necessary.

Users should be extremelly careful when modifying distributed code and including tabs during editing. As a matter of fact, an new script was introduced recently ws_remove.bash or ws_remove.sh in the ROMS/Bin directory to remove trailing white space (including tabs) and report all files that contain tabs (excluding the makefile) so we can remove the tabs by hand.

I am slowly cleaning all the trailing white spaces in all ROMS files. You may have noticed that. I will finish the rest when I tag the new version in the next few days.

[m.hadfield]

All ROMS user have run this application and nobody has reported this problem. I bet that the scripts that have this problem have TABS.

I ran into a problem a few months ago where text after the "!" character affected the parsing of the line. It didn't involve tabs, or an "@" character like the OP. I think the offending line looked liked this

NTIMES = 20 != 72

I generated it with some automated processing, using sed to do a string substitution.

So the handling of comments by inp_par is reasonably robust but not completely bulletproof. Alphanumeric characters and spaces after the comment delimiter are OK, but it's best to avoid anything else.

[arango]

Sure, the problem here is the equal sign after the comment (!= 72). The equal sign is used in decode_line to extract the value of a particular keyword. In these case, it found two possible starting line locations for the processing of the numeric or string value. Probably, some debugging is needed to make this processing more roubust for this possibility. I never accounted for the possibility of an equal sign (=) after the commnent (!). As always, there few possibilities for breaking the decode_line logic.

[wilkin]

I struck this problem more than 2 years ago. It is definitely the = sign in the comment that causes the error.

Sorry, I should have said something to Hernan and had the issue flagged in the documentation in ocean.in