-
Notifications
You must be signed in to change notification settings - Fork 11
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
Conversation
…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
…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
…see how it goes...
Pausing to ponder for a second- the following two commits are really about a different problem.
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. |
spinning off branch for the exposed-config branch, see draft PR #227 |
as of 434dc3e, 4 out of the 9 cases in |
…tions at the cli. update test file cases for addressing no lat/lon case(s)
forwarding some good PR #205 feedback here and below... that PR getting too big though... |
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 |
from PR #205 feedback - regarding need to consider file-format preservation/specification |
from PR #205 feedback - regarding |
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 |
… 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.
next PR #237 will address above todo cases 4, 6, 7, 8, and 9. |
There was a problem hiding this 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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() ) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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!
cmor_lev = cmor.axis( "alternate_hybrid_sigma", | ||
coord_vals = lev[:], | ||
units = lev.units, | ||
cell_bounds = ds[vert_dim+"_bnds"] ) |
There was a problem hiding this comment.
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" ;
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fre/cmor/cmor_mixer.py
Outdated
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' |
There was a problem hiding this comment.
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.
this branches off of #205
gfdl-only specialty tests progress, the calls of which are seen in run_test_file_cases.py
nc_copy
bugnc_copy
bugcode QA:
This PR adds...
tmp
directory + filename handlingcmor_lev
no longer referenced before assignmentrewrite_netcdf_vars
run_test_file_cases.py
outside of the pytest framework to avoid making the repo explode in sizeREADME
accordingly