Please see also the ADCIRC FAQ available at the Inundation Science and Engineering Cooperative (ISEC): http://isec.nacse.org/models/description/3 (courtesy of the Northwest Alliance for Computational Science and Engineering, NACSE).
Q: When running ADCIRC, there are messages printed to the screen that say 'WARNING: Elevation.gt.WarnElev' … what does that mean?
This means that the water surface elevation solution is farther above the geoid than the 'warning' threshold level.
Typically, this means that the water surface elevation solution is growing larger than expected which often indicates a growing instability. So why not just halt execution when this sort of solution begins to form? Well, due to very large tidal ranges in certain parts of the world, very high water elevations (e.g. 10 meters) are *possible*, and therefore ADCIRC will merely log a warning at this point—not shut down the run.
There is also an 'error' water level (e.g. 1000 meters) at which the solution is clearly erroneous, causing ADCIRC to halt execution. The details of this warning/error check behavior depend on certain hard coded threshold levels. The default values for warning/error are:
WarnElev = 20.0 meters ErrorElev = 1000.0 meters.
Q: I have made an ADCIRC mesh for my area of interest, but the resulting ADCIRC simulation is unstable, even with a very small time step. What should I do?
A: Here are some places to start:
Q: I have received an error like “forrtl: severe (x): attempt to blah blah blah” where x is a number and blah blah blah is some sort of error message. What does this mean?
A: This message was not produced by ADCIRC. It was produced by the library that comes with the Intel Fortran Compiler. For more detailed descriptions of the meaning of all these sorts of messages, please refer to the Run-Time Error Messages site.
Q: What utilities are available for working with ADCIRC input and output?
A: There are utilities available on the ADCIRC webpage at http://adcirc.org/Utility_programs.html. There are also many utilities that have been developed by various members of the ADCIRC community for their personal use. Please submit a question to the ADCIRC mailing list to find out what may already be available.
Q: Can the passive scalar transport in ADCIRC be used? The user manual lists this option as “not fully implemented.” What, exactly, does this mean? Will it not give reliable results?
A: (Jason Fleming): Passive scalar transport is not the preferred approach to doing tracking studies of conserved quantities in the production version of ADCIRC. Instead, ADCIRC users generally take current velocity output data and run it through a separate code that they have written to advect clouds of virtual drifters.
This approach is used because the production version of ADCIRC uses the Continuous Galerkin (CG) finite element formulation which guarantees mass conservation along the boundary, but not element-by-element mass conservation. Therefore, it is possible to have mass conservation errors when tracking a conserved scalar in CG ADCIRC.
There is also a Discontinuous Galerkin (DG) formulation of ADCIRC, which does guarantee element-by-element mass conservation. The DG code shows a lot of promise, but it is still at the research stage.
(David Hill): We have written some scripts (matlab) to do this. They use a 4th order Runge-Kutta scheme to integrate the velocity fields and compute trajectories. We have wondered, however, about the appropriate (output) time interval in the fort.64 file. We have erred on the side of accuracy (we have very complicated domains) and use output every 5 or 10 minutes. For large domain simulations, if one wants to track particles over several days / weeks…we are talking about a huge file. Then, each time you wish to place and track particles, the integration process is very slow. With much larger time intervals, however, too many particles seem to drift out of the domain. I have had, on my wish list (listen up, programmers!), a way in Adcirc to (some fort input file) to, at the start of a simulation, specify initial drifter locations and 'on' and 'off' times. Then, when the simulation is run, Adcirc would, on the fly, compute the trajectories and store the output in an output file. With the DG version of the code, will something like this be implemented in the future?
(John David Howlett): The model PTM may be of interest to you. An interface for PTM has been developed in SMS. PTM uses the hydrodynamic output from ADCIRC (and other models).
http://xmswiki.com/wiki/SMS:PTM
The Particle Tracking Model (PTM) is a Lagrangian particle tracker designed to allow the user to simulate particle transport processes. PTM is funded through two US Army Corps of Engineers Engineering Research and Development Center (ERDC) research programs, the Coastal Inlets Research Program (CIRP) and the Dredging Operations and Environmental Research (DOER) Program.
PTM has been developed for application to dredging and coastal projects including dredged material dispersion and fate, sediment pathway and fate, and constituent transport. The model contains algorithms that appropriately represent transport, settling, deposition, mixing, and resuspension processes in nearshore wave/current conditions. It uses waves and currents developed through other models and input directly to PTM as forcing functions.
(Nate Dill): Check out chapter 3 and the associated appendix
http://etd.lsu.edu/docs/available/etd-06142007-084318/
maybe too slow for a big ADCIRC grid, but it uses Scilab which is free so you don't need $$$ for SMS or Matlab. Was working on a much faster fortran version but not quite finished yet, email me if interested.