Issues/suggested improvements when running CIME on macOS (or on other systems)

[climbfuji]

This is a list of issues/suggested improvements that I came across when running CIME on macOS.

1. Currently, ncep_post is being copied into the same directory where the UFS model exe is placed, while chgres_cube.exe is not. I would vote for creating symlinks for both in that directory, so that it is more transparent where the executables are coming from (copies don't tell you anything, and users who wish to find out w/o symlinks need to read through the CIME scripts).

2. The macOS build environment --machine XYZ should be called macos instead of homebrew in my opinion.

3. Passing configuration from NCEPLIBS to CIME. NCEPLIBS creates shell scripts to set environment variables that the user can source, copy and adjust as needed. These variables match what users have to set when building the standalone ufs-weather-model using build.sh. It would be great if CIME was looking for the same set of variables. This way it would be doing the same things for generic platforms and for preconfigured platforms (where modules are setting the same variables that the shell script sets).

4. Low-resolution input data. I think it is necessary to provide an option for using low-resolution input data instead of the full GFS analysis. This could be either a switch in the "case create" call (my preference), or automatic depending on the resolution. The data should be the standard GFS 0.5 analysis that is currently available from NOMADS (to be replaced by something else in May 2020). On my Mac, chgres_cube runs for about 20-30 minutes to condense high-resolution data (18GB altogether) down to 100km resolution data (300MB+/-).

5. The following command, issued in a case directory, leads to an error on macOS:

   heinzeller-lt:c96-gfsv15p2-llvm dom.heinzeller$ ./xmlquery --listall
   ERROR: Unexpected elem 'batch_system' for /Users/dom.heinzeller/scratch/mr-weather-app/my_ufs_sandbox-llvm/cime/scripts/c96-gfsv15p2-llvm/env_batch.xml, attrs {'type': 'none'}

6. In the online documentation, some double dashes -- are replaced with long or standard single dashes -, for example the description of the argument --machines.

7. The standard forecast length of 120h is not reasonable for laptop and workstations. We either need to tell the user to change that using xmlchange in the quick start manual and possibly other places (fine with me), or adjust this setting automatically for those generic platforms.

8. The default timestep for C96 is 450s - this is considerably shorter than what the regression tests for the ufs-weather-model use (1200s for GFDL MP based configurations, i.e. for GFSv15p2 and GFSv16beta). The regression tests pass in PROD, REPRO and DEBUG mode with this timestep. Just to doublecheck sure that this small value is really required. Done - current timestep fo 450s is ok.

[jedwards4b]

With Respect to 7 and 8 please see #52 where we have already discussed changing the default namelist options - in particular note that the defaults are documented here https://docs.google.com/document/d/1EKc2mAld5VsrNjTRgqUcTVG1ZcEIkllA-NrAKUs4DWI/edit https://docs.google.com/document/d/1bLbVdWgEIknDQZgTuOZ6IPVEGv5jUgOrCm4GrR96oBU/edit and that we have already discussed and rejected changing the timestep length.

[climbfuji]

Thanks for sharing those documents. Consider 8 as done, I just wanted to confirm that this was intended. I didn't see anything discussing the forecast length there. Should we just tell the user to change it before executing case.submit?

[uturuncoglu]

@climbfuji (1) is done and will be available in next push

[climbfuji]

Thanks! pre and model run fine, but I am afraid the post script is incompatible with macOS. So far I found four parts in the auto-generated .case.gfs_post script that do not work. It will take me a long time to write this down, I am wondering if there is a better way. Maybe I could share my screen with you on google hangout?

[uturuncoglu]

Sure just send me the link and we could look at together.

[climbfuji]

Folks, any updates on making the post script macOS compliant? The ncep_post crash has been fixed. Thanks ...

[jedwards4b]

@climbfuji my understanding is that this is fixed, can we close this one?

[climbfuji]

Yes, this is all good!