Chemistry stub modules for MUSICA MICM

[dwfncar]

• Added subdirs core_atmosphere/chemistry and core_atmosphere/chemistry/musica, with Makefiles.
• Modified core_atmosphere/Makefile to build chemistry source.
• Added MUSICA MICM stub modules chemistry/mpas_atm_chemistry.F and chemistry/musica/mpas_musica.F.

The module chemistry/mpas_atm_chemistry.F has non-implemented stub subroutines for

• init_chemistry (will call musica_init from mpas_musica)
• step_chemistry (will call musica_step from mpas_musica)
• finalize_chemistry (will call musica_finalize from mpas_musica)

chemistry/musica/mpas_musica.F will define the mpas_musica module with the musica_init, musica_step, and musica_finalize subroutines, also to be implemented.
It uses and directly links to the MUSIC MICM modules

• musica_micm
• musica_state
• musica_util

Also included is an error checking function has_error_occurred.

Note that the call to music_init will take as an argument the chemistry species defined as a new mpas_var_array to be implemented in a new framework module, for instance mpas_runtime_vars. The calling arguments will be further specified in subsequent PRs.

[K20shores]

I have no problems with this, but I do have the same question as matt

[mgduda]

I've left just a few initial comments, and I'll take a closer look and probably offer a second round of comments.

[mgduda]

On Derecho with the gcc/12.4.0 module and the musica/0.10.1 module from /glade/work/mattdawson/modulefiles I'm getting an ICE when compiling mpas_musica.F:

f951: internal compiler error: in matching_typebound_op, at fortran/interface.cc:4479

Which modules / compilers are you testing with on Derecho, @dwfncar @K20shores @mattldawson ?

[dwfncar]

On Derecho with the gcc/12.4.0 module and the musica/0.10.1 module from /glade/work/mattdawson/modulefiles I'm getting an ICE when compiling mpas_musica.F:

f951: internal compiler error: in matching_typebound_op, at fortran/interface.cc:4479

Which modules / compilers are you testing with on Derecho, @dwfncar @K20shores @mattldawson ?

I setup my environment with the following commands:

module --force purge
module load ncarenv/24.12
module load craype/2.7.31
module load gcc/12.4.0
module load ncarcompilers/1.0.0
module load cray-mpich/8.1.29
module load parallel-netcdf/1.14.0
module load netcdf/4.9.2
source /glade/campaign/mmm/wmr/mpas_tutorial/mpas_env/bin/activate
module load ncview
export PATH=/glade/campaign/mmm/wmr/mpas_tutorial/metis/bin:${PATH}
module use /glade/work/mattdawson/modulefiles
module load musica

Looks like same gcc and musica versions.
Let me try a clean build on derecho ...

[dwfncar]

I replicated the compile error on derecho.
It is due to line 70 in mpas_musica.F
micm_version = get_micm_version()
Introduced in this commit from yesterday
2c001d8

Prior to the commit I did successfully build and run with that call in place on my Ubuntu desktop ...
assumed would be OK on derecho ...

[dwfncar]

The simple Ubuntu build environment was just setup via the conda package manager:

conda create --name mpas
conda activate mpas
conda install -c conda-forge gcc gxx gfortran mpich libnetcdf libpnetcdf parallelio
export NETCDF=$HOME/miniconda3/envs/mpas
(same for PNETCDF and PIO),

and building both MUSICA and MPAS with that compiler set (gcc v15).

[dwfncar]

Looking back at the hackathon version of mpas_musica.F,
I see a micm_t object was instantiated and micm%get_state method was called,
but not get_version, ...

The MUSICA GitHub actions do test builds with gcc/gfortran v12 - v13 and the unit tests exercise all Fortran interface functions. I think I need to do a MUSICA build and check the unit tests on derecho.

[dwfncar]

MUSICA MICM unit tests with our derecho build environment are all OK.

(mpas_env) fillmore@derecho7:~/MUSICA/build> make test

Running tests...
Test project /glade/u/home/fillmore/MUSICA/build
Start 1: component_versions
1/9 Test #1: component_versions ............... Passed 0.02 sec
Start 2: util
2/9 Test #2: util ............................. Passed 0.01 sec
Start 3: micm_wrapper
3/9 Test #3: micm_wrapper ..................... Passed 0.01 sec
Start 4: micm_c_api
4/9 Test #4: micm_c_api ....................... Passed 0.02 sec
Start 5: parser
5/9 Test #5: parser ........................... Passed 0.15 sec
Start 6: micm_fortran_api
6/9 Test #6: micm_fortran_api ................. Passed 0.01 sec
Start 7: get_micm_version
7/9 Test #7: get_micm_version ................. Passed 0.01 sec
Start 8: micm_box_model
8/9 Test #8: micm_box_model ................... Passed 0.01 sec
Start 9: demo_fortran
9/9 Test #9: demo_fortran ..................... Passed 0.01 sec

100% tests passed, 0 tests failed out of 9

[dwfncar]

Compiler issue on derecho persists with custom MUSICA build.

[dwfncar]

ccmake for MUSICA on derecho:
Got the same BLAS not found error with default settings.
But config OK if

MUSICA_ENABLE_CARMA OFF
MUSICA_ENABLE_TUVX OFF

also will want
MUSICA_BUILD_FORTRAN_INTERFACE ON
And set
CMAKE_INSTALL_PREFIX <my_install_path>

Usually from the MUSICA root dir I do:

mkdir build
cd build
ccmake ..
make
make test
make install

Also need
export PKG_CONFIG_PATH=<my_install_path>/lib64/pkgconfig

Also in general a good idea to
conda deactivate
(including the base environment)
before cmake configuration.

[mgduda]

@dwfncar With the following at the beginning of the mpas_musica module

    use musica_micm,  only: micm_t, get_micm_version

and modifying the use of musica_micm in the musica_init routine to

        use musica_micm, only : RosenbrockStandardOrder

, the ICE disappears for me. It's not ideal, but perhaps we can use a work-around like this so that we can build CheMPAS-A on Derecho with the GNU 12.4.0 compilers? In the commit message, and even with a code comment if we'd like, we can explain why we're importing get_micm_version at the module level rather than within the musica_init routine.

[dwfncar]

@dwfncar With the following at the beginning of the mpas_musica module

    use musica_micm,  only: micm_t, get_micm_version

and modifying the use of musica_micm in the musica_init routine to

        use musica_micm, only : RosenbrockStandardOrder

, the ICE disappears for me. It's not ideal, but perhaps we can use a work-around like this so that we can build CheMPAS-A on Derecho with the GNU 12.4.0 compilers? In the commit message, and even with a code comment if we'd like, we can explain why we're importing get_micm_version at the module level rather than within the musica_init routine.

I'll go ahead and make that update with a comment and commit the changes ...

[mgduda]

This looks good to me -- nice work!

Since we don't use "squash and merge" in this repository, it might be nice to rework the commit history so that it contains a small number of commits (or even a single commit) with detailed commit messages before we merge this PR.