wiki:TracQuery

Trac Ticket Queries

In addition to reports, Trac provides support for custom ticket queries, which can be used to display tickets that meet specified criteria.

To configure and execute a custom query, switch to the View Tickets module from the navigation bar, and select the Custom Query link.

Filters

When you first go to the query page, the default filter will display tickets relevant to you:

  • If logged in then all open tickets, it will display open tickets assigned to you.
  • If not logged in but you have specified a name or email address in the preferences, then it will display all open tickets where your email (or name if email not defined) is in the CC list.
  • If not logged in and no name/email is defined in the preferences, then all open issues are displayed.

Current filters can be removed by clicking the button to the left with the minus sign on the label. New filters are added from the dropdown lists at the bottom corners of the filters box; 'And' conditions on the left, 'Or' conditions on the right. Filters with either a text box or a dropdown menu of options can be added multiple times to perform an Or on the criteria.

You can use the fields just below the filters box to group the results based on a field, or display the full description for each ticket.

After you have edited your filters, click the Update button to refresh your results.

Clicking on one of the query results will take you to that ticket. You can navigate through the results by clicking the Next Ticket or Previous Ticket links just below the main menu bar, or click the Back to Query link to return to the query page.

You can safely edit any of the tickets and continue to navigate through the results using the Next/Previous/Back to Query links after saving your results. When you return to the query any tickets which were edited will be displayed with italicized text. If one of the tickets was edited such that it no longer matches the query criteria , the text will also be greyed. Lastly, if a new ticket matching the query criteria has been created, it will be shown in bold.

The query results can be refreshed and cleared of these status indicators by clicking the Update button again.

Saving Queries

Trac allows you to save the query as a named query accessible from the reports module. To save a query ensure that you have Updated the view and then click the Save query button displayed beneath the results. You can also save references to queries in Wiki content, as described below.

Note: one way to easily build queries like the ones below, you can build and test the queries in the Custom report module and when ready - click Save query. This will build the query string for you. All you need to do is remove the extra line breaks.

Note: you must have the REPORT_CREATE permission in order to save queries to the list of default reports. The Save query button will only appear if you are logged in as a user that has been granted this permission. If your account does not have permission to create reports, you can still use the methods below to save a query.

You may want to save some queries so that you can come back to them later. You can do this by making a link to the query from any Wiki page.

[query:status=new|assigned|reopened&version=1.0 Active tickets against 1.0]

Which is displayed as:

Active tickets against 1.0

This uses a very simple query language to specify the criteria, see Query Language.

Alternatively, you can copy the query string of a query and paste that into the Wiki link, including the leading ? character:

[query:?status=new&status=assigned&status=reopened&group=owner Assigned tickets by owner]

Which is displayed as:

Assigned tickets by owner

Customizing the table format

You can also customize the columns displayed in the table format (format=table) by using col=<field>. You can specify multiple fields and what order they are displayed in by placing pipes (|) between the columns:

[[TicketQuery(max=3,status=closed,order=id,desc=1,format=table,col=resolution|summary|owner|reporter)]]

This is displayed as:

Results (1 - 3 of 895)

1 2 3 4 5 6 7 8 9 10 11
Ticket Resolution Summary Owner Reporter
#896 Done VERY IMPORTANT: Adding Tide Generating Forces (TGF) arango
#895 Done IMPORTANT: 4D-Var observation operator - observation depths arango
#894 Done IMPORTANT: Updated 4D-Var observation operator arango
1 2 3 4 5 6 7 8 9 10 11

Full rows

In table format you can also have full rows by using rows=<field>:

[[TicketQuery(max=3,status=closed,order=id,desc=1,format=table,col=resolution|summary|owner|reporter,rows=description)]]

This is displayed as:

Results (1 - 3 of 895)

1 2 3 4 5 6 7 8 9 10 11
Ticket Resolution Summary Owner Reporter
#896 Done VERY IMPORTANT: Adding Tide Generating Forces (TGF) arango
Description

I implemented the astronomical Tide Generating Forces (TGF) in ROMS 2D and 3D pressure gradient routines. They are coded in terms of the equilibrium tide (ζeq), defined as the shape that the sea surface (m) would assume if it were motionless and in equilibrium with the TGF on a fluid plane (Arbic et al., 2018).

It is activated with the option TIDE_GENERATING_FORCES. It is restricted to spherical grids since we need (lon, lat) of every cell to compute the harmonic constituents parameters for the location of the Moon and Sun. We recommend activating this option in conjunction with boundary tidal forcing (SSH_TIDES and UV_TIDES).

