2 research outputs found

    NOAA-GFDL/FMS: 2023.04

    No full text
    <h2>[2023.04] - 2023-12-04</h2> <h3>Known Issues</h3> <ul> <li>GCC 9 and below as well as GCC 11.1.0 are unsupported due to compilation issues. See prior releases for more details.</li> <li><code>NO_QUAD_PRECISION</code> macro is no longer set by FMS, the <code>ENABLE_QUAD_PRECISION</code> macro has replaced prior usage of <code>NO_QUAD_PRECISION</code>. <code>-DENABLE_QUAD_PRECISION</code> should be set if quad precision is to be used, otherwise FMS will not use quad precision reals where applicable.</li> </ul> <h3>Added</h3> <ul> <li>DATA_OVERRIDE: A new namelist flag <code>use_data_table_yaml</code> has been added to enable usage of the yaml format data_override tables. This allows an executable built with yaml support be able to accept either format.</li> </ul> <h3>Changed</h3> <ul> <li>RESERVED KEYWORD CHANGES: Various routines in FMS have been updated to not use fortran keywords for variable names. The names changed were: <code>data</code>, <code>unit</code>, and <code>value</code>. This may affect usage of external code if argument names are explicitly used. Only required arguement names were changed to mitigate any breaking changes.</li> <li>TESTS: Changes the testing scripts to allow for the <code>MPI_LAUNCHER</code> environment variable override to work with any provided arguments.</li> </ul> <h3>Fixed</h3> <ul> <li>CMAKE: Fixed build issue with CMake where precision default flags were being overwritten when using GNU and MPICH.</li> <li>AUTOTOOLS: Fixes issue affecting installs where the global libFMS.F90 module was not being installed correctly and adds post-install message.</li> <li>DIAG_MANAGER: Fixes issue with incorrect start_time functionality (from the 2023.02.01 patch)</li> </ul> <h3>Tag Commit Hashes</h3> <ul> <li>2023.04-beta1 be1856c45accfe2fb15953c5f51e0d58a8816882</li> </ul&gt

    NOAA-GFDL/FMS: 2023.03

    No full text
    <h2>[2023.03] - 2023-10-27</h2> <h3>Known Issues</h3> <ul> <li>GCC 9 and below as well as GCC 11.1.0 are unsupported due to compilation issues. See prior releases for more details.</li> <li><code>NO_QUAD_PRECISION</code> macro is no longer set by FMS, the <code>ENABLE_QUAD_PRECISION</code> macro has replaced prior usage of <code>NO_QUAD_PRECISION</code>. <code>-DENABLE_QUAD_PRECISION</code> should be set if quad precision is to be used, otherwise FMS will not use quad precision reals where applicable.</li> </ul> <h3>Added</h3> <ul> <li>UNIT_TESTS: New unit tests have been created or and existing ones expanded on for any modules utilizing mixed precision support.</li> </ul> <h3>Changed</h3> <ul> <li>MIXED PRECISION: Most subroutines and functions in FMS have been updated to simultaneously accept both 4 byte and 8 byte reals as arguments. This deprecates the <code>--enable-mixed-mode</code> option, which enabled similar functionality but was limited to certain directories and was not enabled by default. To facilitate easier testing of these code changes, the CMake precision options for default real size were left in (along with an equivalent <code>--disable-r8-default</code> flag for autotools). The resulting libraries will support mixed-precision real kinds regardless of default real size. It should also be noted that many routines that accept real arguments have been moved to include files along with headers in order to be compiled with both kinds. Most module level variables were explicitly declared as r8_kind for these updates.</li> <li>Some type/module changes were made to facilitate mixed precision support. They are <strong>intended</strong> to have minimal impact to other codebases:<ul> <li>COUPLER_TYPES: In coupler_types.F90, <code>coupler_nd_field_type</code> and <code>coupler_nd_values_type</code> have been renamed to indicate real kind value: <code>coupler_nd_real4/8_field_type</code> and <code>coupler_nd_real4/8_values_type</code>. The <code>bc</code> field within <code>coupler_nd_bc_type</code> was modified to use r8_kind within the value and field types, and an additional field added <code>bc_r4</code> to use r4_kind values.</li> <li>TRIDIAGONAL: Module state between r4 and r8 calls are distinct (ie. subsequent calls will only be affected by calls of the same precision). This behaviour can be changed via the <code>save_both_kinds</code> optional argument to <code>tri_invert</code>.</li> </ul> </li> <li>CODE_STYLE: has been updated to reflect the formatting used for the mixed precision support updates.</li> </ul> <h3>Fixed</h3> <ul> <li>DIAG_MANAGER: Tile number (ie. tileX) will now be added to filenames for sub-regional diagnostics.</li> <li>MPP: Bug affecting non-intel compilers coming from uninitialized pointer in the <code>nest_domain_type</code></li> <li>MPP: Bug fix for unallocated field causing seg faults in <code>mpp_check_field</code></li> <li>FMS2_IO: Fixed segfault occuring from use of cray pointer remapping along with mpp_scatter/gather</li> <li>TEST_FMS: Added various fixes for different compilers within test programs for fms2_io, mpp, diag_manager, parser, and sat_vapor_pres.</li> <li>INTERPOLATOR: Deallocates fields in the type that were previously left out in <code>interpolator_end</code></li> </ul> <h3>Removed</h3> <ul> <li>CPP MACROS:<ul> <li><code>no_4byte_reals</code> was removed and will not set any additional macros if used. <code>no_8byte_integers</code> is still functional.</li> <li><code>NO_QUAD_PRECISION</code> was removed. It was conditionally set if ENABLE_QUAD_PRECISION was undefined. ENABLE_QUAD_PRECISION should be used in model components instead (logic is flipped)</li> <li><code>use_netCDF</code> was set by autotools previously but wasn't consistently used in the code. FMS should always be compiled with netcdf installed so this was removed with the exception of its use in deprecated IO modules.</li> </ul> </li> <li>DRIFTERS: The drifters subdirectory has been deprecated. It will only be compiled if using the <code>-Duse_drifters</code> CPP flag.</li> </ul> <h3>Tag Commit Hashes</h3> <ul> <li>2023.03-beta1 06b94a7f574e7794684b8584391744ded68e2989</li> <li>2023.03-alpha3 b25a7c52a27dfd52edc10bc0ebe12776af0f03df</li> <li>2023.03-alpha2 9983ce308e62e9f7215b04c227cebd30fd75e784</li> <li>2023.03-alpha1 a46bd94fd8dd1f6f021501e29179003ff28180ec</li> </ul&gt
    corecore