Jump to content
GMS, SMS, and WMS User Forum

Alan K. Zundel

SMS Development Team
  • Posts

  • Joined

  • Last visited

1 Follower

About Alan K. Zundel

Profile Information

  • Gender
  • Location
    Provo, UT

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Alan K. Zundel's Achievements


Newbie (1/14)



  1. Jeremy, The recommended method for do that is to use a rating curve. You can use the populate tool to compute a level for any flow in the expected range of flows that will occur during a hydrograph. This avoids needed to worry about latency and attenuation of the flow from the inflow to the outflow. Alan
  2. Don has reminded me that the default "Wall" boundary does have velocities of zero. I will be revising SRH-Post to treat walls as zero-velocity while wet/dry boundaries will still be scaled. In the future I hope to use both cell centered and edge values to give a more accurate representation of what SRH-2D is doing internally.
  3. Don, This changed as a result of update to SRH-2D 3.2. However, as I recall, the edge of the pier did not get assigned a zero velocity even in the old version. SRH-2D would assign values to the nodes from the cell centered values that it computes. The process used a simple averaging of the wet/active cells attached to each node. So for a pier wall, the velocity from the cell centers was mapped to the edge of the mesh. When 3.2 was released we detected that the node interpolation changed from the 3.1 and the activity mapping appeared to have an error. We asked the SRH-2D developer to investigate, the response was to use the cell centered data. To do this, we added the SRH-Post utility that runs after SRH-2D runs. SRH-2D creates an XMDFC.h5 file which includes values at cell centers and and cell based activity. SRH-Post reads this file and performs the interpolation to node based set of data sets. The typical interpolation from cell center to cell center includes: V(node) = Average( v(adjacent_wet_cells)) - This is done for all datasets ( WSE, Depth, Vx, Vy, Froude, Bed Shear) The complications to this approach include: 1- Interpolated water surfaces - Interpolated depths do not equal the nodal Z value. 2- Interpolated water surfaces at the node could be less than the nodal Z value (particularly when the node is at the edge of the mesh or on a lip of an embankment) 3- Interpolated velocity at the edge of a mesh would be too high because the "dry" cells are just ignored. Because of these observations, the old SRH-2D mapping to nodes would modify the basic interpolation to force the water level of a node attached to any active cell to be no lower than the Z value plus a minimum depth. This solved a "dry embankment lip" issue, but it resulted in what we have called the "warped water surface" issue at the edge of the wet region. SRH-Post currently does the following: a- Assigns activity for the nodes based on the rule that if any cell attached to a node is wet, the node is wet. This means that isolated "dry" cells will become wet. (In the future we will just use the cell activity directly.) This activity is now mapped to ALL of the datasets created by SRH-Post rather than just the WSE dataset as was computed in SRH-2D. b- Detects a lip as any node surrounded by all wet cells for which the (interpolated WSE - nodal Z) < (interpolated Depth/3). For these nodes the interpolated WSE is replaced with a value of (nodal Z + minimum adjacent cell depth) c- Detects a wet/dry interface as any node with at least one dry cell attached. For these nodes, the intepolated Depth is replaced with the value of (Interpolated WSE - Z) (Note: this can be negative). In addition, the velocity is reduced to a minimum of zero) based on the new depth. I am interested in feedback on this approach. If I have wrongly described how SRH-2D used to do the interpolation, please let me know. If you have other thoughts, please let me know.
  4. SRH-2D only plots the first two points in the graph while it runs and the model developer would like to remove that option to streamline computations. However, the model creates an output file for each monitor point in the folder where the model runs. You can open those at any time and see the values. To get a plot you have to use something like EXCEL. In future versions of SMS there will be an option to view any of the monitor point plots while the monitor runs.
  5. Where did your SOF file come from? Was it created when you launched SRH from inside of SMS? Which version of SMS are you using? SMS 11 used what SRH referred to as the "Full" interface. SMS 12 uses what SRH refers to as the "Custom" interface. If SMS 12.1 or SMS 12.2 are creating an incomplete SOF file, I would be very interested in getting the data files and resolving this issue as a bug.
  6. Hello. The SRH-2D simulation should be able to run from a previous project. The "sof.dat" file created by SRH-Pre will contain all the input that was processed by SRH-Pre. Looking at it or stepping through the SRH-Pre run in partial mode can give greater insight about what is not working. Another option would be to make sure you have exported the SRH input files again. That would replace all the input you have so you may want to save them for forensic reasons. Finally, if you submit your data files to the Aquaveo tech support group, we can evaluate the project to see what is wrong.
  7. What numerical model are you using that supports this function? The TUFLOW model allows for alterations of the elevation at a specific time in the simulation or based on a trigger. The AdH model automatically refines elements when the gradient across the element is larger than a specified amount. Other adaptation would need to be model specific. If you want to try your second approach, you have to specify the time to stop the initial run explicitly, then interpolate the solution to the refined/modiied grid, then restart the second run with a hotstart file.
  8. Amy, I just reviewed this with the tech support and here is what I understand: 1- The date in the "Time" tab is recorded with the SMS project. It is the intent of SMS that this date should be specified before extracting tidal constituents and be kept current with the boundary conditions being applied in the simulation. 2- The date in the "Tidal Constituent" tab comes from the ADCIRC control file. This means that the date is unknown. The tidal constituent tab allows the user to apply amplitudes and phases for the boundary nodes based on any tidal database, including those not supported from inside of SMS. This means that once the user specifies the tidal constituents, there is know way to verify the values short of performing the extraction again. 3- When SMS extracts tidal constituents from either the LeProvost or ADCIRC databases, the default date if populated with the reference date from the time tab. That does not mean that the user is forced to use that date. Since the user can provide any data he/she feels is appropriate, ADCIRC (and SMS) leave that responsibility with the user. The user could document the process he/she followed in the meta-data of the project. Therefore, my understanding is this: a- If the process is followed correctly, the user will specify a simulation reference date in the time tab and all data will be consistent with that date. b- The simulation reference date is preserved in the SMS project file. c- The user can further document the work that has been done in metadata for the project. d- Nothing is forcing the user to follow these practices, so a reviewer or engineer that is trying to apply the model must be careful not to assume too much, and may want to perform verifications. Do you have any suggestions that we could implement from an interface point of view to facilitate the process? Alan
  9. Amy, Did you load an SMS project, or just the ADCIRC control and grid files? Alan
  10. Karl, My guess is that this is a licensing bug on our end. Did you submit your map file that is causing the crash to our tech support? If we have the file I am sure we can get the issue resolved. Alan
  11. Amy, ADCIRC has not traditionally saved this date. It is used when you extract the tidal potential and tidal amplitude values from the database, but it is not saved in the fort.14 or fort.15. SMS saves it as part of the project that builds the ADCIRC files. If you have the ".sms" project file, it is there. You can view the value by loading the project into SMS and looking at the time control tab of the model control. You can also load the sms project file into HDFview which is a free viewer/editor for HDF5 files. There are some new features in ADCIRC that use the date, so this information may become part of the standard ADCIRC simulation. Alan
  12. Alfredo, You can email your files to support@aquaveo.com. If they are too large to attach, we have an anonymous ftp site. I would start with an email. If I (or tech support) could see your files I am sure we could get your problem resolved very quickly. If we can understand what has caused your confusion, we can post a notice to help others avoid it. Alan
  13. It sounds like the simulation is not getting the wave conditions saved correctly. The details of managing those files has changed between 11.0, 11.1 and 11.2, so depending on which version you are using it may require different checks from your part. If you go into the model control dialog, then into the boundary condition cases, and verify that the spectra are assigned there, that is the first step. If that looks right, you need to make sure SMS knows where the simulation is saving out. Doing a "Save As...|STWAVE" usually clarifies this. If all of that is already set, I would suggest you submit your files to Aquaveo tech support and we can get your problem resolved. Alan
  14. Emma, I am not sure exactly what issue you are talking about. The nodestrings do not require sequential node numbers, you just need to know which nodes make up each nodestring, and SMS saves all this information automatically in the fort.15. If you renumber nodes from a nodestring, SMS does assign the nodes in that nodestring the intial node IDs, but neither ADCIRC, nor SWAN care about that. We recommend that you use the global node numbering (added in SMS 11.1). Then none of the nodestrings will be numbered with sequential node IDs, but as I said, this is not an issue. There can be issues with multiple nodestrings connecting end to end. For that situation, you are best off merging the nodestrings into a single nodestring. This requires that the two nodestrings actually share one end point. Select both nodestrings, right click and select merge, and they become one nodestring. If the two nodestrings begin and end at separate nodes, they cannot be merged, but I think ADCIRC will still work for that case because the boundary conditions are actually assigned at the nodes. If this is not the problem you are encountering, please clarify and we can try again. Alan
  15. Heeyoon, The dx value for LTEA does not control the mesh size. The mesh size comes from a distribution of nodes based on the LTEA ananlysis and result in a specified target number of nodes. The dx value is a base grid size utilized by the LTEA calculations. Basically, it is the limits the how quickly the distribution can change in more than a linear fashion. Alan
  • Create New...