Thanks to John Wilkin for writing the implementation documentation (including equations and harmonics) and the Matlab scripts to compute the equilibrium tide offline and examine the harmonic parameters. Basically, the pressure gradient terms are of the form:

-g (∂(ζ - ζeq))/∂x
-g (∂(ζ - ζeq))/∂y

where g is the acceleration due to gravity (m/s2), ζ is the surface elevation (m), and ζeq is the equilibrium tide (m).

During its implementation, I examined and tested the 3D and 2D pressure gradient algorithms in ROMS. I discovered a but in prsgrd32.h (activated with DJ_GRADPS). This issue is discussed in detail in following forum post.

Two new routines were added:

  • ROMS/Utility/equilibrium_tide.F: module containing routines to compute the equilibrium tide (equilibrium_tide) at every timestep and the harmonic constituents parameters (harmonic_constituents) once during initialization. The equilibrium tide is save in state variable OCEAN(ng)%eq_tide.
  • ROMS/Utility/tides_date.F: Routine to checkout the input time reference parameter TIDE_START, defined as the time of phase zero when preparing the input tidal boundary data NetCDF file specified in TIDENAME.

Currently, there are two ways to specify the tide_start ROMS variable in an application:

(1) Set the zero_phase_date variable in the input tidal forcing NetCDF file (recommended). It a floating-point variable of the form YYYYMMDD.dddd with the following NetCDF metadata:

variables:
        double zero_phase_date ;
                zero_phase_date:long_name = "tidal reference date for zero phase" ;
                zero_phase_date:units = "days as %Y%m%d.%f" ;
                zero_phase_date:C_format = "%13.4f" ;
                zero_phase_date:FORTRAN_format = "(f13.4)" ;

For example, if the tide reference date is 2005-01-01 12:00:00, the zero_phase_date = 20050101.5000:

data:

 zero_phase_date = 20060101.0000 ;

Again, it corresponds to the zero tidal phase when preparing the forcing NetCDF file from the tides dataset (say, OTPS).

Use script forcing/add_tide_date.m from the ROMS Matlab repository to add the zero_phase_date variable to your existing tidal forcing NetCDF file:

>> add_tide_date('my_frc_tides.nc', datenum(2006,1,1))

It is highly recommended to use this approach. If such a variable is found, the TIDE_START value will be overwritten.

Notice that it is possible to have different reference values for zero_phase_date and ROMS clock defined as seconds from reference date (standard input parameter TIME_REF). If ROMS variable time_ref is earlier than zero_phase_date, the frequencies (omega) to harmonic terms will be negative since they are computed as follows:

     tide_start = Rclock%tide_DateNumber(2) - Rclock%DateNumber(2))
     omega = 2 * pi * (time - tide_start) / Tperiod

Notice that tide_start (in seconds) is recomputed, and the value specified in the input standard file is ignored.

If the variable zero_phase_date is found, ROMS will report to standard output:

 TIDES_DATE - Checking tidal reference date for zero phase:
                zero_phase_date = 20060101.0000 (read from ../../../om/doppio_tide_7km.nc)
                tide_DateNumber =   732678.0000 (2006-01-01 00:00:00)
                old tide_start  =        0.0000 (days)
                new tide_start  =        0.0000 (days)

(2) The specify TIDE_START in the ROMS standard input file as days from the application reference time (TIME_REF) is used it the variable zero_phase_date is not found in the NetCDF file. In the input standard input file we have:

  TIDE_START =  0.0d0                      ! days
  TIME_REF   =  20060101.0d0               ! yyyymmdd.dd

Usually, tide_start = 0 implies that the zero-phase tidal forcing date is the same as the application reference date time_ref. ROMS does not know how to check if it is the case. Thus, it is assumed that the user was careful when configuring their application.

In this case, ROMS will report to standard output:

  TIDES_DATE - Checking tidal reference date for zero phase:
                 'zero_phase_date' variable not found in ../../../om/doppio_tide_7km.nc)
                 given tide_start  =        0.0000 (days)
                 tide_DateNumber   =   732678.0000 (2006-01-01 00:00:00)

This capability was also added to the ADM, TLM, and RPM pressure gradient routines. However, I noticed that it slows the 4D-Var algorithm convergence. I need to test in other applications.

I look forward to advanced users helping us test the TGF implementation in their tide forced applications.


