Option to download fix files from web to support larger variety of users

[LarissaReames-NOAA]

Make sure to note that global_chgres and gridgen_sfc (used prior to chgres_cube) expect different fix files. global_chgres expects grb files on the set cubed sphere resolutions, while gridgen_sfc expects the fixed fields in netcdf format.

[MatthewPyle-NOAA]

Do you have a thought as to where they might be staged?

[JacobCarley-NOAA]

That's a good question. We were thinking maybe the UFS community page?

@llpcarson @jwolff-ncar Do either of you know it would be possible to put on the UFS page?

[jwolff-ncar]

According to the latest from the UFS Release Team, sounds like this issue will be solved before the official global release so we should stay tuned for that.

-

Host site for fix files and sample input and output files for community to test and compare against - action item for EMC - aim to have something lined up by Nov 15th

  Create a list of which fix files will be released
  -

  Create fix files for supported configurations -- C96, C192, C384,
  C768 with 64 vertical levels
  -

  Select tests case(s) and generate reference input and output files

On Tue, Jul 16, 2019 at 2:50 PM JacobCarley-NOAA notifications@github.com wrote:

That's a good question. We were thinking maybe the UFS community page?

@llpcarson https://github.com/llpcarson @jwolff-ncar https://github.com/jwolff-ncar Do either of you know it would be possible to put on the UFS page?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NOAA-EMC/regional_workflow/issues/10?email_source=notifications&email_token=AFN5ZDAKCHQ2GJGFBQZWYE3P7YX75A5CNFSM4IDX6BZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2CDI6I#issuecomment-511980665, or mute the thread https://github.com/notifications/unsubscribe-auth/AFN5ZDDUKOXNQZQLNTIGNTTP7YX75ANCNFSM4IDX6BZQ .

--

Jamie K. Wolff National Center for Atmospheric Research (NCAR) Research Applications Laboratory (RAL) Phone: 303.497.2812 Email: jwolff@ucar.edu

My working day may not be your working day. Please do not feel obliged to reply to this email outside of your normal working hours.

[jwolff-ncar]

Relevant notes from preparation for the global release:

Kate Friedman: I know of the following on the EMC ftp site:

FIX files: https://ftp.emc.ncep.noaa.gov/EIB/UFS/global/fix/fix_* ...which are broken into sub-groups:

fix_am fix_chem fix_fv3 fix_fv3_gmted2010 fix_gldas fix_orog fix_sfc_climo fix_verif This is the full collection of FV3GFS fix files as of November 12th. Most likely overkill. Do we need a paired down collection?

C96 canned case tarball (originally made available for NASA folks) https://ftp.emc.ncep.noaa.gov/EIB/UFS/RT/fv3_gfdlmprad.tar

In addition, since then the tar ball was unpacked: https://ftp.emc.ncep.noaa.gov/EIB/UFS/RT/fv3_gfdlmprad/

The tarball itself is still there under the ../RT folder alongside the unpacked folder.

[jwolff-ncar]

The ftp site in the previous comment no longer exists. Need to track down where the ufs-release will point users to these fix files.

[jwolff-ncar]

Ok, the link wasn't completely wrong - just slightly different.

Here is where the fix files for the release are located: https://ftp.emc.ncep.noaa.gov/EIB/UFS/global/fix/.

The full set of files for the release are at: https://ftp.emc.ncep.noaa.gov/EIB/UFS/

[JacobCarley-NOAA]

With the files being hosted on the FTPserver noted in @jwolff-ncar 's update on Feb 6, should we close this issue?

[llpcarson]

Jeff was going to confirm with Kate Friedman that it's OK for the regional-release to use the same EMC FTP server, if so, then this can be closed.

On Wed, Mar 11, 2020 at 2:12 PM JacobCarley-NOAA notifications@github.com wrote:

With the files being hosted on the FTPserver noted in @jwolff-ncar https://github.com/jwolff-ncar 's update on Feb 6, should we close this issue?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/NOAA-EMC/regional_workflow/issues/10#issuecomment-597843761, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB2OWIT2AWYLLQ3FG5KU3T3RG7WCPANCNFSM4IDX6BZQ .

