Skip to content

Only 30 members should be used for the early cycle #1588

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.

Sign up for GitHub

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

Jump to bottom
Open
guillaumevernieres opened this issue Mar 31, 2025 · 10 comments · May be fixed by NOAA-EMC/global-workflow#3628 or #1650
Open

Only 30 members should be used for the early cycle #1588

guillaumevernieres opened this issue Mar 31, 2025 · 10 comments · May be fixed by NOAA-EMC/global-workflow#3628 or #1650
Assignees
@AndrewEichmann-NOAA
Labels
gfsv17 soca

Comments

@guillaumevernieres
Copy link
Contributor

From @CatherineThomas-NOAA :

The early cycle EnKF will only consist of 30 members (NMEM_ENS_GFS in config.base). Those 30 members are chosen as a subset of the previous cycle's 80 members on a cyclical basis. 00z uses members 1-30, 06z uses 21-50, 12z uses 41-70, 18z uses 61-80 and 1-10. The shift in members per cycle is defined by NMEM_ENS_GFS_OFFSET in config.base:

# Early-cycle EnKF parameters
export NMEM_ENS_GFS=30
export NMEM_ENS_GFS_OFFSET=20

In the atmospheric EnKF scripts, we first compute the offset for the cycle (mem_offset). From exgdas_enkf_update.sh:

if [ "${RUN}" = "enkfgfs" ]; then  
   NMEM_ENS=${NMEM_ENS_GFS:-30}
   ec_offset=${NMEM_ENS_GFS_OFFSET:-20}
   mem_offset=$((ec_offset * cyc/6))
else
   NMEM_ENS=${NMEM_ENS:-80}
   mem_offset=0
fi

Then we point to the appropriate member when defining the background:

for imem in $(seq 1 $NMEM_ENS); do
   smem=$((imem + mem_offset))
   if (( smem > NMEM_ENS_MAX )); then
      smem=$((smem - NMEM_ENS_MAX))
   fi
   gmemchar="mem"$(printf %03i $smem)
   memchar="mem"$(printf %03i $imem)

This feature was added in this PR. There were a couple bugfixes since then, but it should give you an idea to what's generally needed.
@AndrewEichmann-NOAA AndrewEichmann-NOAA self-assigned this Apr 17, 2025
@AndrewEichmann-NOAA
Copy link
Collaborator

@CatherineThomas-NOAA Is there a set of 80-member low-res ICs I can use to test?

@guillaumevernieres
Copy link
Contributor Author

@CatherineThomas-NOAA Is there a set of 80-member low-res ICs I can use to test?

Not that I know of @AndrewEichmann-NOAA .

@CatherineThomas-NOAA
Copy link
Collaborator

Sorry @AndrewEichmann-NOAA, we have 30 member low res, or 80 member full res. You can fake the 80 members by just copying/linking to the existing members though.

@AndrewEichmann-NOAA
Copy link
Collaborator

@CatherineThomas-NOAA Where are those on Hera?

I forget if there is a reason not to use what's under /scratch1/NCEPDEV/global/glopara/data/ICSDIR/C48mx500/20250327/enkfgdas.20210323 - that seems to have all 80

@guillaumevernieres
Copy link
Contributor Author

@CatherineThomas-NOAA Where are those on Hera?

I forget if there is a reason not to use what's under /scratch1/NCEPDEV/global/glopara/data/ICSDIR/C48mx500/20250327/enkfgdas.20210323 - that seems to have all 80

That should "work" @AndrewEichmann-NOAA .

@CatherineThomas-NOAA
Copy link
Collaborator

@AndrewEichmann-NOAA : I agree, I think those C48 ones would work. In case you want to poke around the higher res ICs, there are some dates for the full res on Hera here:
/scratch1/NCEPDEV/stmp4/Ruiyu.Sun/ICs/RETROs/warm_start_at_03/warm_star_atmic_with_landspinupNspread
and the C384C192 ones are here:
/scratch1/NCEPDEV/da/Travis.J.Elless/data/S2S_ICs

@AndrewEichmann-NOAA
Copy link
Collaborator

AndrewEichmann-NOAA commented Apr 24, 2025 •
edited
Loading

@CatherineThomas-NOAA Does the following experiment cover what's needed?
/apps/rocoto/1.3.6/bin/rocotostat -d /scratch1/NCEPDEV/da/Andrew.Eichmann/fv3gfs/reduced-ens/global-workflow/sorc/gdas.cd/build/gdas/test/gw-ci/../../test/gw-ci/C48mx500_hybAOWCDA/EXPDIR/C48mx500_hybAOWCDA/C48mx500_hybAOWCDA.db -w /scratch1/NCEPDEV/da/Andrew.Eichmann/fv3gfs/reduced-ens/global-workflow/sorc/gdas.cd/build/gdas/test/gw-ci/../../test/gw-ci/C48mx500_hybAOWCDA/EXPDIR/C48mx500_hybAOWCDA/C48mx500_hybAOWCDA.xml

Edits in config.base:

# Cycle to run EnKF  (set to BOTH for both gfs and gdas)
#export EUPD_CYC="gdas"
export EUPD_CYC="BOTH"
#export EUPD_CYC="gfs"

# GFS cycle info
#export INTERVAL_GFS="0" # Frequency of GFS forecast
export INTERVAL_GFS="1" # Frequency of GFS forecast
export SDATE_GFS="2021032500"

# GFS output and frequency
export FHMIN_GFS=0
#export FHMAX_GFS="120"
export FHMAX_GFS="12"

@CatherineThomas-NOAA
Copy link
Collaborator

@AndrewEichmann-NOAA : Sorry for missing this earlier, but INTERVAL_GFS is set in hours, so to run every cycle, this variable should be 6.

@AndrewEichmann-NOAA
Copy link
Collaborator

AndrewEichmann-NOAA commented Apr 29, 2025 •
edited
Loading

So when gfs_ocnanalecen copies increments back to COMROOT - example:
2025-04-29 19:51:48,577 - INFO - file_utils : Copied ocn.recenter.incr.1.nc to /scratch1/NCEPDEV/stmp4/Andrew.Eichmann/COMROOT/C48mx500_hybAOWCDA/enkfgfs.20210326/00/mem001/analysis/ocean/enkfgfs.t00z.ocninc.nc
should it copy to an NMEM_ENS_GFS member ensemble or a full member ensemble (with offset math)?

@CatherineThomas-NOAA
Copy link
Collaborator

@AndrewEichmann-NOAA : The recentering in the early cycle should be performed on and copied to the NMEM_ENS_GFS ensemble, not the full enkfgdas ensemble. Anything produced in the enkfgfs cycle stays in the enkfgfs COMROOT. Did I understand your question right?

This was referenced May 1, 2025
Open
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@AndrewEichmann-NOAA AndrewEichmann-NOAA

Labels
gfsv17 soca
Projects
None yet
Milestone
No milestone
3 participants
@guillaumevernieres @AndrewEichmann-NOAA @CatherineThomas-NOAA