jhan_JaCAux_Dec2019_Richard

There certainly are a few balls in the air at the moment. Two important ones for this conversation are:

1. Martin’s work to separate the land, sea points etc is reasonably advanced but has stalled due to him grappling with a change in answers. My money is on the compiler enjoying the new-found tidiness triggering bit-level changes but Martin needs to prove it

2. There is increasing pressure from other JULES stakeholders to make some significant changes to facilitate their needs. This will likely require a closed release cycle to get through the work, and we are currently looking at the Mar-May development window. Announcements consulting on this have gone out through the JULES channels. Possible impacts include:

• Removal of USE statements from the science code such that all fields (variables on land_pts etc) are passed by argument
• The bundling of these fields into TYPEs to keep argument list sizes down
• Various changes in/around memory initialisation
• Clean up of the UM interface

Branches will likely struggle to merge cleanly across this release

Therefore we need to think about how we wrap the CABLE integration into the timeline to avoid project conflict

I feel as though pushing really hard to get the ‘fully functioning’ work in for the next release would be very helpful for keeping clear of the closed release.

There is a dependency on Martin’s land/sea separation work and the ‘fully functioning’ work. Getting both through the system in time is looking challenging.

Danny’s present ticket will hopefully be with me for sci/tech next week. I think we’ve already dealt with the major bits. I’ll try to get it through quickly and lean on the code reviewer to prioritise it.

For us to really have a meaningful discussion, there are two things we need:

• A detailed plan of the work plan for the closed release. This is my job that I want finished in early Jan.

• A detailed (ticket-level) plan of the required CABLE integration work. ????????