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.

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 (room will be opened at 9:00)

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:

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

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)

Coming soon...

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)

Coming soon...'

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):