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

Updates for component land model #98

Merged
merged 500 commits into from
Jan 26, 2024

Conversation

uturuncoglu
Copy link
Collaborator

Description of changes

This PR aims to bring fully coupled atmosphere-land component configuration to UFS Weather Model and updates CMEPS.

Specific notes

Contributors other than yourself, if any: N/A

CMEPS Issues Fixed (include github issue #): N/A

Are changes expected to change answers? (specify if bfb, different at roundoff, more substantial)
N/A

Any User Interface Changes (namelist or namelist defaults changes)? N/A

Testing performed

Please describe the tests along with the target model and machine(s)
If possible, please also added hashes that were used in the testing
The full RT test suite is run on Orion using ESMF 8.3.0b09 (current version used under UFS)
The full RT test suite will be run using ESMF 8.5.0, which is required for NoahMP component version

add werror to extbuild
### Description of changes
Add werror to github testing - no gfortran warnings allowed.

### Specific notes

Contributors other than yourself, if any:

CMEPS Issues Fixed (include github issue #):

Are changes expected to change answers? (specify if bfb, different at roundoff, more substantial) 
BFB
Any User Interface Changes (namelist or namelist defaults changes)? NO

### Testing performed

Testing performed if application target is CESM:
- [ ] (recommended) CIME_DRIVER=nuopc scripts_regression_tests.py
   - machines:
   - details (e.g. failed tests):
- [ ] (recommended) CESM testlist_drv.xml
   - machines and compilers:
   - details (e.g. failed tests):
- [X] (optional) CESM prealpha test
   - machines and compilers   cheyenne, intel, gnu, github testing.
   - details (e.g. failed tests):
- [ ] (other) please described in detail
   - machines and compilers
   - details (e.g. failed tests):

Testing performed if application target is UFS-coupled:
- [ ] (recommended) UFS-coupled testing
   - description:
   - details (e.g. failed tests):

Testing performed if application target is UFS-HAFS:
- [ ] (recommended) UFS-HAFS testing
   - description:
   - details (e.g. failed tests):

### Hashes used for testing:

- [X] CESM:
  - repository to check out: https://github.com/ESCOMP/CESM.git
  - branch/hash: cesm2_3_beta11
- [ ] UFS-coupled, then umbrella repostiory to check out and associated hash:
  - repository to check out:
  - branch/hash:
- [ ] UFS-HAFS, then umbrella repostiory to check out and associated hash:
  - repository to check out:
  - branch/hash:
@DeniseWorthen
Copy link
Collaborator

DeniseWorthen commented Oct 13, 2023

@uturuncoglu I'm having an issue w/ the land configurations, but not directly related to this PR.

I'm working on ufs-community/ufs-weather-model/issues/1800 but I'm getting unallocated arrays for the sbs land component. I think this is because the instantaneous coupling fields I want to use (instead of the mean fields) are outside of a cpllnd flag in GFS_typedefs.F90. So, for example,

https://github.com/NOAA-EMC/fv3atm/blob/a13a239a746cb95c74bbe5841f300cb75f8b80d9/ccpp/data/GFS_typedefs.F90#L2869-L2871

The fields I need instead are, for example, dlwsfci_cpl and dswsfci_cpl. As I've noted in the ufs issue, the mean and inst fields available in FV3atm are not b4b, but generally differ by ~O-12 or less.

I think what I needs is for all the inst fields which are currently under the only the cplflx flag but which are used by the lnd sbs need to be moved to the the cplfx=.true. or cpllnd=.true. block. Does this seem right?

Also, I noted that all the net SW bands are being allocated when cplfx=.true. or cpllnd=.true.. These don't seem to be used in either of those two configurations. Are they really required?

@uturuncoglu
Copy link
Collaborator Author

@DeniseWorthen I agree with you. If there is a filed that needs to be used by land then you could move them under cplfx=.true. or cpllnd=.true. statment. I think this will not affect anything in terms of land coupling. The shortwave bands are not used by the land component. We are just getting net or downward (then calculating net internally) based on the configuration. Let me know if you need help about testing.

@DeniseWorthen
Copy link
Collaborator

@uturuncoglu Thanks. These are the banded sw fields currently in the cpllnd/cplflx block

      allocate (Coupling%nnirbmi_cpl (IM))
      allocate (Coupling%nnirdfi_cpl (IM))
      allocate (Coupling%nvisbmi_cpl (IM))
      allocate (Coupling%nvisdfi_cpl (IM))
      allocate (Coupling%nnirbm_cpl  (IM))
      allocate (Coupling%nnirdf_cpl  (IM))
      allocate (Coupling%nvisbm_cpl  (IM))
      allocate (Coupling%nvisdf_cpl  (IM))

None of those are actually used by LND (either SBS or component)?

@uturuncoglu
Copy link
Collaborator Author

@DeniseWorthen I am sure they are not used by the land component but maybe FV3 needs them. Maybe I got error in the initial implementation and decided to put it under also land. It is hard to memorize. If you remove them and land sbs runs, then there is no any issue.

@uturuncoglu
Copy link
Collaborator Author

@DeniseWorthen BTW, if you look at CMEPs wiring for land component, there is no any field like sw bands.

@DeniseWorthen
Copy link
Collaborator

DeniseWorthen commented Oct 13, 2023

@uturuncoglu Thanks. I suspect they need to be under cplflx, but I agree I don't see any reason for them to be in the cpllnd block.

I know from the CMEPS side that the banded sw down components are used, but the ones in that block are the net sw bands. I will do some testing.

edit: banded down is used only for the DATM configuration

@jkbk2004
Copy link

Please, go ahead to merge this pr. All tests were done at weather model side.

@DeniseWorthen DeniseWorthen merged commit 13ed059 into NOAA-EMC:emc/develop Jan 26, 2024
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 this pull request may close these issues.