Create analysis files for early-cycle EnKF by default

[TravisElless-NOAA]

Description
The upcoming GEFS implementation plans to use analysis files from the early-cycle EnKF to cold start the EPS. This PR allows the early-cycle EnKF members to produce analysis files as the default option. Running in this mode will break early-cycle EnKF forecast functionality - running with this new config.base option set to "NO" and/or a future PR will be needed to restore the early-cycle EnKF forecast job. These changes do not impact the ability for the workflow to successfully cycle.

Type of change

• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

How Has This Been Tested?

• Cycled test on Orion
• comrot: /work/noaa/stmp/telless/comrot/test_changes_for_default_enkf_anal
• expdir: /work2/noaa/da/telless/exp/test_changes_for_default_enkf_anal/

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• New and existing tests pass with my changes

[aerorahul]

The changes in this PR are good.
I have just one comment, if you could share your thoughts.

[aerorahul]

This is a picky comment.
Can we instead define this as DO_CALC_INCREMENT_ENKF_GFS.
Here are my reasons:

1. The default is DO_CALC_INCREMENT
2. If doing this for EnKF regardless of cycle, it could be extended to DO_CALC_INCREMENT_ENKF, similar to FHOUT_ENKF.
3. If doing this for EnKF and only for the GFS, this could be extended to DO_CALC_INCREMENT_ENKF_GFS, similar to FHMAX_ENKF_GFS.

Other than that, the changes in this PR are fine.

Your thoughts?

[XianwuXue-NOAA]

I agree to use DO_CALC_INCREMENT_ENKF_GFS to be consistent with other variables.

[TravisElless-NOAA]

This logic makes sense. A commit changing this variable name will be forthcoming.

[XianwuXue-NOAA]

I have tested this PR and new file (gfs.t12z.atmanl.nc and gfs.t12z.ratmanl.nc) were generated in enkfgfs.{PDY}/{cycle}/mem{001..080}/atmos/, and gfs.t12z.ratminc.nc was not generated (I think this is expected ?).

So I will use enkfgfs.{PDY}/{cycle}/mem{001..080}/atmos/gfs.t12z.atmanl.nc to create gfs_data.${tile}.nc for ensemble members and gfs.{PDY}/{cycle}/atmos/gfs.t12z.atmanl.nc to chgres to create gfs_data.${tile}.nc for c00. use gfs.{PDY}/{cycle}/atmos/gfs.t${cyc}z.sfcanl.nc to generate sfc_data.${tile}.nc for c00 and ens members for the cold start of fcst. Please correct me if I am wrong.

[aerorahul]

I have tested this PR and new file (gfs.t12z.atmanl.nc and gfs.t12z.ratmanl.nc) were generated in enkfgfs.{PDY}/{cycle}/mem{001..080}/atmos/, and gfs.t12z.ratminc.nc was not generated (I think this is expected ?).

So I will use enkfgfs.{PDY}/{cycle}/mem{001..080}/atmos/gfs.t12z.atmanl.nc to create gfs_data.${tile}.nc for ensemble members and gfs.{PDY}/{cycle}/atmos/gfs.t12z.atmanl.nc to chgres to create gfs_data.${tile}.nc for c00. use gfs.{PDY}/{cycle}/atmos/gfs.t${cyc}z.sfcanl.nc to generate sfc_data.${tile}.nc for c00 and ens members for the cold start of fcst. Please correct me if I am wrong.

@XianwuXue-NOAA
If the gfs.tHHz.ratmanl.nc file is generated in the early cycle EnKF, then you could use that as the inputs to create gfs_data.${tile}.nc for the ensemble members.
@CatherineThomas-NOAA and @TravisElless-NOAA could you please verify that the recentering is actually being done correctly.
This should be the last step the GFS will do to prepare atmospheric initial conditions for GEFS.

[XianwuXue-NOAA]

I have tested this PR and new file (gfs.t12z.atmanl.nc and gfs.t12z.ratmanl.nc) were generated in enkfgfs.{PDY}/{cycle}/mem{001..080}/atmos/, and gfs.t12z.ratminc.nc was not generated (I think this is expected ?).
So I will use enkfgfs.{PDY}/{cycle}/mem{001..080}/atmos/gfs.t12z.atmanl.nc to create gfs_data.${tile}.nc for ensemble members and gfs.{PDY}/{cycle}/atmos/gfs.t12z.atmanl.nc to chgres to create gfs_data.${tile}.nc for c00. use gfs.{PDY}/{cycle}/atmos/gfs.t${cyc}z.sfcanl.nc to generate sfc_data.${tile}.nc for c00 and ens members for the cold start of fcst. Please correct me if I am wrong.

@XianwuXue-NOAA If the gfs.tHHz.ratmanl.nc file is generated in the early cycle EnKF, then you could use that as the inputs to create gfs_data.${tile}.nc for the ensemble members. @CatherineThomas-NOAA and @TravisElless-NOAA could you please verify that the recentering is actually being done correctly. This should be the last step the GFS will do to prepare atmospheric initial conditions for GEFS.

Thanks. I will do that @aerorahul

[aerorahul]

Changes look good.
Awaiting review from @CatherineThomas-NOAA

[CatherineThomas-NOAA]

The changes look good to me, however, the review did make me realize that we will not be applying INCREMENTS_TO_ZERO to the analysis itself (see my code comment for exgdas_enkf_update.sh). It’s not needed in the current case, but we should think about this part of the design a bit more. Approved.

[WalterKolczynski-NOAA]

There are a couple of conflicts that need to be resolved now due to the removal of some nemsio related code. Then this should be ready to merge now that Cathy has approved.

[TravisElless-NOAA]

Conflicts should now be resolved

[WalterKolczynski-NOAA]

Good except the permissions are now being changed on a couple of the scripts.

[WalterKolczynski-NOAA]

@TravisElless-NOAA did you use the GitHub editor to fix the conflicts or a real clone? We've seen this happen a couple times and we're trying to troubleshoot why.

[TravisElless-NOAA]

I used the GitHub editor to make the changes. Is there an easy way to change these file permissions?

[WalterKolczynski-NOAA]

I used the GitHub editor to make the changes. Is there an easy way to change these file permissions?

I think you have to do it locally somewhere and push it.

[TravisElless-NOAA]

Permissions should now be back to normal