influence content of auto-generated files

[dkokron]

I want an auto-generated file to contain OpenMP directives. Can someone point me to documentation on how to accomplish this.

As an example, I've attached a file that I modified by hand after it was generated.
ccpp_FV3_HAFS_v1_gfdlmp_tedmf_nonsst_time_vary_cap4.F90.txt

[dkokron]

I hacked scripts/mkstatic.py to make the auto-generated contain the required OpenMP directives, but resulting ccpp_FV3_HAFS_v1_gfdlmp_tedmf_stochastics_cap.F90 file is broken by my hack. Really could use some guidance/mentorship on this effort.

[climbfuji]

@dkokron If you could create a branch in your fork of ccpp-framework with the changes you made, and then a complete code tree for the UFS or SCM (not sure what you were using) with the correct branches, i.e. something that I can check out recursively from the top to get exactly the code you are using? I need to be able to do (if using UFS WM)

git clone -b your_branch_name --recursive https://github.com/dkokron/ufs-weather-model

and get exactly your code base to help.

[dkokron]

Working on this now.

[dkokron]

git clone -b hafs-SprinkleOpenMP --recursive https://github.com/dkokron/ufs-weather-model hafs-SprinkleOpenMP
The only change I made in this branch is to file FV3/ccpp/framework/scripts/mkstatic.py

cd hafs-SprinkleOpenMP/tests

./compile.sh acorn "-DAPP=HAFSW -DMOVING_NEST=ON -DCCPP_SUITES=FV3_HAFS_v1_gfdlmp_tedmf,FV3_HAFS_v1_gfdlmp_tedmf_nonsst,FV3_HAFS_v1_thompson_tedmf_gfdlsf -D32BIT=ON" 23 intel YES NO >& make.log

The compile fails with the following because my hack on FV3/ccpp/framework/scripts/mkstatic.py adds code to stochastics CAP that does not belong there. I'd like to limit my changes to a particular CAP if that is possible.

cd /u/daniel.kokron/Scratch/Projects/UFS/hafs-SprinkleOpenMP/tests/build_fv3_23/FV3/ccpp/physics && /opt/cray/pe/craype/2.7.13/bin/ftn -DFV3 -DINTERNAL_FILE_NML -DMOIST_CAPPA -DMPI -DNEMS_GSM -DOVERLOAD_R4 -DUSE_COND -I/u/daniel.kokron/Scratch/Projects/UFS/hafs-SprinkleOpenMP/tests/build_fv3_23/FV3/ccpp/physics -I/lfs/h1/emc/nceplibs/noscrub/hpc-stack/libs/hpc-stack/intel-19.1.3.304/w3emc/2.9.2/include_d -I/lfs/h1/emc/nceplibs/noscrub/hpc-stack/libs/hpc-stack/intel-19.1.3.304/bacio/2.4.1/include_4 -I/lfs/h1/emc/nceplibs/noscrub/hpc-stack/libs/hpc-stack/intel-19.1.3.304/sp/2.3.3/include_d -I/lfs/h1/emc/nceplibs/noscrub/hpc-stack/libs/hpc-stack/intel-19.1.3.304/cray-mpich-8.1.7/netcdf/4.7.4/include -g -traceback -fpp -fno-alias -auto -safe-cray-ptr -ftz -assume byterecl -nowarn -sox -align array64byte -qno-opt-dynamic-align -O2 -debug minimal -qoverride-limits -fp-model consistent -real-size 64 -qopenmp -c /u/daniel.kokron/Scratch/Projects/UFS/hafs-SprinkleOpenMP/tests/build_fv3_23/FV3/ccpp/physics/ccpp_FV3_HAFS_v1_gfdlmp_tedmf_stochastics_cap.F90 -o CMakeFiles/ccpp_physics.dir/ccpp_FV3_HAFS_v1_gfdlmp_tedmf_stochastics_cap.F90.o
/u/daniel.kokron/Scratch/Projects/UFS/hafs-SprinkleOpenMP/tests/build_fv3_23/FV3/ccpp/physics/ccpp_FV3_HAFS_v1_gfdlmp_tedmf_stochastics_cap.F90(53): error #6404: This name does not have a type, and must have an explicit type. [GFS_DATA]
!$omp parallel default(none), private(nthr,nsplit), shared(GFS_Data,GFS_Control)
-----------------------------------------------------------^

[gold2718]

Could this discussion be moved to or at least referenced on the CCPP Framework site where the work would be done for this?

[climbfuji]

Good point, done!

[dkokron]

Where did this discussion end up (URL)?

[climbfuji]

#470 (but nobody worked on it since then)

[dkokron]

Did anyone take a look at my proposed changes?

[climbfuji]

I don't think there's a generic way at the moment to do the type of complicated modifications that you are trying to do here. I will also note that these are data copies due to the presence of blocked data structures. We are currently exploring the option to remove those altogether and use contiguous arrays instead, since performance testing by CISL with CESM, for example, has shown that this is generally more performant than blocked data structures.

[climbfuji]

Nonetheless, i am going to take a quick look now

[climbfuji]

Let me ask this question, how much of a gain in performance do you see with these changes? Is that significant at all or just somewhere in the noise (which is what I would expect)?

[dkokron]

It's a small win. I don't have the numbers handy. I'll see if I can dig them up.

…

On Fri, Dec 1, 2023 at 10:03 AM Dom Heinzeller ***@***.***> wrote: Let me ask this question, how much of a gain in performance do you see with these changes? Is that significant at all or just somewhere in the noise (which is what I would expect)? — Reply to this email directly, view it on GitHub <#470 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACODV2BVREAS5Z4ASY2OAFDYHH5WPAVCNFSM6AAAAAAZLA4DMGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TOMZRGEZDG> . You are receiving this because you authored the thread.Message ID: ***@***.***>