Set Up Boundary Conditions about clearwater-riverine HOT 12 CLOSED

I accessed information on boundary conditions in RAS HDF output as follows:

with h5py.File(fpath, 'r') as infile:
    project_name = cwr.parse_project_name(infile)
    external_faces = pd.DataFrame(infile['Geometry/Boundary Condition Lines/External Faces'][()])
    attributes = pd.DataFrame(infile['Geometry/Boundary Condition Lines/Attributes/'][()])

In the attributes table, we find the name of each boundary condition. The index of each boundary condition in that table relates it to the external_faces table (specifically, to the BC Line ID field). The external_faces table then has information linking each BC Line ID to a Face Index in RAS.

The model was set up to aggregate boundary conditions that were associated with the same cell/face in RAS. These were set up so that if there were more than 3 EFDC boundary conditions were coming into a single cell, the boundary would be distributed over 2 RAS cells. Otherwise, the boundary conditions were associated with 1 RAS cell.

However, while exploring boundary conditions to set up dummy inputs, I found that certain BC Line IDs were associated with hundreds of faces in the RAS2D output file, and that certain boundary conditions corresponded to overlapping faces, even though we explicitly set up the model so that this would not be true.

@jrutyna looked at the RAS model and found that the boundary conditions do not (visually) appear to be configured this way. He also ran a test where he added a boundary condition line and found that it only corresponded to a single cell/face, as expected.

I then checked in with Nick, and he said he would do some troubleshooting to (a) make sure that boundary flows are not being added multiple times and (b) see if it is possible correct the boundary condition / face index relationship in the RAS output.

If we cannot resolve this, we will need to create a lookup table ourselves that designate which face(s) are associated with each boundary condition.

from clearwater-riverine.

@sjordan29, thanks for that detailed report, and for arranging for @jrutyna & @McGrupp10 (Nick) to follow up!

@McGrupp10, let us know what you find with this RAS2D Boundary Condition issue!

from clearwater-riverine.

@jrutyna did some digging and was able to re-configure the boundary conditions. He didn't find a general rule on which BCs were causing issues, but did find the following (correct me if I'm wrong on these, @jrutyna):

• Boundary conditions distributed over 3 or more cells were fine (meaning the boundary condition was associated with the expected cells in RAS)
• Boundary conditions distributed over 2 cells were never fine (meaning, the boundary condition was associated with the expected cells in RAS, but was also associated with unexpected cells in RAS that it should not have been associated with
• Some boundary conditions flowing into a single cell were not fine, but most were fine.

Next steps for @sjordan29:

• Read updated RAS model corrected BC geometry.
• Resolve units (cfu/100 ml vs mg/L).
• Use E. coli boundary condition timeseries defined by @jrutyna to set up a model run with boundary conditions.

from clearwater-riverine.

@sjordan29, thanks for that update!
@jrutyna, thanks for figuring it all out!

from clearwater-riverine.

@aufdenkampe, I provided a work around for the issue to get us moving forward. The "problem" boundary condition lines with either 2 cell external faces or 1 cell external face were shorten until the boundary condition was only associated with 1 external face. Unfortunately, this will not match exactly with the EFDC model, but I think it will be close enough--we will need to look at the side-by-side comparison to see if we like this work around.

If we want to solve this issue completely so a future user does not encounter it for another application, I see three paths forward:

1. Report this issue as a bug to the HEC-RAS developers so they can fix it, or
2. Develop a similar geo-processing tool that HEC-RAS performs to identify external faces from the boundary condition line,
3. Develop a method from the face flow results to identify which external faces have flows coming in/out of the model domain and use these faces as a lookup in the Geometry/Boundary Condition Lines/External Faces table

@aufdenkampe and @sjordan29 please let me know what you think about the proposed paths forward.

from clearwater-riverine.

A bug report was emailed to the HEC-RAS developers. The following is a copy of the email:

I am reporting the following bug to the HEC-RAS development team. Please let me know if you need additional information to troubleshoot the issue I outlined below:

1. Contact Information: Name, Phone Number, and E-mail Address.
   • Jason M. Rutyna, P.E.
   • 734-332-1200
   • [email protected]

2. What version of the software are you using?

3. What operating system are you using?

4. A detailed explanation of the problem (e.g., "Levee option on Cross Section editor not functioning correctly").
   • The “Geometry\Boundary Condition Lines\External Faces” table in the hdf5 file that is generated after the simulation is complete has numerous extra external faces. In the example shown below for “MillCreek_External” boundary condition line, I expected two external faces, but over a thousand external faces are associated with boundary condition line 4.

5. If the problem is reproducible, please list the steps required to re-create the problem (e.g., "1. Create a new file. 2. Insert some text ...).
   • Yes, I can reproduce the issue. I did the following in the same test case I am sending:
   a) Created a new boundary condition line in RAS Mapper called “debug_test”
   b) Added an arbitrary flow time series
   c) Ran the simulation
   d) Viewed the hdf5 simulation results file
   e) Verified that “debug_test” boundary condition line created numerous external faces associated with this boundary condition (as seen in the screen shot below)
   

6. If the problem is not reproducible (only happened once, or occasionally for no apparent reason) please describe the circumstances in which it occurred and the symptoms observed (Note: it is much harder to fix non-reproducible bugs).
   • N/A

7. If the problem causes any error messages to appear, please write down the exact text displayed, or capture it from the screen and paste into the email.
   • No error messages appeared—the simulation finished normally

8. If you have an HEC-RAS data set that demonstrates the problem, use the HEC-RAS "Debug Report" option to zip up the data set. Then attach the zip file to the email. The "Debug Report" option is under the "File" menu on the main HEC-RAS window. If the data set is too large for an email attachment, then you will need to send it by some form of ftp server, Google Drive, or some other file sharing capability. If you are using the two-dimensional modeling capabilities, we will also need the HEC-RAS terrain model files (*.tif, *.hdf, and *.vrt).
   • Here is a link to a zipped copy of a simulation (it is about 5GB, most of the file size is the terrain files): LinkToGoogleDrive

from clearwater-riverine.

Based on the availability of E. Coli data, @jrutyna decided that we should provide a comparison from 5/29/2010 00:00 to 7/06/2010 00:00, which has good data coverage and several pulses of high upstream E. Coli concentrations:

Updated boundary conditions are saved under examples/data/EFDC_to_ClearWater_EcoliConc_for_ORR20_2010_simulation_B.csv.

from clearwater-riverine.

@jrutyna, I noticed in the Ohio River example notebook, that not all boundary lines have e. coli values for all timesteps. See Code Block 64, which prints the RAS2D timeseries name, associated face index, and number of times that contain data for that timeseries. You'll see certain timeseries (e.g., Flow_TS_283, Flow_TS_284, Flow_TS_296, etc) do not have data for all 913 timesteps.

Is this expected? Will we need to interpolate data, or is a "no data" value interpreted as 0 in EFDC?

from clearwater-riverine.

@jrutyna confirmed that if there is no data, the value should default to 0.

from clearwater-riverine.

Looking at each boundary condition timeseries, it looks like Flow_TS_IJ206_369_multi (light blue line) has some extreme spikes. @jrutyna can you confirm these values are accurate?

from clearwater-riverine.

@jrutyna confirmed that the calculation is being performed correctly based on the information we have from the qser and dser files.

from clearwater-riverine.

Initial boundary condition set-up is complete. Closing this issue - future work refactoring boundary conditions and expanding capabilities should be tracked in #17 or other future issues.

from clearwater-riverine.