Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test 5, 10, 15 timestep for Larger Sumwere Creek #70

Closed
sjordan29 opened this issue Apr 3, 2024 · 20 comments · Fixed by #74
Closed

Test 5, 10, 15 timestep for Larger Sumwere Creek #70

sjordan29 opened this issue Apr 3, 2024 · 20 comments · Fixed by #74
Assignees

Comments

@sjordan29
Copy link
Contributor

We have increased the domain size of sumwere creek. Re-run the 100 everywhere test at 5, 10, 15 second timesteps and look at percent error in the output. This will help speed up demonstrations.

@sjordan29 sjordan29 self-assigned this Apr 3, 2024
@sjordan29
Copy link
Contributor Author

At first, I was getting very large percent errors (45% to >100%). I realized when I compared to the _global_mass_bal_100_Ans test that I had an error in the _mass_flux calculation method used in the _global_mass_bal calculation -- I wasn't multiplying by the change in time! I made those updates in commit 841cbfd12a1cc4f68e1dcef5703e46e98a88142e in transport.py

And I get the following:
image

Looks like 15 second output should be fine to move forward with @jrutyna @aufdenkampe

@aufdenkampe
Copy link
Member

@sjordan29, that's great to see!
I assume you saw a proposal improvement in the run time, right?

@sjordan29
Copy link
Contributor Author

I never ran the 3-day 1-second simulation with Clearwater-Riverine alone (only with modules). Initializing and running these models took:

  • 15-second: 3 min 21 sec
  • 10-second: 5 min 10 sec
  • 5-second: 10 min 05 sec

This would suggest that the 1-second output would take ~50-51 minutes, but not sure how the increase in memory might impact. We could run it without modules as a point of reference, but modules was the major slowdown with the 3-day simulation.

Jason just sent a 30-second model for me to test, as well as a 5, 10, 15, and 30 second output for a scaled up fine mesh. Jason notes that the 30 sec output for the fine mesh violates the courant condition near the downstream end of the domain since the water is moving slightly more than 0.5 m/s and the cells in the channel are only 20 m^2. I will check dye results in this area to see if they make any sense.

@sjordan29
Copy link
Contributor Author

The 30 second coarse mesh model had a percent error of 0.017549% and ran in 1 min, 43 seconds.

@jrutyna
Copy link
Collaborator

jrutyna commented Apr 5, 2024

How do the volume errors compare among the four coarse mesh model simulations?

@sjordan29
Copy link
Contributor Author

  • 05-sec: 7.886954666670261e-05
  • 10-sec: 7.887885083351078e-05
  • 15-sec: 7.894825880254046e-05
  • 30-sec: 7.896224557328974e-05

@aufdenkampe
Copy link
Member

@sjordan29 & @jrutyna, this is great news! Running the 3-day, 30-sec time step, course mesh in 1 min, 43 seconds will be perfect for development and testing of ClearWater-modules.

We can then run the fine mesh at different time-step resolutions to explore the scaling curves for speed and memory, while still keeping being able to do common-sense evaluations of the TSM and NSM outputs.

@sjordan29
Copy link
Contributor Author

@jrutyna, for the fine mesh, I'm seeing a larger percent volume error (-5.61%), so the mass error is pretty much leveling out at around that point as well.

@jrutyna
Copy link
Collaborator

jrutyna commented Apr 5, 2024

Are you able to start riverine a day into the HEC-RAS simulation? i.e. do not use the first day of the results from the hdf5 file. I think the hydraulic spin-up period may be creating this problem...

@jrutyna
Copy link
Collaborator

jrutyna commented Apr 5, 2024

If not, I can create a HEC-RAS simulation from a hot-start so you do not have to worry about that spin-up period.

@sjordan29
Copy link
Contributor Author

Got it. Yeah, I can do that.

@sjordan29
Copy link
Contributor Author

ok, started 12 hours in for the fine meshes and got the following results for the fine mesh -- the percent error in mass tracks pretty closely with the percent error in volume. And at 12 hours we hit <1% error for each.
image

These fine mesh models take longer to instantiate (reading data from HDF file) and run than the coarse mesh:

  • 30-sec: ~5 min
  • 15-sec: ~10 min
  • 10-sec: ~15 min
  • 5-sec: ~30 min

Guessing #61 could help with some of this.

anything else we should test before closing this issue?

@jrutyna
Copy link
Collaborator

jrutyna commented Apr 9, 2024

@sjordan29, did you compare the mass percent error from any of these simulations with its "answer" using concentrations of 100 mg/L everywhere?

@sjordan29
Copy link
Contributor Author

@jrutyna
Copy link
Collaborator

jrutyna commented Apr 9, 2024

It looks like the flow boundary for Cold Spring Creek has mass and volume exiting the domain. I expected zero to leave the domain for Cold Spring Creek just like the Upstream flow boundary and the Power Plant flow boundary. Let's talk tomorrow.

@jrutyna
Copy link
Collaborator

jrutyna commented Apr 10, 2024

For troubleshooting purposes, the cross-section I showed you in RAS Mapper that is one cell away from the edge of the domain, the North and South face IDs that cross Cold Spring Creek are 3899 and 3800, respectively. As we discussed and seen in RAS Mapper these faces all had positive flow into the domain (no flow reversals were noted). In addition, the face IDs at the edge of the domain where the flow boundary condition is located are 4093 and 3802 for the North and South faces, respectively.

@sjordan29
Copy link
Contributor Author

sjordan29 commented Apr 26, 2024

@jrutyna, I made some code updates to address #73, and now the model will identify where there are erroneous faces associated with a boundary and filter those out of the boundary_data information associated with a model instance. It will notify users that it has identified this issue, though this should be transferred to logs when we add address #28:
image

This boudary_data is what is used in the postproc_util module, so there was no need to make any updates in that file.

This produces the following results for a 30 second model:

image

I think the 30 sec output for the fine mesh violates the courant condition near the downstream end of the domain since the water is moving slightly more than 0.5 m/s and the cells in the channel are only 20 m^2. I will check the dye results in that area to see if they make sense.

@sjordan29
Copy link
Contributor Author

Still having trouble with interactive viz, but here's a gif with colors ranging from 99.5-100.5. Directly across from the cold creek you can see some wetting/drying. Otherwise, I don't see much down in the downstream. I can plot with a tighter range of colors, or @jrutyna you could try running this notebook (specifically the fine mesh tests) and see if the dynamic viz is working for you or run any other tests.

5_min_99_100

@sjordan29
Copy link
Contributor Author

A comparison for the fine mesh with code updates. Seems like 30 s should be a fine option:

image

@jrutyna - what do you think? Am I good to close this issue and issue a PR?

@jrutyna
Copy link
Collaborator

jrutyna commented May 3, 2024

Do you have a revised "comparison_df_pXY_updates.csv" file for each of these simulations that I can review? Or let me know which notebook I can created it from.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants