Implement string tokenization functionalities as defined in Fortran 2023

[kuanchihwang]

Tag name (required for release branches):

None

Originator(s):

kuanchihwang

Descriptions (include the issue title, and the keyword ['closes', 'fixes', 'resolves'] followed by the issue number):

This PR implements the new string tokenization functionalities that have been standardized in Fortran 2023. Specifically, two new intrinsic procedures have been defined with the following signatures:

1. split (string, set, pos [, back]), defined in section 16.9.196.
2. tokenize (string, set, tokens [, separator]) or tokenize (string, set, first, last), defined in section 16.9.210.

The implementations provided by this PR should be fully compliant with the specifications in Fortran 2023.

Additionally, the parse_stream_name function, which is part of the I/O infrastructure for MPAS dynamical core, is refactored to use the tokenize subroutine for better robustness.

Describe any changes made to the build system:

None

Describe any changes made to the namelist:

None

List any changes to the defaults for the input datasets (e.g., boundary datasets):

None

List all files eliminated and why:

None

List all files added and what they do:

None

List all existing files that have been modified, and describe the changes:

M       src/core_utils/string_core_utils.F90
M       src/utils/string_utils.F90
M       test/unit/fortran/src/core_utils/test_string_core_utils.pf
  * Avoid unnecessary renames from `stringify` to `core_stringify`
  * Also make `split` and `tokenize` available in `string_utils` module
M       src/dynamics/mpas/driver/dyn_mpas_procedures.F90
  * Implement `split` and `tokenize` from Fortran 2023
M       src/dynamics/mpas/driver/dyn_mpas_subdriver.F90
  * Rewrite `parse_stream_name` in terms of `tokenize`
M       src/dynamics/mpas/dyn_procedures.F90
  * Add missing dates
M       src/dynamics/mpas/tests/unit/test_dyn_mpas_procedures.pf
  * Implement unit tests for `split` and `tokenize`

Regression tests:

  SMS_Ln9.ne3pg3_ne3pg3_mg37.FKESSLER.derecho_intel.cam-outfrq_se_cslam_multitape (Overall: NLFAIL)

Except for the known failing test above, all the other tests pass with respect to the last baseline, sima0_09_000.

[kuanchihwang]

To reviewers, you can check out the rendered code documentation here for split and here for tokenize.

[jimmielin]

Thanks @kuanchihwang. I wonder what made the GNU regression tests different (it looks like the snapshot runs are fine which is great!). Maybe we have to accept the new baselines as it is difficult to know what changed at this point.

help@ hasn't gotten back to me yet about the libhugetlbfs.so issue I've been running to that crashes GNU runs at runtime, but it looks like the file is now available on the compute nodes again (I was able to run a case as well). Maybe they are still in the progress of fixing issues?

[nusbaume]

Hi @kuanchihwang @jimmielin, I just ran the SIMA regression tests with the head of the ESCOMCAM-SIMA development branch and I got the same set of failures, so my guess is that the underlying libraries changed somehow during the update and that is what is causing the differences (I agree that it is not related to the changes in this PR).

I have no idea why it is SE-CSLAM specific, but the magnitudes seem quite small (largest relative differences of ~1e-7), and given that the dycore is out-of-date anyways I am not too worried about it at this stage, as long as it is recorded somewhere (e.g. here) so that if we need to trace any differences back we can.

[jimmielin]

Sounds good, thanks @nusbaume and @kuanchihwang! I agree if it's just SE it's probably fine, at least we know the physics code remains bit-for-bit.

[jimmielin]

Hi @kuanchihwang I pushed the changed GNU baselines post-Derecho upgrade as part of sima0_09_000 (#426) so hopefully you will have all GNU tests bit-for-bit now. Thanks!

[nusbaume]

Thanks @kuanchihwang! I just had a few, hopefully simple, requests.

[nusbaume]

Thanks for the extra comments and tests @kuanchihwang! I had one last (optional) test string modification request to try and maximize test coverage, but otherwise this PR looks good to me.

[kuanchihwang]

@nusbaume It seems that I need one more approving review to proceed with the PR. Would you like to suggest an additional reviewer? Thanks!

[nusbaume]

@kuanchihwang just letting you know that your PR should be ready to go now. Thanks for bringing it in!