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

217 teaching fre cmor to bite #218

Merged
merged 16 commits into from
Nov 1, 2024
Merged

Conversation

ilaflott
Copy link
Member

@ilaflott ilaflott commented Oct 24, 2024

this branches off of #205

gfdl-only specialty tests progress, the calls of which are seen in run_test_file_cases.py

  • 1. land gr1 / Lmon / gr1
  • 2. atmos gr1 / Amon / cl (full vertical levels)
  • 3. atmos gr1 / Amon / mc (half vertical levels)
  • 4. atmos gr1 / Amon / ta
    • allow no-lon coordinate axis case
  • 5. ocean gr / Omon / sos
  • 6. ocean gn / Omon / sos
    • nc_copy bug
  • 7. ocean gr / Omon / so (three dimensional ocean)
    • nc_copy bug
  • 8. atmos gn / Amon / ch4global
    • allow no-lon coordinate axis case
    • allow no-lat coordinate axis case
  • 9. LUmip gr1 Emon / gppLut
    • come up with an edge-case work around for non-typical coordinate in place of a more typical vertical coordinate

code QA:

  • I ran my code
  • I tried to make my code readable
  • I tried to comment my code
  • I wrote a new test, if applicable
  • I wrote new instructions/documentation, if applicable
  • I ran pytest and inspected it's output
  • I ran pylint and attempted to implement some of it's feedback

This PR adds...

  • fix for tmp directory + filename handling
  • fix: cmor_lev no longer referenced before assignment
  • doc string for rewrite_netcdf_vars
  • a currently one-off gfdl-only testing script, run_test_file_cases.py outside of the pytest framework to avoid making the repo explode in size
  • updates the directory README accordingly
  • updates the click interface help menu read outs

…in new optional argument for additional control over file targeting. we also now have a \"run one file only\" style flag. new test config file fre/tests/test_files/CMORbite_var_list.json contains variables for processing test cases being workd through in run_test_file_cases.py with notes
@ilaflott ilaflott linked an issue Oct 24, 2024 that may be closed by this pull request
15 tasks
@ilaflott ilaflott self-assigned this Oct 24, 2024
@ilaflott ilaflott changed the title 217 the cmorbite one variable8 grids 217 teaching CMOR to bite Oct 24, 2024
@ilaflott ilaflott changed the title 217 teaching CMOR to bite 217 teaching fre cmor to bite Oct 24, 2024
@ilaflott ilaflott added bug Something isn't working documentation Improvements or additions to documentation enhancement New feature or request tricky Likely to encounter significant friction to solution priority: HIGH labels Oct 25, 2024
…e code currently relies on. unsure how useful the exact way i wrote things down is, but im hoping ot leverage it for structure and or setting up some formulaic approaches and or rules. additionally, merge multiline printstateaments into one call using legal but maybe awkward looking multiline syntax, some other readability edits too
@ilaflott
Copy link
Member Author

Pausing to ponder for a second- the following two commits are really about a different problem.

