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

Implement 'coastal realization' formulation #737

Open
PhilMiller opened this issue Feb 13, 2024 · 2 comments · May be fixed by #810
Open

Implement 'coastal realization' formulation #737

PhilMiller opened this issue Feb 13, 2024 · 2 comments · May be fixed by #810
Assignees

Comments

@PhilMiller
Copy link
Contributor

Per #547 (comment)

@PhilMiller PhilMiller self-assigned this Feb 23, 2024
@PhilMiller
Copy link
Contributor Author

Sketching out notes for how input variables will come from the forcings engine to feed into SCHISM:

SCHISM has three BMI grids that its inputs are defined over:

  1. Variables defined at every node in SCHISM's mesh
  2. Lateral flow defined at elements along the coastal boundary
  3. Water level defined at nodes along the open-water boundary

All of these are covered by bmi_grid_{size,x,y}, and if SCHISM is configured appropriately, it'll provide geographical coordinates in degrees of longitude and latitude for x and y.


The input variables defined on grid 1 at all nodes seem pretty straightforward to address with the forcings engine as I understand it:

  • Surface pressure SFCPRS
  • Temperature TMP2m
  • Wind velocity UU10m, VV10m
  • Specific humidity SPFH2m

One potential hitch I've seen suggested here is that the forcings data may not extend as far off-shore as the mesh. I think for a first cut, we can probably just use a nearest-neighbor value until we integrate a secondary source of data with broader/supplemental coverage.


Q_bnd (m^3 / s) is the lateral inflow in grid 2 coastal elements, that we'll have to carefully digest from t-route's output at downstream/coastal/terminal nexuses.


Precipitation averaged over specific elementsRAINRATE (kg / m^2 s), confusingly defined over the same grid 2 of elements along the on-shore coastal boundary. I've asked Jason about whether it should actually be over the whole domain instead.


Open boundary water level ETA2_bnd defined for grid 3 of nodes along the open-water boundary. This is coming from output of another simulation system. I'm not at all sure how we're getting this one yet. For an initial "get things running", we can probably pin this at a constant until we're prepared to wire that up.

@PhilMiller
Copy link
Contributor Author

From discussion with Jason

  • I'm going to recode RAINRATE to an element grid over the whole domain mesh
  • We talking about what happens to precipitation over land, and whether it should pass through an LSM like Noah or other catchment model code to partition water that does or doesn't become part of the coastal waterbody in a given step
  • For expedient simplicity, we'll defer any digestion of precipitation over land from Noah, and just force with RAINRATE uniformly for now.
  • Lake Champlain is a special case for the ETA2_bnd forcing, because it doesn't actually have an off-shore water level estimate like the Great Lakes or the oceans from circulation models (FVCOMM or STOFS). We think it may be fine without, since the SCHISM code handles an absence of files providing that variable.

PhilMiller added a commit to PhilMiller/NOAA-OWP-ngen that referenced this issue May 3, 2024
@PhilMiller PhilMiller linked a pull request May 3, 2024 that will close this issue
11 tasks
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.

1 participant