The Enlarged Developer's Committe will take place on 18 and 19 June 2013 in Paris. This meeting is one of the major steps to build the NEMO perspectives (5 to 10 years), cf. ​http://www.nemo-ocean.eu/About-NEMO/News/Identify-main-development-streams-for-the-future.

Enlarged Developer's Committee: 18-19 June 2013 (Paris)

All documents, including white papers, contributions, presentations and summary of discussions are in the attachments at the bottom of this page. =

Meeting location:

The meeting will take place at UPMC - Jussieu: ​see access and campus map here
Meeting room: Tower 23 (see campus map above. From main entrance, go to the left to Tower 25, then get deeper into ground works to Tower 23). 4th floor. Corridor 23-22. Room 401

Agenda

Tuesday 18 June: General overview, presentation of the documents and presentation of other projects of interest and discussions
10:00 Welcome coffee
10:30 - 10:45 Opening of the meeting (S. Joussaume)
10:45 – 12:00 Brief presentation of available documents, 10 mn for each, (pdf of presentations are attached below):
CMCC (S. Dobricic) , CNRS (A-M. Tréguier), INGV (A. Guarnieri), Mercator (Y. Drillet), MetOffice & NERC-NOC (J. Holt),
others: CONCEPTS & CCCma, Canada (Y. Drillet), EC-EARTH & ECMWF(K. Mogensen)
12:00 – 12:20 Presentations:
About Gung-Ho (Nigel Wood – Met Office)
12:20 - 2:00 Lunch
2:00 – 3:30 Discussion on the five white papers and additional contributions
3:30 – 4:15 Thematic discussions:BR]'''Session 1: NEMO platform: seamless to what extend? (Leaders: J. Holt and P. Marsaleix)'''[[BR? With ORCA12 (global 1/12°) are we reaching an optimal level? Should we continue moving towards higher resolutions or should we stop there and work in a probabilistic way to quantify errors?
In the future, is the NEMO platform expected to be modelling all time and space scales from global to coastal (up to rivers, tide banks, module sedimentary module, etc…) or is there a boundary in small scales (coastal) and associated processes where NEMO should stop, and/or be properly connected to another modelling platform?
Contours of NEMO in the future (components, diagnostics, data reduction)
4:15 - 4:45 Coffee break
4:45 - 6:15 Thematic discussions (cont’):
Session 2: New dynamical cores, HPC and science (Leaders: S. Masson & N. Wood)
Session 3: Sea-ice and biogeochemical components (Leaders: O. Aumont & M. Vancoppenolle) Which level of flexibility should we target to take efficiently in account the panel of available and used components for sea-ice (NEMO-LIM, CICE, GELATO…) and for biogeochemistry (NEMO-TOP, BFM, MEDUSA…)?
6:30 Cocktail at Peniche Marcounet Pont Marie, Voie Georges Pompidou, 75004 Paris 06 60 47 38 52, see map in attached document below
Wednesday 19 June:
9:00 – 11:00 Thematic discussions (cont’):
Session 4: Is AGRIF a major feature of NEMO? (Leaders: L. Debreu & D. Iovino)
If answer is yes, what is needed in mid-term to have it as a reliable component?
Session 5: Contours and limits of the assimilation component of NEMO (Leaders: P. Brasseur & S. Dobricic)
Session 6: NEMO validation and contours of user support (Leaders : P. Oddo & J. Siddorn)
Although having all possible options working all the time is the NEMO user's dream, it is not possible. What is needed and where does the System Team stops? How many reference configurations should be supported by the System Team and what should they be?
11:00 – 11:20 Coffee break

11:20 -12:00 Conclusions “on the fly” by a group including: for CMCC(S. Dobricic), for CNRS(J. Le Sommer), for INGV(A. Guarnieri), for Mercator(Y. Drillet), for Met-Office(R. Wood), for NERC-NOC(A. Coward), and Scientific Leader (G. Madec)
Suggestions of the committee: for the summary of final document, how to build NEMO’s roadmap for the next 10 years?
Suggestions to Steering Committee for next steps (writing and discussing the final document)
12:30 End of the meeting

Results and conclusions:

"Conclusions on the fly" in attached document below

Notes from the leaders of the sessions

Session 1: NEMO platform: seamless to what extend? (Leaders: J. Holt and P. Marsaleix)

See also table in attached document at bottom of the page.
On seemless modelling in NEMO:

1. There is not a great drive nor enthusiasm for multi-scale (e.g. unstructured meshes) approaches presently within this community. Personally, I somewhat disagree with this view of the future but I agree the approaches (e.g. an ocean model within gung-ho) need to be better developed, tested and demonstrated before we might expect substantial community buy in. Certainly , I still see this door as being open.
2. There are upscaling issues. These weren’t listed in detail, but include river inputs/coastal currents, dense water formation on shelf seas, frictional processes at shelf slope, dense overflows and ‘pinch points’, and a whole list of BGC/ecosystem processes. These can be addressed to some extent with global high resolution and 2-way nesting (e.g. AGRIF), without resorting to a full multi-scale approach.
3. There is a clear need for a near coastal capability in nemo – this includes wetting/drying and surface wave coupling. Concerns were expressed (and noted) that the wetting/drying approach should not be obtrusive (at least initially), but methods such moving boundary approaches could be considered in the future for paeleo work. There are many approaches to wave coupling and lots of physical implication to it depending on the problem at hand (ie waves on current, coupled wave-current or coupled wind-wave-current). Curvilinear coordinates are an important capability for near coastal work, and with it nemo has a potential advantage of being much more computationally efficient than unstructured mesh options – very useful for longer term near-coastal simulations.
4. Resolution and parameterisations need to be considered together and both require development, noting we are moving towards submesoscale permitting models needed to actual resolve the mesoscale, and that observational resolution is increasing to accommodate this.

Session 2: New dynamical cores, HPC and science (Leaders: S. Masson & N. Wood)

• No strong driver to move away from orthogonal curvilinear coordinate with quadrilateral C-grid, together with coupling provided by AGRIF. Question: Does that approach have a finite life time or will it work forever? See also Jason's comments.
• This means that there is no driver for closer sharing of GungHo natural science (ie the vast majority of the kernels).
• However, scalability remains an issue and therefore there is a need to expose as much parallelism as possible (this favours the small kernel approach) and maintain flexibility, as well as protecting parallel code and natural science developers from each other! This favours a layered approach.
• Scope for sharing this approach with GungHo most likely lies in the Application Programming Interfaces (APIs) and possibly also in the Parallelisation Systems (PSy) layer (though the extent of the latter is unclear).

At the meeting I (N. Wood) additionally expressed my personal point of view that having a document, which clearly outlines what the critical scientific properties of NEMO are, could be invaluable, as well as having a clear specification of the scope of applications. In any development there will inevitably be a number of compromises to be made. Having these two documents allows an informed decision over which compromises to make and which not. This allows more progress and less stalemate.'

Session 3: Sea-ice and biogeochemical components (Leaders: O. Aumont & M. Vancoppenolle)

Biogeochemistry Coming soon...

Sea Ice

• The sea ice session was coupled to biogeochemistry and was very short.
• NEMO is coupled to LIM2-3 (model and interface in the reference), to CICE (interface in the reference) and to GELATO.
• Going towards more generic and flexible interfaces is an objective. In practise, however, an interface always has some strong model dependencies, and full generality can hardly be achieved.
• The developments for sea ice in NEMO were detailed for LIM and include: hpc optimization, ice dynamics, advection of multiple tracers, and the introduction of various complexity levels in the model.
• HPC optimization should be addressed, in particular the fact that the sea ice model is called on all points of the domain.
• The need for a sea ice model in NEMO was still seen as necessary as the interface has to be tested by someone.

Session 4: Is AGRIF a major feature of NEMO? (Leaders: L. Debreu & D. Iovino)

Most of the audience agrees that AGRIF is a fundamental tool for NEMO.
The higher the interest in high-resolution regional modeling, shelf and coastal areas, the more useful AGRIF becomes. So, more effort is needed to develop, maintain, test and document NEMO-AGRIF.

Recent, ongoing, near-future improvements:

1. NEMO-LIM2_VP. But there is a standard version NEMO-LIM with AGRIF?
2. AGRIF in coupled model with a zoom in both the ocean and the atmosphere (project by S. Masson) – that also helped to solve some technical problems
3. AGRIF used with NEMOVAR
4. MPP: is done in AGRIF, but there are modifications needed in NEMO. Some processors could be dedicated to the child grids
5. Nesting tools: it will be simplify and it will include only the option to interpolate the bathymetry.

To be improved:

1. The software doc is too old. User-guide and documentation are available online about AGRIF in other models, not in NEMO. There is nothing on AGRIF in the NEMO book.
2. An AGRIF demonstrator is available in ORCA2-LIM2 with a zoom in the Agulhas region. This is quite old, unclear if it has been tested in the recent NEMO versions. It does not explain how to make a zoom.
3. Simple tutorials should be provided online on how to build a new zoom with technical information on interpolation method, bathymetry building, and connections between parent and child grids.
4. Possibility to use AGRIF in the Arctic Ocean with an ORCA grid.
5. Possibility to cross East-West cyclic boundary.
6. AGRIF library. Laurent thinks it is not worth to invest in one source translator only for AGRIF. He suggested to give a closer look at open source Rose compiler (that does not require extra coding, probably).
7. The ocean code should be optimized to minimize the work done by AGRIF pre-processor and to improve the compatibility of a new release with AGRIF.
8. AGRIF compatibility with LIM2-EVP rheology and next LIM3, CICE.
9. The vertical refinement in AGRIF is still under development. Possibility to have different vertical grids and coordinates system between mother and child grids.
10. Strong coupling in NEMO at barotropic level – that requires technical work.
11. Global conservation of tracers in NEMO.
12. Possibility to use AGRIF with other models as biogeochemical ones.

The main point is that the developers and the community of users want to have AGRIF available in the NEMO system, but for that we need

1. to put in more effort to improve AGRIF maintenance, robustness, and versatility. In France there were at least 4 phd focused on AGIRF, what about UK and others? Liverpool might be interested in the maintenance of the software but not with ORCA grids.
2. a precise work plan, which could take AGRIF through to around 2020. Clear steps have to be defined to have AGRIF fully operational whatever the chosen numerical option.
3. RESOURCES. Projects and groups in charge of NEMO-AGRIF. To find someone available now to conduct tests seems hard, probably it would be easier after some improvements.

Session 5: Contours and limits of the assimilation component of NEMO (Leaders: P. Brasseur & S. Dobricic)

The general concept of an assimilation component within NEMO has been promoted since 2009 with the objective of making assimilation tools for NEMO more readily available to the user community. Based on the consensus that a comprehensive assimilation system cannot be incorporated and maintained in the long term within the NEMO system, the purpose of session 5 was to clarify what should be the contours and limits of the NEMO assimilation component. 4 main questions were addressed and discussed during the meeting:

1. Is the current partition between built-in, interface and external components of assimilation a reasonable trade-off, or should we move the boundary? It was agreed that the 3 existing building blocks (OBS, ASM, TAM) should be maintained and further developed in such a way to increase their usefulness by assimilation groups, but also by modeling groups (e.g. using TAM for sensitivity studies).
2. While TAM and ASM modules have no equivalent alternatives in the community, the OBS component is an issue since some groups are developing alternative tools to interface NEMO simulations with observational data sets (for assimilation or diagnostic purposes). In the future, one should ensure that the OBS component evolves in such a way that it could be used more systematically by more groups, using more diverse observational data sets.
3. Should we have a generic interface for data assimilation schemes based on a modular approach with structures (without writing to the disk) ? There was no clear-cut position reached on this question, but we believe that this approach should be encouraged in the long term, and further discussed with the assimilation user community (which was not widely represented in the audience).
4. In the future, should NEMO include a capability to produce probabilistic information (i.e. ensemble model trajectories), in addition to deterministic runs ? This was recognized as an important goal to be considered in the future, especially by NEMO members concerned with assimilation issues. However, there are several key applications that would benefit from such a capability, which extend beyond the strict scope of ensemble assimilation (e.g. for non-linear modelling sensitivity studies in complement to the linearized TAM approach, uncertainty estimation for climate projections, studies of intrinsic variability and chaotic properties of the ocean, stochastic modelling of model errors etc.). It would be great if this capability would enable on-line computation of ensemble means and spread, as well as various ensemble statistics with observational data. This topic will require further brainstorming in order to define an appropriate roadmap for including this option in future NEMO systems.

Session 6: NEMO validation and contours of user support (Leaders : A. Guarnieri & J. Siddorn)

Does NEMO need users?
- what is the priority for the NEMO consortium, to build a community model for use by all (PhD students, developing nations etc.) or building a model fora for consortium use?
- How much time should we devote to building for user interaction?
- How much time should we spend supporting user enquiries?
- How much time should we spend building tools to make NEMO easy vs scientifically better?

Users are an essential part of the NEMO development, and bring a lot of gearing. It would be good to understand what users do bring: is it papers referencing NEMO, model development that feeds through to NEMO or expertise. It is probably all of these. They are also responsible for picking up on many different bugs in the system, so help to keep the code clean.

Users, once they have a critical mass, can be self supporting through news groups.

In a similar way to support for AGRIF, we are all agreed we need to produce better tools and support users better, but we have to do so on a limited resource so we need to accept that user tool development will be relatively slow.

One thing that is missing that other models have is a nice example of how to set up a configuration and run it. George Nurser has volunteered to develop an example/tutorial of the Gyre. In addition to this it was suggested to well define a set and document of test cases to test specific issues. This would be crucial both from the consortium perspective (to test the quality and consistency of the model) and for from the user's perspective. It was noted that the system team is presently a team of developers who do some user support when possible, They are not necessarily interested or skilled in user support activities: user support and model development are completely different tasks and this needs to be recognised. Primarily we need a good model to attract users, and at present it was felt the focus should remain on developing the model but in the future perhaps more emphasis should be put on user tool development, fora and interactions.

NEMO is a hydrodynamic code. Where do the boundaries lie for NEMO and user support?
- NEMO
- NEMO+ice
- NEMO+ice+tools
- NEMO+ice+tools+BGC+waves+DA+ice-shelves+higher-trophic-phyto+sediment+light+hydrology+coupler ……..
This is a subject that has come up over the last couple of days, and should perhaps be referred to the steering committee for decision.

What is needed in NEMO and where does the System Team stop?
- Should NEMO be a framework or a model?
- framework = lots of options, switchable, wide range of users
- a model = limited options, best available science settings.
- How many and what should the future reference configurations be?
- Shall we provide reference configuration testing the model capability to reproduce relevant physical processes or to simulate particular areas of the word ocean?
- Dataset: bathymetry, forcings, rivers … and all the input files NEMO can use
- Shall we share our code after publishing a manuscripts?
- Shall the consortium or the consortium member maintain community configurations (global, ibi, amm, med …)

It was felt that the present balance of options in the model is good, although some effort needs to be put to deprecating options no longer supported. This goes in the direction of the agreed decision of simplifying the model (see conclusions on the fly). A way to define this type of deprecation, though, needs to be decided, and the rationale that stands behind this won't be easy to be defined. The general idea was to no add new options.

Some suggestions were also made in terms of having an approach more divided into "core capibilities" and "added capibilities", i.e by adding modularity to the system.

ORCA025 could be an example configuration, even perhaps via the ftp already available from Jean-Marc rather than supported by NEMO team. Perhaps some analytical or sample test cases could be included as part of the standard configurations. No conclusions were made on which configurations we need, and that needs to go back to the developers committee.

For what concerns the community configurations and/or the users' specific configurations it was suggested that the system may be organized in a way to enable the external users to make available their own specific configurations and datsets. This could be made by adding some tools in the CONFIG or MAKE that allows the user for connecting to a common space and downloading all the needed inputs to each configurations.

What is testing for?
- What are we testing with present NEMO standard configurations? How many and what should be the future reference configurations?
- Is SETTE a useful tool?
- Do we test for technical robustness only or do we also test for scientific quality as part of the systems team

There is the alpha and beta testing phases when the consortium members do their own testing. Gurvan also runs ORCA2 simulations which then get posted on the NEMO web page. This would seem to cover a lot of this. It was suggested that a set of standard metrics could be included to ensure nothing dramatic has happened. Some felt this may be beyond what the system team could do, and that it is not at all for granted that the scientific quality of the model and its configurations should be matter for the system team.

Participants:

Family Name	First name	Will attend 18 June	Will attend cocktail 18 June	Will attend 19 June	Member of:(DevCom?, SysTeam?, invitees..)
Lévy	Claire	Yes	Yes	Yes	Devcom - SysTeam?
Siddorn	John	Yes	Yes	Yes	DevCom
Treguier	Anne Marie	yes	yes	yes	DevCom?
Molines	Jean-Marc	yes	yes	yes	DevCom?
Foujols	Marie-Alice	yes	yes	yes	SysTeam
Barthélemy	Antoine	yes	yes	yes	DevCom?, for Thierry Fichefet
Masson	Sébastien	yes	yes	yes	SysTeam?
Oddo	Paolo	yes	yes	yes	Devcom - SysTeam?
Ethé	Christian	yes	yes	no	Devcom - SysTeam?
Madec	Gurvan	yes	yes	yes	Devcom - Systeam
Flavoni	Simona	yes	yes	yes	SysTeam
Coward	Andrew	yes	yes	yes	Devcom - SysTeam?
Furner	Rachel	yes	yes	yes	Devcom - SysTeam?
Wood	Richard	yes	yes	yes	Steering Committe
Wood	Nigel	yes	yes	yes	Invitee
Dupont	Frederic	no	no	no	ext. regional exp.
Holt	Jason	yes	yes	yes	Invitee
Clementi	Emanuela	yes	yes	yes	SysTeam?
Guarnieri	Antonio	yes	yes	yes	cons. exp.
Bricaud	Clement	yes	yes	yes	Devcom - SysTeam?
Drillet	Yann	yes	yes	yes	cons. exp.
Biastoch	Arne	yes	yes	yes	Invitee
Iovino	Dorotea	yes	yes	yes	cons. exp.
Mogensen	Kristian	yes	yes	yes	Devcom
Reffray	Guillaume	yes	yes	yes	SysTeam?
Brasseur	Pierre	yes	yes	yes	Invitee
Nurser	George	yes	yes	yes	SysTeam?
Vidard	Arthur	yes	yes	yes	Devcom
Joussaume	Sylvie	yes	yes	no	Steering Committee
Debreu	Laurent	yes	yes	yes	Invitee
Benshila	Rachid	yes	yes	yes	SysTeam?
Vancoppenolle	Martin	yes	yes	No	SysTeam?
Pickles	Stephen	yes	yes	yes	Invitee
Aumont	Olivier	yes	yes	yes	DevCom? (L. Bopp)
New	Adrian	yes	yes	yes	Steering Committee
Dobricic	Srdjan	yes	yes	yes	Devcom - Systeam
Eldin	Gérard	yes	yes	yes	Steering Committee (P. Bertrand)
Le Sommer	Julien	yes	yes	yes	Invitee

Documents for, and results of the meeting (see attachments below):