Below are two figures that show the sea surface elevation in the center of the Gulf of Maine (top) and at the entrance of the Bay of Fundi (bottom). ROMS is configured with boundary tidal forcing, tide generating force, and inverted barometer effect in the pressure gradient.

http://www.myroms.org/trac/doppio_tides_GOM.png http://www.myroms.org/trac/doppio_tides_BayFundi.png

As expected, the TGF makes very small corrections to the boundary tidal forcing. It implies that the tide boundary forcing is well calibrated for this application. Users will need to activate both tidal forcings (SSH_TIDES, UV_TIDES, TIDE_GENERATING_FORCES). The ATM_PRESS is activated for all solutions.


WARNINGS:

  • All the standard input files (roms_*.in) in the repositories were modified to add the Lnodal input switch for the TGF harmonics:
    ! If tide generating forces, set switch (T/F) to apply an 18.6-year lunar
    ! nodal correction to equilibrium tide constituents.
    
          Lnodal =  T
    
  • The file varinfo.dat was updated to include the zero_phase_date metadata:
    'zero_phase_date'                                  ! Input
      'tidal reference date for zero phase'
      'days as %Y%m%d.%f'                              ! YYYYMMDD.dddd
      'nulvar'
      'nulvar'
      'idTref'
      'nulvar'
      1.0d0
    

References:

Arbic, B.K., Garner, S.T., Hallberg, R.W. and Simmons, H.L., 2004: The accuracy of surface elevations in forward global barotropic and baroclinic tide models, Deep Sea Research Part II: Topical Studies in Oceanography, 51(25-26), pp. 3069-3101.

Arbic, B.K., Alford, M.H., Ansong, J.K., Buijsman, M.C., Ciotti, R.B., Farrar, J.T., Hallberg, R.W., Henze, C.E., Hill, C.N., Luecke, C.A. and Menemenlis, D., 2018: Primer on Global Internal Tide and Internal Gravity Wave Continuum Modeling in HYCOM and MITgcm. In: New Frontiers in Operational Oceanography, E. Chassignet, A. Pascual, J. Tintoré and J. Verron (Eds.), GODAE OceanView?, 307-392, doi: 10.17125/gov2018.ch13

Doodson, A.T. and Warburg, H.D., 1941: Admiralty Manual of Tides. His Majesty’s Stationery Office, London, UK, 270 pp.

Egbert, G.D. and Ray, R.D., 2017: Tidal prediction, Journal of Marine Research, 75(3), pp.189-237.

#895 Done IMPORTANT: 4D-Var observation operator - observation depths arango
Description
  • The obs_depth variable in the input observation NetCDF file can be specified as negative values in meters or nondimensional, positive, fractional vertical coordinates ranging from 1.0 to N, where N is the number of vertical levels. Recall that in ROMS level N is located next to sea-surface, as shown below: http://www.myroms.org/trac/vertical_grid.png
  • The observation operator was modified to allow both vertical location conventions (meters and fractional) in the variable obs_depth for specific data. Recall that in ROMS, the vertical grid locations are time-dependent due to the evolution of the free surface, which may include tidal forcing or not. Therefore, ROMS will interpolate from depths in meters to the fractional vertical coordinate when computing 4D-Var prior trajectory (background phase) at the observation locations in time and space. Then, the fractional vertical coordinates are written into the obs_Zgrid of the input observation NetCDF file. As a result, we always recommend making a copy of the input observation NetCDF before running a 4D-Var data assimilation cycle if you want to preserve the original file. However, notice that obs_Zgrid is only needed internally in ROMS by the tangent linear and adjoint kernels during the inner-loops minimization when processing the linearized observation operator, H(x).
  • Surface observations are tricky. Therefore, we usually use the fractional vertical coordinate for SSH, SST, SSS, and HFR observations as obs_depth=N. However, notice that level N depth is located at the middle of the top grid cell, as shown above. All the ROMS state variables used in the data assimilation are vertically located at the grid cell center (finite volume sense), vertical RHO-point. Using zero as surface depth is problematic due to its floating-point bit representation. IEEE-754 allows positive and negative zero. The representation of zero using sign bit, biased exponent, and a fraction is subject to roundoff due to precision. There is not an absolute zero value in computers. Using negative depths for surface observations, say obs_depth=-0.005 m, it will be assigned a obs_Zgrid=N in the fractional coordinate because such depth is above the top grid cell middle depth.
  • Minor changes are made to obs_depth.F and obs_write.F to allow both vertical location conventions in obs_depth NetCDF variable. Thanks to Brian Powell for bringing this issue to my attention and providing a test case to debug.
  • The variables time and tdays are initialized to zero in mod_scalars.F to avoid segmentation faults in some computer during 4D-Var prior error phase. Such variables haven't been assigned yet in the prior error phase. We may get some unwanted Fortran error when calling time_string in get_state.F with an uninitialized time variable:
         CALL time_string (time(ng), time_code(ng))
    
    This issue was discovered in the ROMS-JEDI interface. The ctest command was failing when running the JEDI unit tests.
