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

Add forcing height variable to GSWP3 forcing files #1760

Open
olyson opened this issue May 18, 2022 · 4 comments
Open

Add forcing height variable to GSWP3 forcing files #1760

olyson opened this issue May 18, 2022 · 4 comments
Assignees

Comments

@olyson
Copy link
Contributor

olyson commented May 18, 2022

We want to add a forcing height variable to the GSWP3 forcing files and stream text file (and probably eventually to other forcing datasets as well) so that it is read in from the forcing files instead of being hardcoded in the datm code (currently set to 30m). This variable would still be time- and space-invariant. The main reason is to make this variable more visible to users. This would also be consistent with our flux tower forcing files where forcing height is encoded as ZBOT in the datm forcing files.

@olyson olyson added the next this should get some attention in the next week or two. Normally each Thursday SE meeting. label May 18, 2022
@olyson olyson self-assigned this May 18, 2022
@ekluzek
Copy link
Collaborator

ekluzek commented May 18, 2022

This work will need to be done in CDEPS. The CTSM part of this will be to update to the CDEPS tag where this is done. I think the way to do this will be to add an additional file for ZBOT, that will be handled as an additional stream file. The file will only have a single time-sample and one latitude and longitude, but it would be a separate stream.

@billsacks billsacks removed the next this should get some attention in the next week or two. Normally each Thursday SE meeting. label May 19, 2022
@ekluzek
Copy link
Collaborator

ekluzek commented Jun 3, 2022

I have a branch and PR in CDEPS that fixes the read for ZBOT

ESCOMP/CDEPS#169

@wwieder
Copy link
Contributor

wwieder commented Jun 8, 2022

Just clarifying, this will also fix the bug with reading in ZBOT from DATM files for single point runs (adding next so we can discuss).

@wwieder wwieder added the next this should get some attention in the next week or two. Normally each Thursday SE meeting. label Jun 8, 2022
@ekluzek
Copy link
Collaborator

ekluzek commented Jun 8, 2022

@wwieder the CDEPS PR above fixes the bug for reading ZBOT for single point runs. Using that branch will fix that for you. I've just pinged Jim to approve the PR so we'll have a CDEPS tag for it.

@billsacks billsacks removed the next this should get some attention in the next week or two. Normally each Thursday SE meeting. label Jun 23, 2022
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

No branches or pull requests

4 participants