Add the 3DIAU capability for regional HAFS#399
Conversation
…onsistent with that in FV3/atmos_model.F90.
output (fort.602, the partial atcf track file).
…nt from set_regional_BCs in fv_regional_bc.F90
tools/fv_grid_tools.F90.
…tialized elements of qin array Input array qin in a2b_ord2 routine is declared as qin(is-ng:ie+ng,js-ng:je+ng) but only elements in (is-1:ie+1, js-1:je+1) range are initialized in a calling routine, for example pin array in adv_pe routine in dyn_core.F90
…MAKE_Fortran_FLAGS_DEBUG)
…to feature/hafsv2p2_baseline
…hafsv2p2_baseline
… Lanczos-like temporal filter
…into feature/hafsv2p2_sync
| if ( open_file(fileobj_regional, trim(fname), 'read') ) then | ||
| ! Read increments | ||
| call read_data(fileobj_regional, 'u_inc', tmp) | ||
| increment_data%ua_inc=tmp(is:ie,js:je,:) | ||
| call read_data(fileobj_regional, 'v_inc', tmp) | ||
| increment_data%va_inc=tmp(is:ie,js:je,:) | ||
| call read_data(fileobj_regional, 'T_inc', tmp) | ||
| increment_data%temp_inc=tmp(is:ie,js:je,:) | ||
| call read_data(fileobj_regional, 'delp_inc', tmp) | ||
| increment_data%delp_inc=tmp(is:ie,js:je,:) | ||
| if ( .not. Atm%flagstruct%hydrostatic ) then | ||
| call read_data(fileobj_regional, 'delz_inc', tmp) | ||
| increment_data%delz_inc=tmp(is:ie,js:je,:) | ||
| end if | ||
|
|
||
| ! Read tracer increments | ||
| do itracer = 1,ntracers | ||
| call get_tracer_names(MODEL_ATMOS, itracer, tracer_name) | ||
| if ( variable_exists(fileobj_regional, trim(tracer_name)//'_inc') ) then | ||
| call read_data(fileobj_regional, trim(tracer_name)//'_inc', tmp) | ||
| increment_data%tracer_inc(:,:,:,itracer)=tmp(is:ie,js:je,:) | ||
| end if | ||
| end do | ||
| call close_file(fileobj_regional) | ||
| end if |
There was a problem hiding this comment.
I don't understand why this block is needed. The original code should be able to handle reading in the (is:ie,js:je,:) section of each rank.
What error/behavior were you getting without these changes? Were all ranks reading in the same data?
There was a problem hiding this comment.
Hi, @uramirez8707
When using the original type(FmsNetcdfDomainFile_t) :: fileobj together with
if (open_file(fileobj, trim(fname), 'read', Atm%domain)) then
call read_data(fileobj, 'u_inc', increment_data%ua_inc)
the code consistently failed at the open_file stage when reading the regional increment file. Unfortunately, no informative diagnostic message was produced to indicate the exact cause of the failure.
As a comparison test, I switched to using type(FmsNetcdfFile_t) :: fileobj_regional to open the same increment file, and in that case the file opened and the data were read successfully without issue.
My current guess is that FmsNetcdfDomainFile_t may be coupled to a specific grid or tiling metadata expected by the domain object—likely assuming a global or multi-tile configuration. In our case, the regional 3DIAU increment file corresponds only to a single moving nest tile 8 and does not carry the same grid/tiling definition as a full FV3 domain file. This mismatch may cause the domain-aware file interface to reject the file at open time.
The added block is therefore a workaround to allow successful reading of the regional increment data using a grid-agnostic NetCDF interface. I understand it is not ideal, but since our nest domain is very small (660 x 660 x 81), the computational cost seems to be acceptable. If there is a recommended way to make FmsNetcdfDomainFile_t work with single-tile, nest regional increment files, I would be very interested in adopting that approach instead.
… the help of Uriel Ramirez (uriel.ramirez@noaa.gov)
gaokun227
left a comment
gaokun227
left a comment
There was a problem hiding this comment.
This is out of area of expertise but I don't see any immediate issues.
|
@vithikashah001 Could we get your review/approval on this PR so that we can schedule WM parent PR 3014 for the commit queue? |
|
I will review on Vithika's behalf. |
laurenchilutti
requested review from
laurenchilutti
and removed request for
vithikashah001
|
Testing completed successfully on WM parent PR 3014. This PR can be merged. |
|
@laurenchilutti @bensonr @vithikashah001 Could one of you please merge this PR? |
12 participants
Description
The current IAU implementation in FV3 is designed primarily for global applications. When used in regional HAFS configurations, the default behavior is insufficient because it does not read regional increment files or apply region-specific IAU weighting. This limits the applicability of IAU in regional HAFS workflows.
This request introduces several enhancements to support IAU in regional FV3/HAFS configurations without affecting global usage:
Adds support for reading regional increment files during the IAU procedure.
Provides a user-defined scaling factor to adjust the IAU weighting specifically for regional HAFS applications.
Corrects the time-step indexing to ensure consistent and accurate IAU weighting.
All new capabilities are optional and do not modify or interfere with existing global IAU functionality.
Fixes # (issue)
#398