Version 108 (modified by clevy, 7 years ago) (diff)

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.

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


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)

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+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.


Family Name First name Will attend
18 June
Will attend
cocktail 18 June
Will attend
19 June
Member of:(Dev Com?, Sys Team?, invitees..)
Lévy Claire Yes Yes Yes Devcom - Sys Team?
Siddorn John Yes Yes Yes DevCom
Treguier Anne Marie yes yes yes Dev Com?
Molines Jean-Marc yes yes yes Dev Com?
Foujols Marie-Alice yes yes yes SysTeam
Barthélemy Antoine yes yes yes Dev Com?, for Thierry Fichefet
Masson Sébastien yes yes yes Sys Team?
Oddo Paolo yes yes yes Devcom - Sys Team?
Ethé Christian yes yes no Devcom - Sys Team?
Madec Gurvan yes yes yes Devcom - Systeam
Flavoni Simona yes yes yes SysTeam
Coward Andrew yes yes yes Devcom - Sys Team?
Furner Rachel yes yes yes Devcom - Sys Team?
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 Sys Team?
Guarnieri Antonio yes yes yes cons. exp.
Bricaud Clement yes yes yes Devcom - Sys Team?
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 Sys Team?
Brasseur Pierre yes yes yes Invitee
Nurser George yes yes yes Sys Team?
Vidard Arthur yes yes yes Devcom
Joussaume Sylvie yes yes no Steering Committee
Debreu Laurent yes yes yes Invitee
Benshila Rachid yes yes yes Sys Team?
Vancoppenolle Martin yes yes No Sys Team?
Pickles Stephen yes yes yes Invitee
Aumont Olivier yes yes yes Dev Com? (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):

Attachments (18)