Custom Query (964 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (820 - 822 of 964)

Ticket Owner Reporter Resolution Summary
#64 arango m.hadfield Fixed Invalid Fortran unit numbers in inp_par.F
Description

In inp_par.F, lines 242 through 292, there is a series of OPEN statements to open biology, sediment, assimilation, float and stations parameters, using Fortran unit numbers 100, 200 ... 500. On a Cray T3E, unit number 100 is not allowed; the error message reads "The unit number (100) in the OPEN statement must be nonnegative and outside the range of 100 through 102." Other compilers have their own restrictions on unit numbers, eg. my Compaq Visual Fortran for Windows manual tells me that the numbers must be in the range 0 through 119. I *think* the Fortran standard restricts unit numbers to the range 1 through 99 (but the standard document costs US$140, so I haven't checked).

So I suggest the unit numbers in this part of the code be made smaller. I attach a version of the file in which they are set to 15, 25 ... 55.

#68 arango jcwarner Done nf_fread error checking
Description

In function ROMS/Utility/nf_fread2d, lines 223:237 *

      status=nf90_noerr
      IF (InpThread) THEN
        status=nf90_get_var(ncid, ncvarid, wrk, start, total)
        IF (status.eq.nf90_noerr) THEN
          ...
        END IF
      END IF

      ...

      IF (status.ne.nf90_noerr) RETURN

If the file is not read correctly, then "status" will not equal nf90_noerr, and the code will return. But we need to have the value of "nf_fread" set to = the value of status before the return happens. IF the file is read correctly, then at the bottom of nf_fread2d we have:

      nf_fread2d=status

so that is ok.

Suggest that we add a line

      nf_fread2d=status

before the return statement. This also needs to be addressed in read 3d, 4d.

#72 arango mathieu Postponed CELERITY_*, FORWARD_* and boundary variables.
Description

It is less a precise bug than a whole array of issues.

Option CELERITY_READ has the following properties:

  • It is not documented in cppdefs.h but it is not switched in globaldefs.h. I consider this to be a problem as in my mind it should be one and the other.
  • It occurs in checkdefs.F with the option FORWARD_READ but not in any other place. I suspect that this is a false dependency and that CELERITY_READ should be removed from line 522 in this line.
  • Appart from above dependency CELERITY_READ occurs always in conjuction with CELERITY_WRITE.

Option FORWARD_WRITE occurs in:

  • setting up boundary values with CELERITY_WRITE
    BOUNDARY(ng)%zeta_north ...
    
  • in doing write ups of data but not of BOUNDARY(ng) data. So either
    • remove the above dependency
    • add code for output of boundary data

Proposed solution:

  • Remove CELERITY_WRITE from cppdefs.h
  • Rename CELERITY_READ and CELERITY_WRITE to CELERITY.
  • Trigger CELERITY in globaldefs.h from FORWARD_WRITE if needed.
  • Trigger CELERITY in globaldefs.h if EAST_TRADIATION, EAST_FSRADIATION, EAST_M2RADIATION, EAST_M3RADIATION and the same for north, south, west.
Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.