-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes for when INTERNAL_FILE_NML is not used #23
Conversation
I can't assign reviewers, could someone add the appropriate people please? |
Life is not that easy ;-) There are a few commits, at least one that is currently worked on, in the queue to happen before this can get tested. Usually reviewers are added at the time the tests are run in this setup. Not ideal, but that's how it has been until now. Given the small number of changes I would suggest to have reviewers look at it earlier so that when it is ready and the tests pass it can be committed. Only @junwang-noaa or @DusanJovic-NOAA can add reviewers. I suggest @bensonr. |
Thanks for the info @climbfuji. No particular rush since we typically work from our fork. Just wanted to make sure the changes propagate upstream at some point. |
p.s. thanks for fixing the incompatibility with GNU that was introduced. |
For your information, in the last commit I set up Hera with gnu-9.3.0 as Tier-1 platform, which means that any commit to go in must pass the regression tests with this compiler as well. Thus, the days of commits breaking GNU code are history. |
That's great news, thanks. Should save us some time downstream. Our CI includes Intel, Clang and GNU so we need that working. |
I usually test on my mac with clang+gfortran, but this is of course not a tier-1 (pre-commit) testing, only when I work on/with the code. But gcc+gfortran catches most of the issues. |
Dan, I'd suggest to switch to -DINTERNAL_FILE_NML if possible, otherwise
the namelist reading could cause many small piece of I/O access issues,
GFDL fixed that by using this -DINTERNAL_FILE_NML feature for GFSv15
implementation.
…On Mon, Jun 22, 2020 at 11:09 PM Daniel Holdaway ***@***.***> wrote:
p.s. thanks for fixing the incompatibility with GNU that was introduced.
For your information, in the last commit I set up Hera with gnu-9.3.0 as
Tier-1 platform, which means that any commit to go in must pass the
regression tests with this compiler as well. Thus, the days of commits
breaking GNU code are history.
@arunchawla-NOAA <https://github.com/arunchawla-NOAA> @ligiabernardet
<https://github.com/ligiabernardet> FYI
That's great news, thanks. Should save us some time downstream. Our CI
includes Intel, Clang and GNU so we need that working.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AI7D6TOWHK4MEHIDWAMCFV3RYAKYDANCNFSM4OFG6BAA>
.
|
@junwang-noaa my understanding is that with the compiler definition set the input.nml file is read once when fms is initialized. In data assimilation we have to create several geometries potentially of different resolution. E.g. the background is the high resolution C768 while the increment is the lower C384. If doing 4DVar we even have increments at C48, C96, C192 etc as well. That all needs to be done in-core. So in the C++ level of JEDI we actually move different input.nml files in and out of the directory as we're running and read several of them. Unless I'm misunderstanding things -DINTERNAL_FILE_NML would not allow for that. |
@junwang-noaa I would also note that GMAO (unless things have changes recently @wmputman?) also do not use -DINTERNAL_FILE_NML. For GEOS it's because npx, npy and layout are provided by geos and fv_init is broken into two steps. |
I guess it depends on how many MPI tasks reading the input.nml. Also I am
not sure if I/O impact is an issue in your application. But in GFSv15
implementation it showed that there are too many small read actions to this
single input.nml (~10**8 if I remember correctly). If you do need to read
input.nml for different resolutions with FMS, it might be good to use one
task to read the file and pass the variables to the rest of the tasks.
…On Tue, Jun 23, 2020 at 9:00 AM Daniel Holdaway ***@***.***> wrote:
@junwang-noaa <https://github.com/junwang-noaa> I would also note that
GMAO (unless things have changes recently @wmputman
<https://github.com/wmputman>?) also do not use -DINTERNAL_FILE_NML.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AI7D6TLXS6ZTDCMV4VCUFDDRYCRNZANCNFSM4OFG6BAA>
.
|
OK, thanks for sending those numbers @junwang-noaa. We'll look into having the read be done by one processor if we find it's an issue. I assumed that's what it was doing since it's read by an mpp routine so good to know that it's not. |
Unlike ESMF, one can see the source code and inline documentation for FMS.
The function read_input_nml is public and can be used to reset the
character string input_nml_file as needed.
For any additional namelist file you'd like to read in, the name of the
file must be input_<name>.nml. The call to read_input_nml would be:
call read_input_nml("name")
This functionality is used to read in a different namelist file for the
nesting. For example, each nest needs both the global namelist and it's
own namelist.
!--- read fv_core_nml from input.nml
read(input_nml_file, fv_core_nml)
!--- opens, reads input_nest02.nml on rank 0, and broadcasts as
input_nml_file
read_input_nml("nest02")
!--- reads fv_core_nml from input_nml_file
read(input_nml_file,fv_core_nml)
|
Thanks @bensonr, good to know about that functionality. I'll try that out in my geometry generation code. |
* Add LICENSE.md * Renamed driver directories and removed the null version of the nh extensions for the public release * Update license header for FV3 * Added a README.md file * Replace GPL header with LGPL header * fixed license header in every file and added it to those without it * Master test (#17) * commit of new version of dycore from Weather and Climate Dynamics Group at GFDL * updated versions of GFDL-specific files from dev/gfdl * updated README.md with current release information * cleaned up a few lines in fv_dynamics * new file RELEASE.md with release notes documenting differences between this and the last release * updated RELEASE.md message * hand merge of diagnostic updates * remove trailing spaces from sources * updates to merge some GFDL specific updates into this public release * Master test (#18) * commit of new version of dycore from Weather and Climate Dynamics Group at GFDL * updated versions of GFDL-specific files from dev/gfdl * updated README.md with current release information * cleaned up a few lines in fv_dynamics * new file RELEASE.md with release notes documenting differences between this and the last release * updated RELEASE.md message * hand merge of diagnostic updates * remove trailing spaces from sources * updates to merge some GFDL specific updates into this public release * updated README.md * updated GFDL_tools/fv_cmip_diag to be consistent with dev/gfdl branch * Bug fix for two-way nest updating (#21) * remove trailing whitespace and any tabs * update the RELEASE.md with the FV3 technical memorandum * semantic fix in RELEASE.md * adds default values for nest_*offsets in fv_control breaks up a too long line in fv_nesting.F90 * change default value of nestupdate to 7 Co-authored-by: Seth Underwood <Seth.Underwood@noaa.gov> Co-authored-by: lharris4 <53020884+lharris4@users.noreply.github.com>
At the JCSDA we don't use the INTERNAL_FILE_NML compiler definition since we need to use different resolutions in the same executable. After the most recent merging from GFDL this capability stopped working. A couple of simple changes to make it work again.
In test_cases.f90 there are some missing includes.
In fv_control.f90 GNU compilers don't like trying to open an already open file.