Skip to content

Conversation

@cbegeman
Copy link

@cbegeman cbegeman commented Oct 21, 2021

The file extension of the main routine ppr_1d.f90 needed to be F90 in order for cmake to recognize the c-style # include lines. Since the library is in active use, a copy of ppr_1d was created with the F90 extension.

@dengwirda
Copy link
Owner

@cbegeman, did creating a second ppr_1d.F90 that contains #include ppr_1d.f90 work out okay as an alternative in the end? Thanks very much for looking into this.

@cbegeman
Copy link
Author

@dengwirda That looks like it's working out fine. Wish the solution was more elegant!

@dengwirda
Copy link
Owner

@cbegeman, I still need to do some more testing on this, but I think this might be an alternative *.F90 vs *.f90 option:

# include "ppr_1d.f90"

@cbegeman
Copy link
Author

@dengwirda Can you update me on where you got with your testing of this #include "ppr_1d.f90" version? As we move toward opening the VLR PR, let's settle on one of the two options we identified. Thanks!

@dengwirda
Copy link
Owner

Hi @cbegeman, I'd say the version that's in dev presently is my prefered option --- the single additional ppr_1d.F90 that simply # include's the actual ppr_1d.f90 library, and keeps compatibility with existing workflows.
I've confirmed that this seems to work as expected for gfortran workflows --- do you think this should satisfy E3SM in general? If so, I'll merge this into master which should then make it available in E3SM via git submodule update --init --recursive.

@cbegeman
Copy link
Author

@cbegeman
Copy link
Author

cbegeman commented Feb 7, 2022

@dengwirda The following worked for me:

  • Anvil, intel compiler, successful run with VLR branch and VLR on (executing PPR calls)
  • Anvil, intel compiler, successful (bfb) comparison between VLR branch and master
  • Anvil, gnu compiler, successful (bfb) comparison between VLR branch and master

Is there any other testing that you think is necessary before merging this PR?

Note: VLR branch is based on E3SM-Ocean-Discussion/E3SM/master and uses this PPR branch, master refers to E3SM-Ocean-Discussion/E3SM/master

@whannah1
Copy link

whannah1 commented May 15, 2024

Seems like this PR is pretty stale, but Having two copies of ppr_1d with "f" and "F" is very annoying when I'm working locally on a mac where file names are handled in a case-insensitive way. My local E3SM repository always shows the PPR submodule as "dirty" and shows uncommitted changes as the difference between these two files. I have the same problem with "example/ex_1.F90".

Is there a way to rename these files so that it's not just the case of one letter that is changing?

@dengwirda
Copy link
Owner

@whannah1 originally there was indeed only a single *.f90 extension used throughout, and the -cpp flag was used to enable the preprocessor. The *.F90 workaround was added due to E3SM's build system (at least at the time) requiring it.
If there's another option available I'd be happy to consider it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants