Problems when extending a component configuration in echam.yaml in connection with "choose_computer.name"

[khimstedt]

In connection with modifying .../esm_tools/configs/echam/echam.yaml for building a version of the proglacial lake extension "6.3.05p2-concurrent_radiation-paleodyn-plake" of ECHAM6 on the Mistral cluster two problems occurred.

I added the following lines:

        6.3.05p2-concurrent_radiation-paleodyn-plake:
                choose_computer.name:
                    mistral:
                        compiletime_environment_changes:
                            add_export_vars:
                                NETCDFROOT: "/sw/rhel6-x64/netcdf/netcdf_c-4.3.2-gcc48"
                                LD_LIBRARY_PATH: "/sw/rhel6-x64/netcdf/parallel_netcdf-1.6.1-impi-intel14/lib/:$LD_LIBRARY_PATH"
                        runtime_environment_changes:
                            add_export_vars:
                                NETCDFROOT: "/sw/rhel6-x64/netcdf/netcdf_c-4.3.2-gcc48"
                                LD_LIBRARY_PATH: "/sw/rhel6-x64/netcdf/parallel_netcdf-1.6.1-impi-intel14/lib/:$LD_LIBRARY_PATH"

Trying to build on Mistral gives the following result:

esm_master comp-echam-6.3.05p2-concurrent_radiation-paleodyn-plake

ERROR: YAML syntax

\The following ``_changes`` can be accessed simultaneously in [...]/esm-tools/esm_tools/configs/components/echam/echam.yaml:
    - choose_version.6.3.05p2-concurrent_radiation-paleodyn.choose_computer.name.mistral.runtime_environment_changes
    - choose_version.6.3.05p2-concurrent_radiation-paleodyn-plake.choose_computer.name.mistral.runtime_environment_changes

Note that if there are more than one ``_changes`` in the file, they need to be placed inside different cases of the same ``choose`` and these options need to be compatible (only one ``_changes`` can be reached at a time).
Use ``add_<variable>_changes`` if you want to add/overwrite variables inside the main ``_changes``.

I placed the entry for "6.3.05p2-concurrent_radiation-paleodyn-plake:" to the same indentation level as the already existing entry for "6.3.05p2-concurrent_radiation-paleodyn:"

If I comment out (as a workoaround) the corresponding lines for the sections "compiletime_environment_changes:" and "runtime_environment_changes:" for the already existing entry "6.3.05p2-concurrent_radiation-paleodyn", it works.

The second problem is that the settings for runtime_environment_changes, e.g.

LD_LIBRARY_PATH: "/sw/rhel6-x64/netcdf/parallel_netcdf-1.6.1-impi-intel14/lib/:$LD_LIBRARY_PATH"

seem to be ignored anyway. At least there is no corresponding setting of LD_LIBRARY_PATH in the final .sad-scriptfile created via esm_runscripts.

[mandresm]

Hi @khimstedt,

What you are seeing here is a safety feature to avoid conflicts of environment variables with the same names, that could be accesses simultaneously. However, in your case those environments cannot be accessed simultaneously as they are under different versions and therefore, this is a bug. I'll be working on a solution. In the mean time, another possible work around is to substitute your lines with:

        6.3.05p2-concurrent_radiation-paleodyn-plake:
                choose_computer.name:
                    mistral:
                        add_compiletime_environment_changes:
                            add_export_vars:
                                NETCDFROOT: "/sw/rhel6-x64/netcdf/netcdf_c-4.3.2-gcc48"
                                LD_LIBRARY_PATH: "/sw/rhel6-x64/netcdf/parallel_netcdf-1.6.1-impi-intel14/lib/:$LD_LIBRARY_PATH"
                        add_runtime_environment_changes:
                            add_export_vars:
                                NETCDFROOT: "/sw/rhel6-x64/netcdf/netcdf_c-4.3.2-gcc48"
                                LD_LIBRARY_PATH: "/sw/rhel6-x64/netcdf/parallel_netcdf-1.6.1-impi-intel14/lib/:$LD_LIBRARY_PATH"

(adding add_ to the environment dictionaries)

[nwieters]

Hi @mandresm,

has this issue been solved in recent ESM-Tools versions?

[github-actions[bot]]

This issue has been inactive for the last 365 days. It will now be marked as stale and closed after 30 days of further inactivity. Please add a comment to reset this automatic closing of this issue or close it if solved.