commit 31996b08b3c2ab3c5510a86606c01ef305383a55 (HEAD -> 217-the-cmorbite-one-variable8-grids, 
    fix undefined variable name errors

commit 4b313384a8c0cda3bb4eab2d398d99d3ada8a93c
    alrightly, lets move some of this hardcoding to the top of the file, see how it goes...

I could branch that development off here and revert the commits to make this less about exposing configuration and more about accommodating a wider array of input cases.

@ilaflott
Copy link
Member Author

spinning off branch fre-cmor-config-exposed at commit
31996b08b3c2ab3c5510a86606c01ef305383a55 from this PR. Then, this PR's branch will have the aforementioned commit, 4b313384a8c0cda3bb4eab2d398d99d3ada8a93c, and possibly parts of 62852833ecc7f42c3fbae1433fbaf341bba469cb reverted, as those edits are really attempting to do something worthwhile (making hard-coded dependencies more obvious) but not related to this PR's primary goal.

for the exposed-config branch, see draft PR #227

@ilaflott
Copy link
Member Author

as of 434dc3e, 4 out of the 9 cases in run_test_file_cases work outright. of the five failures, two are due to the lack of a lon/lat/both coordinates, two are actually associated with the copy_nc routine, and the last is associated with 4-dimensional land-use data where one has the typical horizontal coordinates, time, and NOT a z-coordinate

…tions at the cli. update test file cases for addressing no lat/lon case(s)
@ilaflott ilaflott mentioned this pull request Oct 29, 2024
7 tasks
@ilaflott
Copy link
Member Author

ilaflott commented Oct 29, 2024

forwarding some good PR #205 feedback here and below...

that PR getting too big though...

@ilaflott
Copy link
Member Author

from PR #205 feedback "do we really need to copy the input file before CMORizing?" - @ceblanton

i don't particularly think we need to, maybe batch related? --> perhaps batch configuration option... or check

@ilaflott
Copy link
Member Author

from PR #205 feedback - regarding copy_nc, "If the input file is NC3 will the output file be NC3 or NC4"

need to consider file-format preservation/specification

@ilaflott
Copy link
Member Author

from PR #205 feedback - regarding create_tmp_dir, the logic of this function should be clarified or revisited

@ilaflott
Copy link
Member Author

from PR #205 feedback

generally: we should be using a variable's "bounds" attributes to pull in assoc coordinate data. This came up discussing time axes, but might as well look at lat and lon or other coordinates similary.

… checks, trying to generally allow this code to be more flexible. not currently working atm
…ns. none checks, trying to generally allow this code to be more flexible. not currently working atm"

This reverts commit d80b790.
@ilaflott ilaflott mentioned this pull request Oct 31, 2024
18 tasks
@ilaflott
Copy link
Member Author

next PR #237 will address above todo cases 4, 6, 7, 8, and 9.

@ilaflott ilaflott marked this pull request as ready for review October 31, 2024 19:28
Copy link
Collaborator

@ceblanton ceblanton left a comment

Choose a reason for hiding this comment

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

Looks great, Ian. I didn't run it, but with your test cases I believe you, and we'll have plenty more opportunities in the future to run it.

I was slightly confused about the optional "local var" setting, mostly wondering why it's not required and normally set to the "target" variable name. But later on the "local var" IS required, so I think I just confused myself.

And then the question about whether the dimension bounds should be retrieved in a CF-friendly way, but regardless it's a fair assumption.

Aside from those two probable non-issues, all of the changes are clear improvements for functionality and clarity. Onward!

process only filenames matching that variable name.
I.e., this string help target local_vars, not
target_vars.
--help Show this message and exit.
Copy link
Collaborator

Choose a reason for hiding this comment

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

I can't ever really disagree with documentation, and don't disagree with this, but we'll have to keep this up-to-date with the actual --help output content which is defined elsewhere. Eventually, documentation like this will be auto-created through sphinx somehow.

Copy link
Member Author

@ilaflott ilaflott Nov 1, 2024

Choose a reason for hiding this comment

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

I've been pondering this too. hear me out for a second- I know that the way (edit) we generate i generated coverage badges in our pipeline is a bit hacky- utilizing the deployed github pages to host the generated image at a static URL for linking to the README.

But... there DO exist workflows that edit the coverage badge in the repo directly and makes the commit itself- i tried to make those work but couldn't figure it out on a reasonable timeline.

Why do i bring this up? Well, in theory if a workflow could commit to the repo for a generated test-coverage badge, it should also be able to commit a quick README edit based on the latest fre <tool> --help or fre <tool> <subtool> --help. That's tech debt worth noting down for future payment.

fre/cmor/cmor_mixer.py Show resolved Hide resolved
print('(cmorize_target_var_files) NOT using /local /work /net (tmp_dir = outdir/tmp/ )')
tmp_dir = f"{outdir}/tmp/"
print(f'(create_tmp_dir) NOT using /local /work /net (tmp_dir = {outdir}/tmp/ )')
tmp_dir = str( Path(f"{outdir}/tmp/").resolve() )
Copy link
Collaborator

Choose a reason for hiding this comment

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

we agreed to revisit this tmpdir and if it's needed at all. It seems odd to combine the string and path type conversion in one line but I've had to do it too.

Copy link
Member Author

Choose a reason for hiding this comment

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

see #240 ! but perhaps we should discuss the best way to use/handle pathlib.Path in our codebase... lest we get too deep in the hole!

fre/cmor/cmor_mixer.py Show resolved Hide resolved
cmor_lev = cmor.axis( "alternate_hybrid_sigma",
coord_vals = lev[:],
units = lev.units,
cell_bounds = ds[vert_dim+"_bnds"] )
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is this line creating the cell bounds from scratch or do they have to be in the input file?

If it's creating it from thin air, then this should be fine. But if it has to be in the input file, then perhaps it is named something different, but is probably vert_dim+'_bnds'. The CF way to find it would be similar to the dimension axis:

double lev(lev) ;
	lev:units = "1.0" ;
	lev:long_name = "hybrid sigma pressure coordinate" ;
	lev:axis = "Z" ;
	lev:positive = "down" ;
	lev:formula = "p(n,k,j,i) = ap(k) + b(k)*ps(n,j,i)" ;
	lev:formula_terms = "ap: ap b: b ps: ps" ;
	lev:bounds = "lev_bnds" ;
	lev:standard_name = "atmosphere_hybrid_sigma_pressure_coordinate" ;

Copy link
Member Author

Choose a reason for hiding this comment

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

ds is grabbed as a netCDF4.Dataset from the targeted files in the input directory, so ds[vert_dim+'_bnds'] demands a value pointed to by key vert_dim + '_bnds' exists in ds.

Copy link
Member Author

Choose a reason for hiding this comment

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

@ilaflott ilaflott merged commit 16af470 into main Nov 1, 2024
2 checks passed
@ilaflott ilaflott deleted the 217-the-cmorbite-one-variable8-grids branch November 1, 2024 16:42
INPUT_SUBCASE2_1_ZFACT_BNDS = ['ap_bnds','b_bnds']
#-
OUTPUT_SUBCASE2_0_ZFACT_VAL_NAMES = ['ap','b']
OUTPUT_SUBCASE2_0_VERT_LVL_NAME = 'altername_hybrid_sigma'
Copy link
Collaborator

Choose a reason for hiding this comment

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

Completely agree with this approach. It's far better than hard-coding in actual code but retains flexibility and transparency.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working documentation Improvements or additions to documentation enhancement New feature or request priority: HIGH tricky Likely to encounter significant friction to solution
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CMORbite: success across different variables and tables
2 participants