access_NWP_UM_BuildProcedure - ACCESS-NRI/accessdev-Trac-archive GitHub Wiki

#!html
<h1  style="text-align: center; color: green"> UM Build Procedure draft</h1>

... the basics which are required to be able to build a UM executable:

• UM sources
• GCOM3.5 library
• Software stack

At this stage only UM source are stable.

Let’s address an issue on how the building procedure depends on a specified software stack. Here are the changes which should be implemented to reflect a change in the software stack

1. Rebuild GCOM3.5 library as well as setting a new name and location for the library.

2. Change reference to the environment setting which is currently done via script

/access/umdir/vn7.5/linux/scripts/prg_env_vn7.5_01 (1)

which is probably coming from $UMDIR/vn$VN/$TARGET_MC/scripts/.umsetvars_$VN with an "export VN=7.5" setting. In this case I would like to note that playing with a user own version of $HOME/.umsetvars_$VN referred in SCRIPT (script produced during UMUI job processing) I have not been able to change the “general” location /access/umdir/vn7.5/linux/scripts/prg_env_vn7.5_01 using a different setting for PRG_ENV in the corresponding version of my $HOME/.umsetvars_$VN file. It puzzles me a bit but at the same time I don’t have much of interest in this as it will be clear below.

3. As per the change described in item 1 above we need to make a change in the repository sources for a corresponding reference in a configuration file

machines/linux-mpich2-meto/ext_libs/gcom_mpp.cfg (2)

in the statement for “%gcom_path” definition.

4. As the corresponding UMUI building job points to a specific SVN repository revision then after committing the corresponding change of item 3 we need to update the revision number specified in the “Specify revision number or keyword of code base to use” option in the “Model Selection => FCM Configuration => FCM Options for Atmosphere and Reconfiguration” panel.

So clearly the current procedure in relation to build a new UMUI 7.5 executable set in the corresponding jobs for Global and regional executables is not flexible with any change in a software stack.

After discussing this complexity with Xiao a slightly new approach is suggested. The building environment can be set via the same PRG_ENV environment variable or via a different name for the term which should point to a file say with a name of aps1_um7.5_build_env. This script should include similar settings as the above mentioned file (1) has, also a setting for a new GCOM_TOP_DIR environment variable should be included too. This variable should point out to the top directory of the corresponding GCOM3.5 library at the same time file (2) should have the following definition

%gcom_path $GCOM_TOP_DIR (3)

After that none of the changes described above under items 2-4 are not needed with any change in the software stack, so finally we have

1. Modify the UMUI7.5 scripts to reflect the recommended change by "sourcing" the aps1_um7.5_build_env script. It should be done only once.

2. Rebuild the GCOM library and

3. Adjust the aps1_um7.5_build_env script correspondingly.

At this stage I am not sure on whether this aps1_um7.5_build_env script should be kept under the SVN repository or not at the same time I would like to note that script (1) is not included in the repository. The recommended procedure has already been tested manually in relation to setting (3).

Regards,

Ilia