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

Physics tendency updaters #163

Merged
merged 19 commits into from
Nov 1, 2021
Merged

Physics tendency updaters #163

merged 19 commits into from
Nov 1, 2021

Conversation

peverwhee
Copy link
Collaborator

@peverwhee peverwhee commented Oct 20, 2021

Updating Externals_CAM and host model to support physics tendency updaters.

Tested with Held-Suarez and no significant differences found using ncdata_check (had to remove qneg from the suite_held_suarez_1994.xml temporarily for testing - qneg updates will come into CAMDEN with future PR).

Addresses #156

@peverwhee peverwhee changed the title Updaters Physics tendency updaters Oct 20, 2021
Copy link
Collaborator

@gold2718 gold2718 left a comment

Choose a reason for hiding this comment

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

Questions and suggestions

@@ -433,7 +434,7 @@ def __init__(self, elem_node, parent_name, dimensions, known_types,
', '.join(dimensions)))
# end if
local_name = '{}({})'.format(parent_name, self.index_string)
super(ArrayElement, self).__init__(elem_node, local_name, my_dimensions,
VarBase.__init__(self, elem_node, local_name, my_dimensions,
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm not super happy with explicitly calling out the class hierarchy. Not that I have a plan to change this one but changing it is more difficult if we put explicit names in derived classes. Is there a good reason to not use super (here and below)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I was getting errors using super - I think related to a python version change.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Right. I think this is probably due to taking out the (object) inheritance in the classes.
Since we do not use multiple inheritance, you should be able to just use super() in place of VarBase.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

To get that to work, I think I have to change class VarBase to class VarBase(object). Does that seem right?

Comment on lines 30 to 31
private :: active_file_ptr

Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm not sure what is going on here but this might be a regression. I think the 'base' version is a fix that @nusbaume put in recently.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

good call - reverted.

@peverwhee
Copy link
Collaborator Author

@gold2718 @nusbaume Any ideas on how to fix the failing unit tests? It looks like it can't find framework_env.py...?

Copy link
Collaborator

@gold2718 gold2718 left a comment

Choose a reason for hiding this comment

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

See comment

@@ -433,7 +434,7 @@ def __init__(self, elem_node, parent_name, dimensions, known_types,
', '.join(dimensions)))
# end if
local_name = '{}({})'.format(parent_name, self.index_string)
super(ArrayElement, self).__init__(elem_node, local_name, my_dimensions,
VarBase.__init__(self, elem_node, local_name, my_dimensions,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Right. I think this is probably due to taking out the (object) inheritance in the classes.
Since we do not use multiple inheritance, you should be able to just use super() in place of VarBase.

@nusbaume
Copy link
Collaborator

nusbaume commented Oct 21, 2021

Hi @peverwhee, it looks like framework_env.py doesn't exist anywhere in your CAMDEN branch (including the externals). My guess is that the ccpp-framework external in Externals_CAM.cfg needs updated. Do you know if you updated it at all in your test version, or if you copied in CCPP framework code from somewhere else?

@gold2718
Copy link
Collaborator

My guess is that the ccpp-framework external in Externals_CAM.cfg needs updated. Do you know if you updated it at all in your test version, or if you copied in CCPP framework code from somewhere else?

Good catch. It looks like you have CPF_0.2.026, I would try updating it to CPF_0.2.029

@nusbaume
Copy link
Collaborator

Hi @peverwhee

Just an FYI that to get these unit tests to pass, it looks like you'll need to modify the calls to metadata_file_to_files in test_registry.py so that instead of reading in logging.getLogger("badmf") it uses a CCPPFrameworkEnv object. I believe after this is fixed the unit tests will finally pass, at which point I'll make sure to get through my code review.

Thanks!

@peverwhee
Copy link
Collaborator Author

Hi @peverwhee

Just an FYI that to get these unit tests to pass, it looks like you'll need to modify the calls to metadata_file_to_files in test_registry.py so that instead of reading in logging.getLogger("badmf") it uses a CCPPFrameworkEnv object. I believe after this is fixed the unit tests will finally pass, at which point I'll make sure to get through my code review.

Thanks!

Thank you, @nusbaume! I was doing some major flailing.

Copy link
Collaborator

@nusbaume nusbaume left a comment

Choose a reason for hiding this comment

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

Looks good, but I do have some questions, and one important request (the phys_timestep_init_zero suggestion).

@@ -28,7 +28,7 @@ from CIME.buildlib import parse_input
from CIME.build import get_standard_makefile_args
#pylint: enable=wrong-import-position

check_minimum_python_version(2, 7)
check_minimum_python_version(3, 7)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Did you test this on Izumi? I know that with our older version of CIME the "default" system version of python is sometimes used (which is python 2.7 on Izumi), but that may only be for the run phase.

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're right - it doesn't work. Not sure how we got it to work before, but right now I'm getting this error during the build stage (despite explicitly loading 3.7.0):

ERROR: Python 3, minor version 7 is required, you have 3.6

@gold2718 any ideas?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Hmm. It seems that the Izumi entry in CIME (<root>/cime/config/cesm/machines/config_machines.xml) is really out of date. It has some python path information that does not exist on Izumi and does not load the python module. Try adding a module load command in the <modules> section of Izumi's entry and see if that helps. If so, open an issue on ESMCI/cime and we can update the entry.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

That seems to have fixed the issue! Thank you! In regards to the cime issue, I assume we want to add the module load command for all of the available compilers?

Copy link
Collaborator

Choose a reason for hiding this comment

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

No, just adding it to the <modules> section as a new line after the module purge should do it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ahhh that makes sense. Issue created: ESMCI/cime#4116

@@ -32,6 +33,8 @@ sys.path.append(_CIME_CONFIG_PATH)
# Import CAM's configure structure:
from cam_config import ConfigCAM

check_minimum_python_version(3, 7)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Does this work on Izumi with our older version of CIME (i.e. can you successfully run case.submit)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

No. Updated cime version and removed this check, and now it runs.

src/data/generate_registry_data.py Show resolved Hide resolved
src/data/registry.xml Show resolved Hide resolved
@@ -1 +1 @@
<CAMBuildCache>TAG1<registry><generate_init_file file_path="$TEST_SOURCE_MODS_DIR/simple_reg.xml" hash="05510a45b99aa9449bb44684362465bf2dacbc6c" />TAG2<generate_registry_file file_path="$TEST_SOURCE_MODS_DIR/simple_reg.xml" hash="05510a45b99aa9449bb44684362465bf2dacbc6c" /><registry_file file_path="$TEST_SOURCE_MODS_DIR/simple_reg.xml" hash="05510a45b99aa9449bb44684362465bf2dacbc6c" /><dycore>none</dycore><config /></registry><CCPP><SDF file_path="$TEST_SOURCE_MODS_DIR/simple_suite.xml" hash="1d90bde78b8740d08cb530748a3ddb346497bf1a" /><scheme file_path="$TEST_SOURCE_MODS_DIR/temp_adjust_scalar.meta" hash="ce34cd13aade63ee06cd82b75170f3c2f6ac1bd5" />TAG3<preproc_defs>UNSET</preproc_defs><kind_phys>REAL64</kind_phys></CCPP></CAMBuildCache>
<CAMBuildCache>TAG1<registry><generate_init_file file_path="$TEST_SOURCE_MODS_DIR/simple_reg.xml" hash="05510a45b99aa9449bb44684362465bf2dacbc6c" />TAG2<generate_registry_file file_path="$TEST_SOURCE_MODS_DIR/simple_reg.xml" hash="05510a45b99aa9449bb44684362465bf2dacbc6c" /><registry_file file_path="$TEST_SOURCE_MODS_DIR/simple_reg.xml" hash="05510a45b99aa9449bb44684362465bf2dacbc6c" /><dycore>none</dycore><config /></registry><CCPP><SDF file_path="$TEST_SOURCE_MODS_DIR/simple_suite.xml" hash="1d90bde78b8740d08cb530748a3ddb346497bf1a" /><scheme file_path="$TEST_SOURCE_MODS_DIR/temp_adjust_scalar.meta" hash="ca48290fa714873cb0e6cf04968c65d508d6f5dd" />TAG3<preproc_defs>UNSET</preproc_defs><kind_phys>REAL64</kind_phys></CCPP></CAMBuildCache>
Copy link
Collaborator

Choose a reason for hiding this comment

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

Not relevant for this particular PR, but should we pretty print the cache XML file? I realize that a user should never have to look in this file, but I have also had that same thought with a lot of files before and been wrong most of the time.

Any opinions @gold2718 @peverwhee ?

Copy link
Collaborator

Choose a reason for hiding this comment

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

There is a pretty printer class in the CCPP Framework (PrettyElementTree) that you could use (or did I reinvent a wheel here?).
It is probably not in the best place right now (ccpp_datafile.py), I can move it to parse_tools.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

pretty printed cache XML file

@peverwhee peverwhee requested a review from gold2718 October 29, 2021 20:30
@peverwhee peverwhee requested a review from nusbaume October 29, 2021 20:31
Copy link
Collaborator

@gold2718 gold2718 left a comment

Choose a reason for hiding this comment

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

Couple of minor tweaks but then I'm okay to merge.

@@ -19,6 +19,7 @@ sys.path.append(_LIBDIR)
from standard_script_setup import *
from CIME.XML.standard_module_setup import *
from CIME.buildnml import create_namelist_infile, parse_input
from CIME.utils import check_minimum_python_version
Copy link
Collaborator

Choose a reason for hiding this comment

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

I guess we do not really need this now.

Comment on lines 1444 to 1445
meta_tables = parse_metadata_file(file_path, known_ddts, run_env)
# end if
Copy link
Collaborator

Choose a reason for hiding this comment

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

To avoid confusion, these need to be swapped:

Suggested change
meta_tables = parse_metadata_file(file_path, known_ddts, run_env)
# end if
# end if
meta_tables = parse_metadata_file(file_path, known_ddts, run_env)

@@ -1532,6 +1535,10 @@ def write_registry_files(registry, dycore, config, outdir, src_mod, src_root,
"""
files = []
known_types = TypeRegistry()
logger.debug('hi')
Copy link
Collaborator

Choose a reason for hiding this comment

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

Uhhh, not sure what is going on here. If we need this line, I think the correct syntax is logger.debug('hi mom') ;)

Copy link
Collaborator

@nusbaume nusbaume left a comment

Choose a reason for hiding this comment

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

Looks good to me! Just one question related to the addressed issue (which is probably more for @gold2718 anyways).

@@ -28,7 +28,7 @@ from CIME.buildlib import parse_input
from CIME.build import get_standard_makefile_args
#pylint: enable=wrong-import-position

check_minimum_python_version(2, 7)
check_minimum_python_version(3, 6)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Does this mean that for issue #156 we should have the restriction be for a 3.6 minimum (instead of 3.7)?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Does this mean that for issue #156 we should have the restriction be for a 3.6 minimum (instead of 3.7)?

I think so, let's settle this over there (where I have been commenting).

@peverwhee peverwhee merged commit bcef915 into ESCOMP:development Nov 1, 2021
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.

3 participants