search

ESCOMP / CAM-SIMA

Community Atmosphere Model - System for Integrated Modeling of the Atmosphere
3 stars 12 forks source link

Remove support for python scripts in SourceMods? #176

Open gold2718 opened 2 years ago

gold2718 commented 2 years ago

In ESMCI/cime#4130, there was a discussion of removing support for python code in SourceMods. This seems like a good idea especially since I am finding it harder and harder to support the search and import process this requires.

Thoughts?

cacraigucar commented 2 years ago

Two comments:

gold2718 commented 2 years ago

Oops, I twiddled the digits. Fixed in the header.

cacraigucar commented 2 years ago

After reviewing the discussion, I do not think that it is important for us to try to support allowing python code to be placed in SourceMods.

nusbaume commented 2 years ago

I also agree that there should really not be a reason to include the python scripts in SourceMods, as theoretically there shouldn't be much "science" that is occurring in those scripts anyways, so if someone is modifying them then they are doing something beyond a simple science calculation or tuning experiment (which in my mind is what SourceMods was designed for).

That being said, I could see the benefit of allowing the replacement of various XML files (e.g. the registry) in SourceMods, so I would try to keep that functionality, if possible.

gold2718 commented 2 years ago

I could see the benefit of allowing the replacement of various XML files (e.g. the registry) in SourceMods ...

XML files do not have import issues so I do not see a problem with preserving this functionality. However, the CAMDEN build is getting complicated</understatement alert> and I am having trouble adding the new host model variables created from the namelist XML files to the initialization code (the generated code that checks the variable initialization status). Cleaning up the import methodology we use can help.

Speaking of that, do you know if all the fun and games with doctest and inspect in cam_autogen.py would still be needed if we could move all the import statements to the top of the module (except perhaps for doctest)?

nusbaume commented 2 years ago

Sadly I think so, as a lot of that code is just being used to determine the number of doctest failures to report back to the shell (which allows Github Actions to properly indicate a failed test). To be honest I think I am probably pushing the doctest framework beyond what is designed for in cam_autogen.py, and that much of these tests would be better suited as unittest tests, excluding possibly some small simple tests for some of the local functions that might be needed for complete code coverage.

Also, I should note that I am bringing in some additional modularization and clean-up (e.g. #152) along with the ParamGen changes that will hopefully help somewhat, although I agree that write_init_files.py is currently the biggest mess (hence any input for issue #145 would be helpful).