Changes between Version 104 and Version 105 of Scientific Advisory Board/Agenda/2013-06-18

2013-07-05T18:22:29+02:00 (7 years ago)


  • Scientific Advisory Board/Agenda/2013-06-18

    v104 v105  
    6262= Results and conclusions: = 
    63  *  "Conclusions on the fly" in attached document below 
    64  * Notes from the leaders of the sessions in attached documents below 
     63"Conclusions on the fly" in attached document below 
     65'''Notes from the leaders of the sessions''' i 
     67'''Session 1: NEMO platform: seamless to what extend? (Leaders: J. Holt and P. Marsaleix)''' 
     69[[BR]]'''Session 2: New dynamical cores, HPC and science     (Leaders: S. Masson & N. Wood)''' 
     71'''Session 3: Sea-ice and biogeochemical components (Leaders: O. Aumont & M. Vancoppenolle)''' 
     73[[BR]]'''Session 4: Is AGRIF a major feature of NEMO? (Leaders: L. Debreu & D. Iovino)''' 
     75Most of the audience agrees that AGRIF is a fundamental tool for NEMO.[[BR]]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. 
     77Recent, ongoing, near-future improvements: 
     79 1. NEMO-LIM2_VP. But there is a standard version NEMO-LIM with AGRIF? 
     80 1. 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 
     81 1. AGRIF used with NEMOVAR 
     82 1. MPP: is done in AGRIF, but there are modifications needed in NEMO. Some processors could be dedicated to the child grids 
     83 1. Nesting tools: it will be simplify and it will include only the option to interpolate the bathymetry. 
     85To be improved: 
     87 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. 
     88 1. 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. 
     89 1. 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. 
     90 1. Possibility to use AGRIF in the Arctic Ocean with an ORCA grid. 
     91 1. Possibility to cross East-West cyclic boundary. 
     92 1. 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). 
     93 1. 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. 
     94 1. AGRIF compatibility with LIM2-EVP rheology and next LIM3, CICE. 
     95 1. The vertical refinement in AGRIF is still under development. Possibility to have different vertical grids and coordinates system between mother and child grids. 
     96 1. Strong coupling in NEMO at barotropic level – that requires technical work. 
     97 1. Global conservation of tracers in NEMO. 
     98 1. Possibility to use AGRIF with other models as biogeochemical ones. 
     100The 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 
     102 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. 
     103 1. 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.''' ''' 
     104 1. ''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. 
     106'''Session 5: Contours and limits of the assimilation component of NEMO''' '''(Leaders: P. Brasseur & S. Dobricic)''' 
     108'''Session 6: NEMO validation and contours of user support  (Leaders : A. Guarnieri & J. Siddorn)''' 
     110Does NEMO need users?[[BR]]-        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?[[BR]]-        How much time should we devote to building for user interaction?[[BR]]-        How much time should we spend supporting user enquiries?[[BR]]-        How much time should we spend building tools to make NEMO easy vs scientifically better? 
     112''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.'' 
     114''Users, once they have a critical mass, can be self supporting through news groups.'' 
     116''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.'' 
     118''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.'' 
     120NEMO is a hydrodynamic code. Where do the boundaries lie for NEMO and user support?[[BR]]-       NEMO[[BR]]-       NEMO+ice[[BR]]-       NEMO+ice+tools[[BR]]-       NEMO+ice+tools+BGC+waves+DA+ice-shelves+higher-trophic-phyto+sediment+light+hydrology+coupler ……..''[[BR]]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.'' 
     122What is needed in NEMO and where does the System Team stop?[[BR]]-        Should NEMO be a framework or a model?[[BR]]-        framework =  lots of options, switchable, wide range of users[[BR]]-        a model = limited options, best available science settings.[[BR]]-        How many and what should the future reference configurations be?[[BR]]-        Shall we provide reference configuration testing the model capability to reproduce relevant physical processes or to simulate particular areas of the word ocean?[[BR]]-        Dataset: bathymetry, forcings, rivers … and all the input files NEMO can use[[BR]]-        Shall we share our code after publishing a manuscripts?[[BR]]-        Shall the consortium or the consortium member maintain community configurations (global, ibi, amm, med …) 
     124''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.'' 
     126''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.'' 
     128''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.'' 
     130''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.'' 
     132What is testing for?[[BR]]-        What are we testing with present NEMO standard configurations? How many and what should be the future reference configurations?[[BR]]- Is SETTE a useful tool?[[BR]]-        Do we test for technical robustness only or do we also test for scientific quality as part of the systems team 
     134''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.'' 
    66136== Participants: ==