Development wish list

Table of ideas / wishes for future development (updated 5-9-2014)

Everyone can add Idea/Wish's. If you do so then mention your name under Contact. The ID's can be used as footnote linking to a more detailed description of the idea under the table. If you start implementing the idea, then put your name under Development together with a brief indication of the Status.

ID	Idea/Wish	Contact	Development	Status
1	Clean up RunTM5	Guillaume	-	-
2	Revise Rc management	Guillaume	-	-
3	Simplify the base tree	Guillaume	Sourish	-
4	PyShell Documentation	Guillaume	ALL	-
5	Simplify logging	Guillaume	-	-
6	Daily meteo I/O	Sourish	-	-
7	Fix adjoint phlb_t	Sourish	-	-
8	Time splitting	Sourish	-	-
9	Regional AKs	Sourish	-	-
10	Problem adjoint-zoom	Sourish	Sourish/Sander	-
11	3 hourly meteo	Sourish	-	-
12	Bias optimization	Arjo	-	-
13	'Roedenbeck scheme'	Arjo	-	-
14	Log normal pdf's	Arjo	-	-

1: Take out from the RunTM5 class what is not strictly needed to run TM5. It should just read the emission, observations and rcfile, and run TM5 with it (forward, backwards, in moon-walk …). The setup_emissions, setup_observations routines should be independent.
2: I really don't like that rcf is not independent from RunTM5. What I wanted is to be able to set some keys directly in my run-tm5.py script, since most of the time this is the file I am working with. I wanted these changes to be propagated. What I did is create a “rcdat” class, deriving from rcFile (originally, this was just because I didn't wanted to modify the base rc.py file). It has functionalities such as rc = rcdat(), rc.add(key,val), rc.substitute(key,val), rc.setkey(key,val), rc.readfile(filename). Possible addition: rc.repropagate ==> to re-propagate the changes if a “base” key is modified (it should be very easy to implement, but I never had the need for it). In the end, I had to so some changes to the rc.py, but it is still 100% backwards compatible. rc-files are used to store a limited number of default keys. Keys that are often modified by the user can be set at the very beginning of the python script. Complex sets of rc-keys (such as the ones used for the meteo, which are nearly impossible to read) can be generated directly from python. Overall, it allows using much smaller rc-files.
3: Take out any branches from the main branch.
4: Document each Python routine in the header section of the routine, including purpose, interface , method, last revision, etc.
5: There are different mechanisms for logging output, which end up in different places that are sometimes difficult to trace. At SARA, jobs that crash even seem to loose logging output.
6: Reading in meteo in daily chunks may speed up the code substantially.
7: The pressure levels (phlb_t) are not the same in the forward and adjoint model. This makes it difficult to use data that are defined at pressure levels.
8: Suggestion to implement the split window 4DVAR published in Chevallier et al (GMD, 2013) to improve the parallelisation of inversions spanning several years.
9: Extend VPP to calculate regional averaging Kernels (Note from Sander: In preconditioned space the averaging kernel is 1 - C_apos/C_apri, so it follows directly from the regional uncertainties that are already computed in VPP).
10: A bug creeped into the latest PyShell version, causing the adjoint test to fail when zoom regions are used.
11: Update the TM5 forward/adjoint to the reading of 3 hourly meteo.
12: Unify to approach for optimising bias correction factors. The process can be split into two parts 1) The treatment of added state vector elements (base) and 2) The application specific definition of bias correction functions (project).
13: Implement the scheme proposed by Trusilova et al (2010) to couple TM5 to a meso scale model.
14: Implement the use of log normal probability distributions.

[Sander Houweling]

wish list table