Open eguil opened 6 years ago
@eguil I agree with this sentiment, if we can modularize things more so functions are reusable that would be great - it would also aid multiprocessing/threading these functions
libDensityPospro.py created
We need to decide how to distinguish global variables from local. We could use:
Capitalised
global vs.lowercase
localg_<var>
for global@eguil how many regions do you want to define? I suggest we attempt to align as much with CF as we can http://cfconventions.org/Data/cf-standard-names/docs/standardized-region-names.html
no, not geographical regions ! -> names of python variables in the binDensity code
Ok got you, well what is the most important way to slice and dice variables in memory - having all the same quantities lining up together eg:
thetaoAtl
thetaoGlo
thetaoInd
thetaoPac
soAtl
...
Or the regional totals all lining up:
atlSo
atlThetao
gloSo
gloThetao
...
still not the issue ! Go and check the streamfunction branch created by Nicolas - you will see that he created variables in upper case (those that are coming from the libDensity.py). I find that upper case is really hard to read so we are looking for other ways of encoding this (first letter uppercase, g_,...)
@eguil which file am I looking at https://github.com/eguil/Density_bining/blob/streamFunction/libDensity.py?
@eguil ok got you https://github.com/eguil/Density_bining/compare/master...streamFunction
I also agree that it would be nice to make the code more intuitively readable, some of the variable declarations don't make immediate sense to me. We really should attempt to leverage the CMIP6 MIPvar names, but this will certainly come at a cost of length (e.g. thetao vs ptem)
binDensity.py
with more external modules stored in libDensity.py