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

New docn features and update to documentation #213

Merged
merged 11 commits into from
Feb 1, 2023

Conversation

mvertens
Copy link
Collaborator

@mvertens mvertens commented Jan 30, 2023

Description of changes

New docn features

Specific notes

This PR adds two new features to docn:

  • New Feature 1: A new cplhist mode that will enable DOCN to read coupler history data needed to drive WW3DEV. As a result - development of WW3DEV can be done in isolation and without the need for an active ocean. The new ocean model is $DOCN%CPLHIST and the following new xml variables are introduced (along with their default values).
	DOCN_CPLHIST_YR_ALIGN: 1
	DOCN_CPLHIST_YR_END: 1
	DOCN_CPLHIST_YR_START: 1

For now the user will have to set the following variables in user_nl_docn_streams:

	cplhist:taxmode=extend
	cplhist:dtlimit=1.e30
	cplhist:datafiles= <fill this in>
  • New Feature 2: The ability for DOCN to advertise import fields. This is needed by MOM6 developers where as an example aerosol forcing data on the ocean grid is needed to be written out the the coupler history file.
    The new xml variable is DOCN_IMPORT_FIELDS
    If DOCN_IMPORT_FIELDS=none, then no ocean import fields will be advertised by the ocean and therefore written out in the mediator history file
    If DOCN_IMPORT_FIELDS= Faxa_bcph:Faxa_dstdry:Faxa_dstwet:So_duu10n:Si_ifrac then these fields will be written out to the mediator history file.

Contributors other than yourself, if any: @jedwards4b @mnlevy1981

CDEPS Issues Fixed (include github issue): None

Are there dependencies on other component PRs (if so list): Yes. This PR needs to be accompanied by an associated CMEPS PR (TBD) and resolves the CMEPS issue ESCOMP/CMEPS#340

Are changes expected to change answers (bfb, different to roundoff, more substantial): bfb

Any User Interface Changes (namelist or namelist defaults changes): Yes -see new xml variable above
Testing performed (e.g. aux_cdeps, CESM prealpha, etc):

  • Verified that changes were bfb when Feature 1 and Feature 2 changes were not invoked.
  • Verified that SMS_Ld5.f09_g17.B1850G.cheyenne_intel.allactive-cism-test_coupling and ERP_Ln9_Vnuopc.ne30_ne30_mg17.F2000climo.cheyenne_intel.cam-outfrq9s were bfb compared to cesm2_3_beta11

Hashes used for testing: cesm2_3_beta11

