Custom Query (964 matches)
Results (910 - 912 of 964)
Ticket | Owner | Reporter | Resolution | Summary |
---|---|---|---|---|
#905 | Done | VERY IMPORTANT: Enhanced Point Sources/Sinks Forcing | ||
Description |
The ROMS point sources and sinks specify river runoff, nutrients, and other passive tracer concentrations inflows in an application grid. There are two different ways to impose such Source/Sink forcing in ROMS:
It is now possible to use both methodologies in a single application. We can have some point sources/sinks operated with the LuvSrc switch and others worked with the LwSrc switch. However, applying both methods to the same grid location is incorrect. Thanks to John Warner for suggesting, coding, and testing this new capability. The metadata for the input Sources/Sinks forcing NetCDF file has been updated to facilitate the new capability: dimensions: s_rho = 13 ; river = 11 ; river_time = UNLIMITED ; // (745 currently) variables: double river(river) ; river:long_name = "river runoff identification number" ; double river_direction(river) ; river_direction:long_name = "river runoff grid-cell face flag" ; river_direction:flag_values = "0, 1, 2" ; river_direction:flag_meanings = "flow across u-face, flow across v-face, flow across w-face" ; double river_Xposition(river) ; river_Xposition:long_name = "river XI-coordinate location" ; river_Xposition:LuvSrc_meaning = "i-index grid cell of U- or V-face source/sink" ; river_Xposition:LwSrc_meaning = "i-index grid cell of W-face source/sink" ; double river_Eposition(river) ; river_Eposition:long_name = "river ETA-coordinate location" ; river_Eposition:LuvSrc_True_meaning = "j-index grid cell of U- or V-face source/sink" ; river_Eposition:LwSrc_True_meaning = "j-index grid cell of W-face source/sink" ; double river_Vshape(s_rho, river) ; river_Vshape:long_name = "river runoff mass transport vertical profile" ; river_Vshape:requires = "must sum to 1 over s_rho coordinate" ; double river_time(river_time) ; river_time:long_name = "river runoff time" ; river_time:units = "days since 2001-01-01 00:00:00" ; double river_transport(river_time, river) ; river_transport:long_name = "river runoff vertically integrated mass transport" ; river_transport:units = "meter3 second-1" ; river_transport:positive = "LuvSrc=T flow in positive u,v direction, LwSrc=T flow into grid cell" ; river_transport:negative = "LuvSrc=T flow in negative u,v direction, LwSrc=T flow out of grid cell" ; river_transport:time = "river_time" ; double river_temp(river_time, s_rho, river) ; river_temp:long_name = "river runoff potential temperature" ; river_temp:units = "Celsius" ; river_temp:time = "river_time" ; double river_salt(river_time, s_rho, river) ; river_salt:long_name = "river runoff salinity" ; river_salt:time = "river_time" ; In particular, the NetCDF variable river_direction flag (ROMS Dsrc variable) has a value of 2 to represent the location of the flow across the w-face cell, as illustrated below: Here, the river_direction variable name is confusing and not a good choice, but its value represents the point Source/Sink location on the grid cell. Dsrc(is) = 0, flow across grid cell u-face (positive or negative), LuvSrc = T Dsrc(is) = 1, flow across grid cell v-face (positive or negative), LuvSrc = T Dsrc(is) = 2, flow across grid cell w-face (positive or negative), LwSrc = T Notice that advection and divergence operators center the point Source/Sinks effect at the ρ-point (cell center) for all cases. For example, in step3d_t.F, we have the advective flux: IF (LuvSrc(ng)) THEN DO is=1,Nsrc(ng) IF (INT(SOURCES(ng)%Dsrc(is)).eq.0) THEN ... ! u-face ELSE IF (INT(SOURCES(ng)%Dsrc(is)).eq.1) THEN ... ! v-face END IF END DO END IF In omega.F, we have the divergence flux: IF (LwSrc(ng)) THEN DO is=1,Nsrc(ng) IF (INT(SOURCES(ng)%Dsrc(is)).eq.2) THEN ... ! w-face END IF END DO END IF WARNING: ROMS is now very strict to how Dsrc is used, as illustrated in the code snippet above. We recommend to revise your input files to use river_direction = 2 when LwSrc is used. It is an inconvenience but we are gaining flexibility. A new routine check_sources is added to module mod_sources.F to check and report about the correctness of river_direction in the input SSFNAME NetCDF file. We recommend checking the report in the standard output file: Point Sources/Sinks grid-cell flag locations counter: Grid: 1, file: Data/roms_riverplume1_uvw.nc LuvSrc = T u-face = 1 LuvSrc = T v-face = 0 LwSrc = T w-face = 10 RIVERPLUME1 Test Case:The River Plume Test 1 is reworked to include all the three possible values for Dsrc. We now use Netcdf files instead of ANA_GRID for the grid and instead of ANA_PSOURCE for point Sources/Sinks locations and properties. We have recommended using a NetCDF file instead of ANA_PSOURCE for a long time. However, there are posts in the Forum from users who ignore that advice. Moreover, it is tricky to code ana_psource.h for practical applications free of nasty shared-memory or distributed-memory parallel bugs. It is an important forcing, so be proactive follow the advice. In the test repository, you will find the following files in the riverplume/Data directory:
Notice that there is an input script for each case: roms_riverplume1_uv.in, roms_riverplume1_w.in, and roms_riverplume1_uvw.in. Also, the solutions with the estuary river located at u- or w-face of the cell are very similar (see src:ticket:860). It is a good way to test the correctness of the LuvSrc and LwSrc methods. |
|||
#906 | Fixed | IMPORTANT: Corrected structure syntax in equilibrium_tide.F | ||
Description |
The structures in equilibrium_tide.F were using . (dot, Matlab style) instead of % (percent for Fortran) in several places. We tested this algorithm in Matlab and missed changing the syntax when coding in Fortran. The weird think is that the ifort compiler accepts such syntax. It is scary! For example, we need to have: Q1%Afl=Q1%amp*Q1%f*Q1%love O1%Afl=O1%amp*O1%f*O1%love K1%Afl=K1%amp*K1%f*K1%love N2%Afl=N2%amp*N2%f*N2%love M2%Afl=M2%amp*M2%f*M2%love S2%Afl=S2%amp*S2%f*S2%love K2%Afl=K2%amp*K2%f*K2%love instead of Q1.Afl=Q1.amp*Q1.f*Q1.love O1.Afl=O1.amp*O1.f*O1.love K1.Afl=K1.amp*K1.f*K1.love N2.Afl=N2.amp*N2.f*N2.love M2.Afl=M2.amp*M2.f*M2.love S2.Afl=S2.amp*S2.f*S2.love K2.Afl=K2.amp*K2.f*K2.love Many thanks to Brian Powell and Guangpang Liu for reporting this bug. |
|||
#909 | Done | Tagged latest respository version as ROMS 4.0 | ||
Description |
The current trunk revision (-r 1108) is quite stable so we are tagging this as ROMS Version 4.0 and the beginning of ROMS Version 4.1. |