Merge ew-develop into ew-main for v2.1 release #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… in CAM This commit adds the attribute used_by="cam" to namelist options need by the MPAS-A dycore in CAM. A Python script (build_cam_namelists.py) included with the MPAS-A dycore in CAM may be used to extract all such namelist options and to build pieces of files needed by CAM to define namelists. For the CAM-MPAS Python script to extract an option, the enclosing nml_record tag must have used_by="cam", as must the nml tag itself.
In the mpas_framework_init_phase2 routine, the namelist options config_pio_stride and config_pio_num_iotasks were accessed regardless of whether MPAS was being run in a configuration that used an external PIO io_system or not. For stand-alone configurations, an external PIO io_system will generally not be available, in which case config_pio_stride and config_pio_num_iotasks must be accessible so that their values can be passed to mpas_io_init, where PIO is initialized. In coupled configurations, an external PIO io_system will often be provided by the driver, and a minimal MPAS Registry.xml file may omit config_pio_stride and config_pio_num_iotasks. Accordingly, the values of these non-existent namelist options must not be accessed in mpas_framework_init_phase2. Besides accessing config_pio_stride and config_pio_num_iotasks only when necessary, this commit also moves the access of config_calendar_type inside of an if-test on the presence of an external calendar.
This merge ensures that the namelist options config_pio_stride and config_pio_num_iotasks are accessed only when necessary, enabling the namelists for coupled MPAS configurations to be minimized by omitting these options. In the mpas_framework_init_phase2 routine, the namelist options config_pio_stride and config_pio_num_iotasks were accessed regardless of whether MPAS was being run in a configuration that used an external PIO io_system or not. For stand-alone configurations, an external PIO io_system will generally not be available, in which case config_pio_stride and config_pio_num_iotasks must be accessible so that their values can be passed to mpas_io_init, where PIO is initialized. In coupled configurations, an external PIO io_system will often be provided by the driver, and a minimal MPAS Registry.xml file may omit config_pio_stride and config_pio_num_iotasks. Accordingly, the values of these non-existent namelist options must not be accessed in mpas_framework_init_phase2. Besides accessing config_pio_stride and config_pio_num_iotasks only when necessary, this commit also moves the access of config_calendar_type inside of an if-test on the presence of an external calendar. * framework/init_with_external_pio: Only access config_pio_stride and config_pio_num_iotasks when necessary
This merge adds a new optional argument, unitNumbers, to the core%setup_log routine. The mpas_log_init routine takes an optional argument, unitNumbers, to specify which Fortran unit numbers to use for the output and error log files written by a core. The mpas_log_init routine is called by the core % setup_log routine, which previously did not have an argument for passing in logging unit numbers. This commit adds an optional argument, unitNumbers, to the core % setup_log routine, and it modifies the implementation of each core's setup_log routine to pass the optional unitNumbers argument to the mpas_log_init routine. The core % setup_log routine is called by the MPAS subdriver's mpas_init routine, and at present no changes are made to the mpas_init routine to pass optional unitNumbers to the core % setup_log routine. However, the changes in this commit do enable alternate implementations of mpas_init to supply unit numbers to be used for logging, e.g., in coupled systems where the coupler has already defined logging units for each component. * framework/external_log_units: Add optional argument 'unitNumbers' to core % setup_log(...) routine
… I/O options This commit adds the used_by="cam" attribute to namelist options in the MPAS-A Registry.xml file that are either needed during the block-setup process or during the dimension-setup process. Specifically, the attribute is added to the following: * config_number_of_blocks * config_explicit_proc_decomp * config_proc_decomp_file_prefix * input_soil_temperature_lag * num_soil_layers * months * noznlev * naerlev * camdim1
This merge enables the sounding diagnostics module to handle the non-existence of the config_sounding_interval namelist option. When MPAS-Atmosphere is built as a dycore in other modeling systems (e.g, CAM/CESM), only a subset of the stand-alone MPAS-Atmosphere namelist options may be available. To avoid segfaults in the soundings diagnostic module due to the non-existence of the config_sounding_interval option in such cases, add extra logic in the soundings_setup routine to detect that this namelist option is not available and deactivate soundings just as we would if config_soundings_interval = 'none'. * atmosphere/no_sounding_namelist: Enable soundings to handle non-existence of config_sounding_interval option
This merge enables MPAS-Atmosphere to be compiled in a dynamics-only configuration, which omits all physics dimensions, pools, and namelist options. * atmosphere/minimal_dynamics_only: Pre-process out physics dimensions, pools, and options without -DDO_PHYSICS Use PHYSICS definition in diagnostics sub-Make and pre-processing of Registry.xml Conflicts: src/core_atmosphere/Registry.xml
This merge allows mpas_bootstrap_framework_phase1 to use an externally provided PIO file_desc_t. When MPAS is a component in a larger system, it may be necessary to "bootstrap" the MPAS infrastructure from an externally provided file descriptor. This commit adds an optional PIO file_desc_t argument to mpas_bootstrap_framework_phase1, which is then passed to MPAS_io_open. The MPAS_io_open routine now uses the optional PIO file_desc_t if provided, and opens the file indicated by the filename argument * framework/bootstrap_w_pio_filedesc: Allow mpas_bootstrap_framework_phase1 to use an externally provided PIO file_desc_t
This merge ensures that PIO_closefile is not called in MPAS_io_close for externally provided PIO file handles. In order to avoid closing a PIO file_desc_t that was not opened by MPAS_io_open (because this external file_desc_t was provided as an optional argument in the call to MPAS_io_open), this commit adds a new member, external_file_desc, to the MPAS_IO_Handle_type type. This member is set to .true. if an external PIO file_desc_t was provided, and if .true. in the call to MPAS_io_close, PIO_closefile is not called. * framework/dont_close_external_pio: Don't call PIO_closefile in MPAS_io_close for externally provided PIO filedesc
…e/cam This merge enables phase-2 bootstrapping from external PIO file_desc_t The mpas_bootstrap_framework_phase2 was previously capable of scanning through all input streams from the streams.<core> file to find definitions of dimensions. With the changes in this commit, this search for dimensions can be restricted to a single, externally provided PIO file_desc_t. * framework/external_pio_handle_bootstrap: Permit phase 2 bootstrapping from external PIO file_desc_t
This commit adds an optional argument, pio_file_desc, to the MPAS_createStream routine, enabling a stream to be created based on an existing, opened PIO file descriptor. The pio_file_desc argument is simply passed through to the MPAS_io_open routine.
This merge permits the creation of streams from existing PIO file descriptors. A new optional argument, pio_file_desc, has been added to the MPAS_createStream routine, enabling a stream to be created based on an existing, opened PIO file descriptor. The pio_file_desc argument is simply passed through to the MPAS_io_open routine. * framework/external_filedesc_stream: Permit creation of streams from existing PIO file descriptors
This commit checks to see that `config_fg_interval` in the namelist.init_atmosphere and the output interval for the `surface` stream are the same for init_case 8.
…MPAS-Dev#330) This merge adds a check to ensure that the intermediate file interval and the 'surface' stream output interval match when generating surface update files for MPAS-Atmosphere. When config_fg_interval does not match the output_interval for the 'surface' stream, the init_atmosphere_model core will now generate a fatal error. * init_atmosphere/sst_interval_check: SST input and output interval check
The fields defined in the new dyn_in and dyn_out pools may be directly referenced by CAM-MPAS's dynamics import and export states, since the members of those states are pointers. Eventually, redundant versions of fields (e.g, uReconstructZonal and ux) that already exist elsewhere in the Registry.xml file should be avoided, but the final organization of CAM-MPAS's import and export states is yet unknown.
… threads When MPAS-Atmosphere was compiled with OpenMP and run with multiple threads, an out-of-bounds array access was generated in the GWDO scheme when an array of size (ims:ime) was assigned to an array of size (its:ite): cleff(its:ite) = dxmeter The simple fix is to copy only the elements (its:ite) of the dxmeter array: cleff(its:ite) = dxmeter(its:ite) When the GWDO scheme is run with just one thread, ims = its and ime = ite, so there was no out-of-bounds access.
… tendencies The 'dyn_in' and 'dyn_out' pools were previously added to store the CAM-MPAS dynamics import and export states. However, the preferred approach in CAM is to have the dycore define its import and export states to match as closely as possible the prognostic state of the dycore. To that end, CAM-MPAS will now point to 'u', 'w', 'rho_zz', 'theta_m', 'scalars', and fields holding the total tendencies from physics. Since these total tendency fields did not previously exist, they have been added as 'tend_ru_physics', 'tend_rtheta_physics', and 'tend_rho_physics'. These will be referenced by the CAM-MPAS dynamics import state, and they are now used in the atm_srk3 routine in place of what were local, allocatable arrays.
…stry.xml The adv_coefs and adv_coefs_3rd fields had typographical errors in their descriptions, which have been corrected.
…-Dev#421) This merge corrects the misspelling of 'coefficients' and 'fields' in the descriptions for the adv_coefs and adv_coefs_3rd fields in the atmosphere core's Registry.xml file. * atmosphere/registry_typo_foelds: Correct misspelling of 'coefficients' and 'fields' in atmosphere Registry.xml
) This merge fixes an out-of-bounds array access when the GWDO scheme was run with multiple threads. When MPAS-Atmosphere was compiled with OpenMP and run with multiple threads, an out-of-bounds array access was generated in the GWDO scheme when an array of size (ims:ime) was assigned to an array of size (its:ite): cleff(its:ite) = dxmeter The simple fix is to copy only the elements (its:ite) of the dxmeter array: cleff(its:ite) = dxmeter(its:ite) When the GWDO scheme is run with just one thread, ims = its and ime = ite, so there was no out-of-bounds access. * atmosphere/gwdo_openmp_fix: Fix out-of-bounds array access when GWDO scheme was run with multiple threads
The description for the albedo12m field incorrectly spelled 'surface' as 'aurface'. This commit corrects the misspelling.
…PAS-Dev#423) This merge corrects the misspelling of 'surface' in the description of the albedo12m field in the atmosphere core's Registry.xml file. * atmosphere/albedo12m_typo_aurface: Correct misspelling of 'surface' in atmosphere Registry.xml
This merge makes the 'postread_reindex' routine public in mpas_stream_manager. The postread_reindex routine in the mpas_stream_manager module was previously private. However, code that builds ad hoc streams at the mpas_io_streams level that contain indexing fields could benefit from the use of this routine to reindex indexing fields (e.g., cellsOnCell). Unlike the prewrite_reindex and postwrite_reindex routines, which rely on module state, the postread_reindex routine does not rely on any module variables in the mpas_stream_manager module, and can therefore be safely used by external code. * framework/public_postread_reindex: Make 'postread_reindex' routine public in the mpas_stream_manager module
…calars Following a comment in the code, the unused arguments scalar_tend and rho_zz_int can be removed from the argument list of atm_advance_scalars. Furthermore, as the actual argument (scalar_tend_array) to scalar_tend was only used in the call to atm_advance_scalars, it can also be removed from the atm_time_integration module.
The atm_advance_scalars routine previously had a test on the value of local_advance_density to determine how to call the atm_advance_scalars_work. However, both calls to atm_advance_scalars_work are identical after the changes in the preceding commit, and so the if-test can be eliminated.
There was previously substantial duplicated code to call the atm_advance_scalars and atm_advance_scalars_mono routines from two places in the atm_srk3 routine, depending on the setting of config_split_dynamics_transport. This common code has been moved to a new routine, advance_scalars.
The atm_advance_scalars and atm_advance_scalars_mono routines never used the vertex loop bound arguments, which have now been removed in order to simplify the code.
This commit removes unused variables from the scalar transport routines (advance_scalars, atm_advance_scalars, atm_advance_scalars_work, atm_advance_scalars_mono, and atm_advance_scalars_mono_work). This commit also modifies the comment style for transport routines to match the prevailing style in the MPAS framework.
Prior to this commit, several queries of field dimensions were being made in the advance_scalars routine, and the resulting values passed down through argument lists into the atm_advance_scalars and atm_advance_scalars_mono routines. In an effort to clean up the argument lists, these queries have been moved one level down in the call stacks for the scalar transport.
…variables
The tend_ru_physics, tend_rtheta_physics, and tend_rho_physics variables were
formerly allocatable module variables in the atm_time_integration module. When
MPAS-Atmosphere is run as a dycore in CAM, setting these physics tendencies
and having the ability to read/write them from/to restart files would be better
facilitated by having them be defined as Registry variables (and therefore,
having them be accessible from pools).
This commit rearranges the preprocessing directives in the Registry.xml file
so that the tend_physics pool (var_struct) is always defined with the fields
tend_ru_physics, tend_rtheta_physics, and tend_rho_physics (and also tend_uzonal
and tend_umerid, which were already part of tend_physics and are used by
CAM-MPAS). This commit also modifies the atm_srk3 routine to simply obtain
pointers to these variables via mpas_pool_get_array calls rather than
allocating/deallocating arrays.
Note that the storage for tend_{ru,rtheta,rho}_physics now persists for the
duration of a model run rather than for the duration of a call to atm_srk3.
The physics tendancy variables were changed from an allocatable to a pointer variable. This is done to accomodate the variables coming from CAM. These module pointer variables causes issues with OpenACC execution. As a workaround, currently the kernels involving tend variables are moved to CPU for CAM dycore execution. The issue has been communicated to the NVHPC compiler group.
Scratch variables may be fetched and used in OpenACC parallel sections, but can cause partially present issues when the array is deallocated but the memory isn't freed on the device. By using an `!$acc exit data delete(f % array) finalize` statement in the deallocate_scratch routines, the memory is guranateed to be freed on the device too.
…s needed
In order to allow stand-alone MPAS-Atmosphere to allocate the tend_ru_physics,
tend_rtheta_physics, and tend_rho_physics fields only for the duration of a call
to atm_srk3 (as was done when these fields were allocatable arrays), this commit
converts these fields to scratch fields. The allocation and deallocation of
these fields in the atm_srk3 routine only happens when MPAS_CAM_DYCORE is not
defined.
When MPAS-Atmosphere is run as a dycore in CAM, the tend_{ru,rtheta,rho}_physics
fields need to persist between calls to the dycore, since these fields are set
in the CAM physics-dynamics coupling layer. When MPAS_CAM_DYCORE is defined,
these scratch fields are allocated and deallocated once per run in the
mpas_atm_dynamics_init and mpas_atm_dynamics_finalize routines.
Note that CAM-MPAS will need to ensure that calls to mpas_atm_dynamics_init and
mpas_atm_dynamics_finalize are made at appropriate points in the CAM-MPAS run
sequence.
…dencies Previously, if the DO_PHYSICS macro was not defined, we assumed that MPAS-Atmosphere was running without physics, in which case we set the physics tendencies tend_ru_physics, tend_rtheta_physics, and tend_rho_physics to zero. However, if MPAS-Atmosphere is running as a CAM dycore, the DO_PHYSICS macro is not defined (since we don't want to activate any of the stand-alone MPAS- Atmosphere physics), but we do not want to clear the physics tendency fields, which are set in the CAM-MPAS dynamics-physics coupling interface. If MPAS-Atmosphere is running as a CAM dycore, the MPAS_CAM_DYCORE will be defined, so we now only clear physics tendencies if neither DO_PHYSICS nor MPAS_CAM_DYCORE are defined.
…v#916) This merge changes the tend_{ru,rtheta,rho}_physics variables from local variables to Registry-defined scratch variables. The tend_ru_physics, tend_rtheta_physics, and tend_rho_physics variables were formerly allocatable module variables in the atm_time_integration module. When MPAS-Atmosphere is run as a dycore in CAM, setting these physics tendencies and having the ability to read/write them from/to restart files would be better facilitated by having them be defined as Registry variables (and therefore, having them be accessible from pools). This merge rearranges the preprocessing directives in the Registry.xml file so that the tend_physics pool (var_struct) is always defined with the fields tend_ru_physics, tend_rtheta_physics, and tend_rho_physics (and also tend_uzonal and tend_umerid, which were already part of tend_physics and are used by CAM-MPAS). In order to allow stand-alone MPAS-Atmosphere to allocate the tend_ru_physics, tend_rtheta_physics, and tend_rho_physics fields only for the duration of a call to atm_srk3 (as was done when these fields were allocatable arrays), the allocation and deallocation of these fields in the atm_srk3 routine happens when MPAS_CAM_DYCORE is not defined. When MPAS-Atmosphere is run as a dycore in CAM, the tend_{ru,rtheta,rho}_physics fields need to persist between calls to the dycore, since these fields are set in the CAM physics-dynamics coupling layer. When MPAS_CAM_DYCORE is defined, these scratch fields are allocated and deallocated once per run in the mpas_atm_dynamics_init and mpas_atm_dynamics_finalize routines. Note that CAM-MPAS will need to ensure that calls to mpas_atm_dynamics_init and mpas_atm_dynamics_finalize are made at appropriate points in the CAM-MPAS run sequence.
…ev#917) This merge ensures that physics tendencies aren't zeroed-out when MPAS-Atmosphere is run as a CAM dycore. Previously, if the DO_PHYSICS macro was not defined, we assumed that MPAS-Atmosphere was running without physics, in which case we set the physics tendencies tend_ru_physics, tend_rtheta_physics, and tend_rho_physics to zero. However, if MPAS-Atmosphere is running as a CAM dycore, the DO_PHYSICS macro is not defined (since we don't want to activate any of the stand-alone MPAS- Atmosphere physics), but we do not want to clear the physics tendency fields, which are set in the CAM-MPAS dynamics-physics coupling interface. If MPAS-Atmosphere is running as a CAM dycore, the MPAS_CAM_DYCORE will be defined, so we now only clear physics tendencies if neither DO_PHYSICS nor MPAS_CAM_DYCORE are defined.
…PAS-Dev#900) This merge removes the unused used_by="cam" attributes from the atmosphere core's Registry.xml file. The used_by="cam" attributes in the atmosphere core's Registry.xml file were formerly used by a Python script (build_cam_namelists.py) in the CAM repository when automatically generating CAM-MPAS namelist definitions. However, this Python script is no longer used -- namelist options in CAM-MPAS must be defined by hand -- and so the used_by="cam" attribute can be safely removed from the Registry.xml file.
…S-Dev#901) This merge reverts changes from the use of NF_FILL_ constants to NF90_FILL_ constants in mpas_io.F. The change from NF_FILL_* to NF90_FILL_* constants in mpas_io.F was needed when building MPAS-Atmosphere as a CAM dycore in the past, but since CAM/CESM has updated to using PIO2, these changes are no longer needed (because the affected code is pre-processed out when USE_PIO2 is defined). Since the use of NF_FILL_* constants worked without apparent problem in stand- alone MPAS, perhaps as a consequence of the way that PIO was installed by MPAS users, it seems preferable to revert the mpas_io.F code to its former state.
This merge brings the 'atmosphere/cam' branch up-to-date with the current 'develop' branch and it resolves conflicts between the two branches. Conflicts: src/core_atmosphere/Registry.xml src/core_atmosphere/dynamics/mpas_atm_time_integration.F src/framework/mpas_attlist_types.inc src/framework/mpas_framework.F
…lars The prev, next, sendList, recvList, and copyList members of all field derived types are now nullified by default in mpas_field_types.inc, rendering the nullification of these members in the atm_allocate_scalars routine redundant.
…cam (PR MPAS-Dev#919) This merge removes unnecessary nullification of field members in the atm_allocate_scalars routine. The prev, next, sendList, recvList, and copyList members of all field derived types are now nullified by default in mpas_field_types.inc, rendering the nullification of these members in the atm_allocate_scalars routine redundant.
MPAS Version 7.1 This minor release addresses several issues in the MPAS-Atmosphere model and initialization, and it corrects several minor compilation issues. MPAS-Atmosphere: ---------------- * In calculating moist air density in the real-data initialization case, virtual temperature, rather than temperature, should be used. * An out-of-bounds array access in the GWDO scheme when running with multiple OpenMP threads has been corrected. * A check has been added in the init_atmosphere core to ensure that the intermediate file interval and the 'surface' stream output interval are consistent. * A non-standard BOZ-literal constant has been corrected in the module_ra_cam_support.F file. The non-standard constant lead to build failures, particularly with newer versions of the GNU compilers. General software: ----------------- * The logic to add PIO libraries to the definition of LIBS in the top-level Makefile has been updated to accommodate newer versions (approx. 2.5.2 or later) of the PIO library; without the fix to the Makefile, builds would fail with the message Checking for a usable PIO library... ************ ERROR ************ Failed to compile a PIO test program Please ensure the PIO environment variable is set to the PIO installation directory ************ ERROR ************ * Various options for the 'gfortran' build target have been cleaned up. * Occasional parallel build failures related to a race condition in the ezxml library compilation have been addressed.
MPAS Version 7.2 This minor release addresses several issues in the MPAS-Atmosphere model. MPAS-Atmosphere: ---------------- * Correct the use of uninitialized memory in the init_atm_case_squall_line routine by initializing the qvb array to zero before its first use. * Fix a bug in the vertical extrapolation of relative humidity and specific humidity to model levels below the lowest first-guess level when first-guess levels are given in top-to-bottom order in the input intermediate file. * Fix reproducibility issues in several fields within the Noah LSM over land-ice points when running with different MPI task counts; however, only one of these fields -- smstav, the surface moisture availability field -- persists outside of the physics driver and is written to MPAS-Atmosphere restart files. * Correct the units and description attributes for the GWDO fields var2d, con, oa1, oa2, oa3, oa4, ol1, ol2, ol3, and ol4 in both the init_atmosphere and atmosphere core Registry.xml files. * Add code that had inadvertently been omitted for computing dtheta_dt_mp, the potential temperature heating rate from microphysics. Prior to this change, the dtheta_dt_mp field would always contain a constant zero value when written to model output files. * Correct a check on the availability of the dtheta_dt_mix variable when computing depv_dt_mix in the PV diagnostics module. * Correct the parallel computation of iLev_DT (and other fields that depend on it, including u_pv, v_pv, theta_pv, vort_pv, depv_dt_diab_pv, and depv_dt_fric_pv) in the PV diagnostics module.
MPAS Version 7.3 This minor release addresses one issue in the MPAS-Atmosphere model. MPAS-Atmosphere: ---------------- * Update the checkout_data_files.sh script to use HTTPS rather than the unencrypted Git protocol when obtaining the MPAS-Data repository from GitHub.
Catch up with the version of MPAS-A used in ESCOMP/CAM cam6_3_058 until cam6_3_137. This should enable this OpenACC enabled branch to work with those versions of CAM.
if MPAS_CAM_DYCORE pre-processor directive is used to hide radiation coupler code for CAM runs. The standalone MPAS radiation coupler code is not used in CAM runs.
Match with eworg/mpas-framework
Change copied from EarthWorksOrg/mpas-framework PR #2
Change from real3dField to real4dField
Synch with EarthWorksOrg/mpas-framework version
Incorporate changes for EarthWorks v2.1 release
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.