@mvertens mvertens marked this pull request as draft January 30, 2023 15:39
@@ -1,9 +1,11 @@
project(docn Fortran)
set(SRCFILES ocn_comp_nuopc.F90
docn_datamode_copyall_mod.F90
docn_datamode_copyall_mod.F90
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

align these?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything is now re-aligned under SRCFILES.

@@ -44,7 +45,7 @@

<entry id="DOCN_MODE">
<type>char</type>
<valid_values>prescribed,sst_aquap1,sst_aquap2,sst_aquap3,sst_aquap4,sst_aquap5,sst_aquap6,sst_aquap7,sst_aquap8,sst_aquap9,sst_aquap10,sst_aquapfile,som,som_aquap,sst_aquap_constant,interannual,null</valid_values>
<valid_values>prescribed,sst_aquap1,sst_aquap2,sst_aquap3,sst_aquap4,sst_aquap5,sst_aquap6,sst_aquap7,sst_aquap8,sst_aquap9,sst_aquap10,sst_aquapfile,som,som_aquap,sst_aquap_constant,interannual,cplhist</valid_values>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is null no longer a valid option?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You never needed null - and it made no sense to have it there. So it is no longer a valid option.

@mvertens mvertens marked this pull request as ready for review January 31, 2023 12:07
Copy link
Contributor

@mnlevy1981 mnlevy1981 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to run this with the additional fields Foxx_taux and Foxx_tauy being written out, but got an error. I'm testing now with the original variable list -- is it reasonable to expect docn to be able to write out the two components of tau, or would that come from a different component? I think MOM and POP can both receive the above field, though it's entirely possible I mistyped the variable names in my xmlchange command.

@mnlevy1981
Copy link
Contributor

I tried to run this with the additional fields Foxx_taux and Foxx_tauy being written out, but got an error. I'm testing now with the original variable list -- is it reasonable to expect docn to be able to write out the two components of tau, or would that come from a different component? I think MOM and POP can both receive the above field, though it's entirely possible I mistyped the variable names in my xmlchange command.

My sandbox was incomplete -- I forgot to update CMEPS to the branch in ESCOMP/CMEPS#341 so I'm rebuilding and testing again. Sorry, the caffeine hasn't kicked in yet.

Copy link
Contributor

@mnlevy1981 mnlevy1981 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I updated my sandbox correctly, I was able to run (and write the additional tau fields in the history files). I really like the introduction of DOCN_IMPORT_FIELDS, it makes it really easy to modify what fields we want output!

Copy link
Collaborator

@uturuncoglu uturuncoglu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this also requires update in the documentation. If you don't mind could you include information about these new docn modes to the Section 5 (https://escomp.github.io/CDEPS/versions/master/html/docn.html). I think we don't need to test UFS for this PR since it does not touching exiting ones. Do you agree with me? If you want I could test it.

@mvertens
Copy link
Collaborator Author

mvertens commented Feb 1, 2023

@uturuncoglu - I agree about not having to test with the UFS. How do I update the web pages for the documentation. Once the PR is merged - does it automatically update the web pages? Can we please chat today?

@mvertens
Copy link
Collaborator Author

mvertens commented Feb 1, 2023

@uturuncoglu @jedwards4b - I have updated the CDEPS documentation quite a bit. I have added new documentation for this PR as well as documenting the env_run.xml variables for each data component that appear in env_run.xml.
I think this PR is ready to be merged.

@mvertens mvertens changed the title New docn features New docn features and update to documentation Feb 1, 2023
@uturuncoglu
Copy link
Collaborator

@mvertens once the doc sources ready. we need to compile it and push to gh-pages with another PR. Then you could see the update in the pages.

@jedwards4b
Copy link
Contributor

THis may be a good opportunity to add the stuff that Ufuk recently wrote up as well.

@uturuncoglu
Copy link
Collaborator

@jedwards4b agree. once this PR in. Maybe I could push those as a part of this PR. What do you think? Of course after ESMF meeting today.

@jedwards4b jedwards4b merged commit ca57286 into main Feb 1, 2023
@mvertens
Copy link
Collaborator Author

mvertens commented Feb 2, 2023

@uturuncoglu - how do you do a PR to gh-pages?

@mvertens mvertens deleted the feature/cplhist_and_ocnimport branch February 2, 2023 14:33
@jedwards4b
Copy link
Contributor

When you open the PR - you direct it to the gh-pages branch of the repo instead of main.

@mvertens
Copy link
Collaborator Author

mvertens commented Feb 2, 2023

@jedwards4b- in looking at the gh-pages branch it looks like this is just the output from running make html in the doc directory. This seems really awkward if this is indeed what we are doing. Do you agree?
@uturuncoglu - what exactly do you do in terms of the workflow for the PR?

@uturuncoglu
Copy link
Collaborator

@mvertens you need to checkout gh-pages branch. Create your branch from it such as updatedoc. Then, copy your compiled doc (the directory that has doctrees and html) under master directory. Then commit your changes. then you could create PR to gh-pages.

@mvertens
Copy link
Collaborator Author

mvertens commented Feb 2, 2023

@uturuncoglu - thanks.

@uturuncoglu
Copy link
Collaborator

@mvertens @jedwards4b i am planing to add NUOPC cap documentation that I wrote for the UFS technical documentation. As a part of this, I need to compile the documentation and also need to create PR for CDEPS gh-pages. So, this will also include documentation that is added as a part of this PR. @mvertens do you want me to go and do that. So, there is no to have two PR to gh-pages (one for doc that is a part of this PR and other for NUOPC cap doc.)

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.

4 participants