Custom Query (964 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (280 - 282 of 964)

Ticket Owner Reporter Resolution Summary
#377 arango jcwarner Fixed make bug on cygwin
Description

A few months ago, a correction was made in the makefile to correctly use

source-to-object = $(call source-dir-to-binary-dir,   \
                   $(subst .F,.o,$1))

The word 'binary' was misspelled, and is now correct. However, that fix has created a problem. I can not correclty build on Cygwin. Cygwin now creates *.obj files. The Cygwin-ifort.mk file has a catch to force ifort to make *.o not *.obj using

%.o: %.f90
	cd $(SCRATCH_DIR); $(FC) -c $(FFLAGS) $(notdir $<) /object:$(notdir $@)

However, this line is not invoked anymore. I traced it back to the makefile, and was able to get it to build correctly by modifying line 278-279 from

  $1: $2 $3
	cd $$(SCRATCH_DIR); $$(FC) -c $$(FFLAGS) $(notdir $2)

to

  $1: $2 $3
	cd $$(SCRATCH_DIR); $$(FC) -c $$(FFLAGS) $(notdir $2) /object:$(notdir $1)
#378 arango arango Fixed SOURCE(ng)%Ltracer and SOURCE(ng)%Lsrc
Description

The variables SOURCE(ng)%Ltracer and SOURCE(ng)%Lsrc were removed in src:ticket:376. However, this variables were still used in get_data.F and set_data.F. Now, only the variable LtracerSrc(itrc,ng) needs to be used. This variable is now declared in mod_scalars.h.

Many thanks to Mathieu Dutour for reporting this bug.

#380 arango m.hadfield Fixed Operations on uninitialized data in NETCDF_GET_FVAR_1D
Description

I have a limited-area ocean modelling application in which the usual variables are being read from a boundary file. On one of the platforms I run this on (Cray T3E), it fails in netcdf_get_fvar_1d with a message about an invalid floating-point value. The failure occurs somewhere in the following section of code:

        DO i=1,Asize(1)
          IF (ABS(A(i)).ge.ABS(Aspval)) THEN
            A(i)=0.0_r8
          ELSE
            A(i)=Afactor*A(i)+Aoffset
          END IF
        END DO

I set up a toy example with Lm=78, Mm=87 and N=25, serial with 1 tile in each direction. The failure occurred when reading vbar data from the southern boundary. netcdf_get_fvar_1d was being called by get_ngfld with the optional argument total set to 80 (the number of v points on the southern boundary, as expected) and being passed a 1D array much larger than this: I think the size was 2025 or 2225. In the above loop, Asize(1) was set to the size of the output array and the failure occurred on the 81st point, which had a value of NaN.

As I said, this failure occurs on only one platform, but processing uninitialized values is always dangerous and, in this case, inefficient: why process 2000-odd values when you only want 80 of them?

The fix I propose is to set Asize to the size of the data returned from the netCDF file, if that differs from the size of the output array. So the following

        Asize(1)=UBOUND(A, DIM=1)

becomes

      IF (PRESENT(start).and.PRESENT(total)) THEN
        Asize=total
      ELSE
        Asize(1)=UBOUND(A, DIM=1)
      END IF

NB: I test for the presence of both start and total because that is the test done when nf90_get_var is called.

I see no reason not to apply the same logic to all the netcdf_get_$var_$d routines, so I have done so in my copy of the source code, which is here:

https://www.myroms.org/projects/omlab/browser/branches/hadfield/trunk/ROMS/Modules/mod_netcdf.F

PS: I don't know why get_ngfld is creating such a large array to collect 1D boundary data, but I presume the same array is being used for other purposes.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.