Adding mods to derive PRECT

[bstephens82]

from PRECC+PRECL if PRECT is not in the cam.h0 files. This code could be extended to other variables.

[brianpm]

Just to note that #240 is a similar modification to allow RESTOM to be derived. The implementation there is quite different. I'd recommend we encourage doing these kinds of simple derivations in a consistent manner. I like @bstephens82 's approach of just having a derive_variable method. I'm not sure how I feel about doing the derivation with ncap2, but I'm open to it if others think this is better than using python tools.

[bstephens82]

Just to note that #240 is a similar modification to allow RESTOM to be derived. The implementation there is quite different. I'd recommend we encourage doing these kinds of simple derivations in a consistent manner. I like @bstephens82 's approach of just having a derive_variable method. I'm not sure how I feel about doing the derivation with ncap2, but I'm open to it if others think this is better than using python tools.

Ah, I had heard RESTOM might be another variable this could be applied to, but didn't realize it had already been implemented. I figured for each variable that could be derived, we would need to add another "recipe" in derive_variable. In the case of PRECT using ncap2 was just one of the shortest routes I could come up with. Feel free to modify or suggest other methods. Is the idea to avoid using NCO operators where possible?

[brianpm]

Yeah, I think adding "recipes" for each variable is the right way to go.

We do use NCO to make time series files, but we have discussed that having NCO as a dependency might not be great for portability. I'm not opposed to using it in the short term, but we might need to revisit in the future.

I guess my point was mostly to note that we should somehow combine this PR and #240 to allow both PRECT and RESTOM to be generated when the requirements are met.

[brianpm]

I also notice that #232 mentions similar functionality, so should also be harmonized with this one and #240.

[justin-richling]

Also I believe this is mentioned (PRECT specifically) in Julie's issue #228, so hopefully this can close that issue out as well

[nusbaume]

Thanks for working on this @bstephens82! It looks good, but I do have a few changes requests, mostly to avoid possible errors showing up if certain variables aren't present.

[nusbaume]

I think this is totally fine for now, but long-term I wonder if we can figure out a way to add the derivation equations to the variable defaults YAML file itself, and then simply have this function properly parse those equations to produce the derived variable. That way future users won't have to modify the core ADF python code if they want to add a new derived variable.

Thoughts? @brianpm @justin-richling

[bstephens82]

I like that idea...I am not sure how to implement it though.

[nusbaume]

Almost there! Just a little bit of extra clean-up on your new file-checking code.

[nusbaume]

Super-close, just one last question.

[nusbaume]

Looks good to me now, thanks! Once @justin-richling also reviews and approves it then it will be ready to be merged.

[justin-richling]

This looks good on my end, thanks @bstephens82! This will help get us in the right direction for more derived quantities in the future.