#894 Done IMPORTANT: Updated 4D-Var observation operator arango
Description
  • This update enhances the observation operator to allow the input NetCDF variable obs_depth to have the data vertical location specified as a negative value (depths in meters), a positive value (fractional vertical coordinate ranging from 1:N), or a combination of both conventions.

Recall that during initialization, the ROMS 4D-Var algorithm always processes obs_depth from the input observations NetCDF file. Then, it will update the obs_Zgrid variable with all depths in fractional vertical coordinates. The obs_Zgrid variable is used after initialization in the inner loops to facilitate the vertical interpolation of the TLM and ADM state at the observation locations.

Many thanks to Brian Powell for bringing this issue to my attention. Before, it only worked if the user selected a single convention for all the observations in the file (negative depths or positive vertical fractional coordinate).

  • Updated extract_obs.F and ad_extract_obs.F to avoid rejecting observation depths above the center of the top vertical grid cell, k=N(g). Recall that ROMS vertical grid is staggered with 3D variables (u, v, T, S, ...) located at the center of the grid cell. Notice that W-type variable are located at the bottom and top of the grid cell.

http://www.myroms.org/trac/vertical_grid.png

Thus, now we have:

           ...
           Ztop=Adepth(i1,j1,N(ng))
           Zbot=Adepth(i1,j1,1    )
           IF (Zobs(iobs).ge.Ztop) THEN
             k1=N(ng)                         ! If shallower, assign to
             k2=N(ng)                         ! top grid cell. The
             r1=1.0_r8                        ! observation is located
             r2=0.0_r8                        ! on the upper cell half
             Zobs(iobs)=REAL(N(ng),r8)        ! above its middle depth.
           ELSE IF (Zbot.ge.Zobs(iobs)) THEN
             r1=0.0_r8                        ! If deeper, ignore.
             r2=0.0_r8
             ObsVetting(iobs)=0.0_r8
           ELSE
             ...

Many thanks to Brian Powell for bringing this issue to my attention. It is only relevant when processing vertical observations as negative depths in meters.

  • Updated read_asspar.F and read_phypar.F to avoid a hanging-up in MPI application when find_file triggers an exit during ROMS configuration due to the wrong specification of input NetCDF files by the User.
1 2 3 4 5 6 7 8 9 10 11

Query Language

query: TracLinks and the [[TicketQuery]] macro both use a mini “query language” for specifying query filters. Filters are separated by ampersands (&). Each filter consists of the ticket field name, an operator and one or more values. More than one value are separated by a pipe (|), meaning that the filter matches any of the values. To include a literal & or | in a value, escape the character with a backslash (\).

The available operators are:

= the field content exactly matches one of the values
~= the field content contains one or more of the values
^= the field content starts with one of the values
$= the field content ends with one of the values

All of these operators can also be negated:

!= the field content matches none of the values
!~= the field content does not contain any of the values
!^= the field content does not start with any of the values
!$= the field content does not end with any of the values

The date fields created and modified can be constrained by using the = operator and specifying a value containing two dates separated by two dots (..). Either end of the date range can be left empty, meaning that the corresponding end of the range is open. The date parser understands a few natural date specifications like "3 weeks ago", "last month" and "now", as well as Bugzilla-style date specifications like "1d", "2w", "3m" or "4y" for 1 day, 2 weeks, 3 months and 4 years, respectively. Spaces in date specifications can be omitted to avoid having to quote the query string.

created=2007-01-01..2008-01-01 query tickets created in 2007
created=lastmonth..thismonth query tickets created during the previous month
modified=1weekago.. query tickets that have been modified in the last week
modified=..30daysago query tickets that have been inactive for the last 30 days

See also: TracTickets, TracReports, TracGuide, TicketQuery

Last modified 4 years ago Last modified on Jun 20, 2017 2:27:28 PM