Source code management (validation)

• Use of cc_depend , gmkpack

Code has more and more dependencies. Use of sophisticated compilation and building tools is recommended. Possibilities:

- gmkpack's (Météo-France) advantage is, that there is support for ODB as well.

- cc_depend (CHMI) is the other option, but it is currently does not handle ODB.

- cc_depend could be perhaps built in gmkpack .

Þ Recommendation :

Developers outside Toulouse are encouraged to use gmkpack . The possibility to merge cc_depend and gmkpack should be explored.

• Source code management:

There will be more and more need to have local source code management due to local development and local operational applications.

Þ Recommendation :

The usage of CVS. Export version of CVSTUC (a set of scripts making CVS more user friendly for ALADIN) will be created. For the package contact Martin Janousek.

Xrd problems

• xrd should be cleaned (useless routines to be removed etc.).
  
• duplication of .c and .F routines.
  
• All project (except xrd) can be compiled without explicit promotion of real and integer values.
  
• Problem of explicit declaration of arrays (memory consumption)
  

Þ Conclusions :

Olda, Gabor, Martin, Stjep and Jure write a list of existing problems in xrd with a proposal of solutions. Olda starts the action. Jean-Daniel Gril will be the Météo-France contact person. It should be decided inside the above nominated group how to sort out problems and in which format to enter the modifications, after a possible (mandatory) check with ECMWF.

Documentation

• Users manual for configuration 001 would be very useful. There are some parts partially covered (i.e. non-hydrostatic) from scientific and architecture point of view.
  
• Technical/scientific documentation (with the structure similar to Alain Joly's paper) has to be written.
  

Þ Conclusion :

Météo-France will invite a volunteer to Toulouse to set up the skeleton of documentation. Afterwards, the documentation will be completed and maintained with the help of experts for specific parts.

• Other proposal is improve self-documentation in the code (modules): short explanation of the module + description of module variables (easier to follow changes)
  
• Exercise for phasing: enhance explanations in modules
  

Þ Conclusion :

Prototype namelists of all working configurations have to be added to export versions of new cycles with explanations in separate file or in the namelist itself.

Coding rules

• A great part of the work has been done with Ryad's documentation.
  
• Automatic checker for the code is needed.
  

Þ Conclusions :

-   Read and comment the coding rules and send the comments.

-   Météo-France will discuss the usage of coding rules with ECMWF.

-   Coding rules are obligatory while working on the ALADIN code.

-   Coding rules are recommended while working on external tools related to ALADIN.

-   Concerning the automatic checker, it could be the supplementary part of new fortran2html parser.

Future code evolution

• Further externalization, modularization (as TFL/TAL)

  goal : step by step towards more rationalized and modular code.

  proposals : biperiodization, coupling?, FullPos...

  question : how to handle the interfaces to modular part?

• Parallel I/O: follow the evolvement of implementation of MPI-2, but no concrete actions for the time being.
  
• Revision of data flow (not decided yet who and how it is going to do the job)
  
• Reformulation of physics/dynamics interface

Phasing (validation) strategy

• Number of phasers is limited, on the other hand the number of configurations has increased and they have to be phased rather sequentially than in parallel
  

Þ The spirit of phasing has slightly changed :

-   rather continuous than a "one go" procedure

-   the job has been split to direct code phasing followed by the phasing of data assimilation parts (a core-group works on the basic configurations and the rest is phased afterwards)

Þ Further proposals :

-   Some parts of the phasing could be exported.

-   Training of newcomer phasers (this workshop was a proper introduction).

Export version

• Some additional information to be attached to export versions:

-   prototype namelists

-   specific document about validated configurations

• Incremental strategy for export versions was proposed which means:

-   a basic export version (at least 927, 001, FullPos)

-   bugfixes for other working configurations (bugfixes with respect to the basic version)

• LACE ASC (Olda) will be responsible to report the platform-specific modifications of the code with respect to the reference version in Météo-France and other local specific issues.

ODB

• Generic problem is the lack of documentation:

-   installation guide would be very useful

-   validation guide/doc. - " -

Both have to evolve with modifications cycle by cycle...

• It was decided that the LACE Data Manager (Stjep) will take over the coordination of the ODB related work, to start with the writing of an installation guide.
  
• It is planned that possibly Sandor + Stjep will work together on next cycle's installation in Budapest.

Web server

• Recommendation: Visit to Météo-France has to be organized to maintain the web server.
  
• Mirroring between intranet and internet part of ALADIN web server.

AOB

• Next workshop about maintenance in 2004, decision at the next ALADIN Assembly of Partners
  
• Format has to change perhaps to the lectures in the morning and exercises in the afternoon.
  
• Undiscussed topics : Optimization, E923

Home