[jwolff-ncar]

Would it also be helpful if we establish a list of files we need to make available via this FTP server for the SRW app release? I started a Google Doc if that's useful (https://docs.google.com/spreadsheets/d/1c89VFGPd11v0K8Q4JAgpNTIYq93NRw_r2wlN2LgodqI/edit?usp=sharing). If others think this is not necessary, just let me know and we won't worry about it.

@JeffBeck-NOAA Let us know what Kate says and what the protocol will be for including new files in that location if approved.

[jwolff-ncar]

Thumbs up from Kate to add SAR files to: https://ftp.emc.ncep.noaa.gov/EIB/UFS/

@BenjaminBlake-NOAA is willing to transfer fix files for the SAR to rzdm when we are ready. Thanks!

[jwolff-ncar]

From @mkavulich: Here is the info I compiled about the necessary "fix" files for the current version of the ufs-srweather-app. I tried to include a description of what was in the files if I could determine it, but for some I was at a complete loss (so if anyone has info I'd appreciate it!).

https://docs.google.com/spreadsheets/d/1A_xJ604fMJDiPH_Uqs3Bs-AU5XquAqFMitDkcq_OCY8/edit?usp=sharing

The workflow looks for these files according to two paths set in ufs-srweather-app/regional_workflow/ush/setup.sh. SFC_CLIMO_INPUT_DIR defines the location of a number of fixed climatology fields in netCDF format. Most of the rest are determined by the FIXgsm variable. One weird property about the workflow is that for the files used by make_orog (there are three files), they currently must reside in a directory named "fix_orog" that is one directory above the FIXgsm location. This would be fairly easy to fix so that the location of these files is also more flexibly determined in the setup.sh file, but I'm not sure if there is some legacy reason I don't know about that the directory structure is set that way.

[jwolff-ncar]

From @BenjaminBlake-NOAA: I think we should remove the fix_orog directory to make the workflow more flexible. I don't see a reason to keep it around.

[jwolff-ncar]

@mkavulich I think you had a PR to remove the fix_orog dir requirements. Is that complete now? @BenjaminBlake-NOAA Would you be willing/able to put the files on the https://ftp.emc.ncep.noaa.gov/EIB/UFS/?

[BenjaminBlake-NOAA]

@jwolff-ncar Sure I can do that! Do we want to include all the files listed in the spreadsheet? Also, is putting them all in one directory ok and if so what should it be called?

[jwolff-ncar]

@BenjaminBlake-NOAA Thanks! Let's create a top-level directory called "fv3-lam" that we can put the files under. I propose we use a similar structure to where the files are currently sitting on hera: /scratch1/NCEPDEV/global/glopara/fix/fix_am Also under there we can have fix_orog/ and fix_co2_proj In addition, let's add a sfc_climo/ to put those files under.

Does this all make sense?

fv3-lam/ |-> fix/ |-> fix_am/ |-> fix_orog/ |-> fix_co2_proj/ |-> sfc_climo/ |-> simple_test_case/ |-> etc...

@mkavulich Feel free to chime in with other ideas!

[jwolff-ncar]

Shoot, my indentation in my previous message with the directory layout did not come through.

[jwolff-ncar]

Top-level fv3-lam/

under fv3-lam/, fix/ simple_test_case/

under fix/, fix_am/

under fix_am/, fix_orog/ fix_co2_proj/ sfc_climo/

[BenjaminBlake-NOAA]

Sounds good! That directory structure works for me. So in the spreadsheet the files that are listed under FIXgsm can just go directly into fix_am?

[jwolff-ncar]

That would be my suggestion, but I am open to other ideas. Thanks!

[BenjaminBlake-NOAA]

I think that's fine! I'll let you know when the files have been transferred.

[BenjaminBlake-NOAA]

I tried to copy all the files to that directory but got a permission denied error. I guess I'm not allowed to copy files to that EIB/UFS directory? Maybe the quickest solution would be for me to find someone else in EIB to copy the directory I set up on Hera. I'll email Arun and see what he thinks.

[jwolff-ncar]

Thanks for following up and keep us posted!

[BenjaminBlake-NOAA]

Sure! Arun recommends we put the directory here if that is ok: https://ftp.emc.ncep.noaa.gov/static_files/

They are in the process of moving files to that location and we should be able to get them moved there early next week.

[jwolff-ncar]

Will this include the global static files as well? It would be nice to keep them co-located since it uses the same weather model. But if that is not an option, we can proceed with this plan. (Maybe it isn't a huge deal, though.) Thanks!

[BenjaminBlake-NOAA]

I believe Arun's idea is to put all of the static files in one place, so the global static files will be included too!

[BenjaminBlake-NOAA]

Kate has put the files here for now: ftp://ftp.emc.ncep.noaa.gov/static_files/public/UFS/SRW/fv3-lam/ If possible, Arun would prefer to avoid duplication of files with the global configuration. Does it make sense to have one directory/location for the global and regional files or do we want to keep a separate regional directory? Our proposed directory structure is different from how the global does it. If we have one location, we would need to add any regional files that aren't already part of the global files.

[jwolff-ncar]

I'm not quite sure how to handle all of this. I am not familiar with the fix files needed for the global vs lam. It adds complexity to the workflow on accessing/staging the necessary fix files if we have them in multiple subdirectories. Not a show stopper, but we should determine whether we want to deal with that very soon. I am guessing this potentially combined directory will not be what is used for the MRW app v1.1 release, regardless. My worry would be if someone changed a fix file that is used for both without properly testing it for both applications it could lead to problems. Not likely, but need to think about the fact that we would be sharing files and would need to carefully test.

Somewhat related question...We also want to stage some input data for the workflow end-to-end WE2E and GST tests. I would like to have this in a similar location. However, these fix files are now under a "stat_files" directory so I am not sure if that is appropriate. For the MRW app the use: ftp://ftp.emc.ncep.noaa.gov/EIB/UFS/inputdata/. This was originally where we were going to put our static data too (to be consistent with them (ftp://ftp.emc.ncep.noaa.gov/EIB/UFS/global/) but that has since changed with Arun's suggestion. Suggestions on where to put the model data for initialization now?

[BenjaminBlake-NOAA]

Hi Jamie, I agree that we should decide how to handle this soon. I share your concern that changing a fix file that is used by both systems without proper testing could potentially lead to issues. I am fine with having separate directories for now, but perhaps we should bring Arun and other relevant folks into the conversation to help make that decision.

For the input data, could we create a directory here? ftp://ftp.emc.ncep.noaa.gov/static_files/public/UFS/SRW/fv3-lam We already added an empty simple_test_case directory. It sounds like that EIB/UFS location is going away soon.

[JeffBeck-NOAA]

@BenjaminBlake-NOAA Would you be able to copy the CCN_ACTIVATE.BIN file needed for Thompson MP into the fv3-lam directory on the FTP server? Thanks!

[BenjaminBlake-NOAA]

@JeffBeck-NOAA where is the file currently located (on Hera if possible)? I don't think I have permission to copy the file myself but I can ask Kate to do it when she gets a chance, she copied the files last time

[JeffBeck-NOAA]

@BenjaminBlake-NOAA It's on Hera here: /scratch1/NCEPDEV/global/glopara/fix/fix_am Thanks!

[BenjaminBlake-NOAA]

@JeffBeck-NOAA the file has been added!

[JeffBeck-NOAA]

Thanks, @BenjaminBlake-NOAA!

[BenjaminBlake-NOAA]

All - The fix files have been moved to the following location: https://ftp.emc.ncep.noaa.gov/EIB/UFS/SRW/v1p0/

Can we close this issue or do we want to leave it open for now?

[jwolff-ncar]

Excellent! I am fine with closing now. Thanks!

[BenjaminBlake-NOAA]

Ok! I can do that now.

[JeffBeck-NOAA]

Thanks for your work coordinating this effort, @BenjaminBlake-NOAA!