Test slim at lower resolution(s)
Closed this issue · 13 comments
Testing this far has used the f19 resolution. Generate slim_fsurdat file(s) at lower resolution(s) and test.
@marysa I wonder whether you have a simple tool for generating slim_fsurdat files and whether I could use that to work on this issue.
@ekluzek I think I should try one of our existing resolutions, e.g. 10x10, using the existing domain file (with mct) or mesh file (with nuopc) rather than generating new domain or mesh files. If you think that we will repeat this testing with nuopc, then I propose that this issue should wait and the testing be done once.
@slevisconsulting yes try fv10x15 and fv4x5. The domain files (or eventually mesh files for NUOPC) are part of the CESM system, so you won't need to worry about that part. The only part you'll need to do is to create mml_surdat files and see if it works. When you setup a case the proper domain files will be pointed to in the case. You can check for them with "./xmlquery -p DOMAIN".
I have written a matlab script to generate dummy mml_surdat files, e.g. slim_unrealistic4x5.nc and slim_unrealistic10x15.nc. I will try running simulations pointing to these files. If they work, then I could use the same matlab script to address #36.
ERP_D_Ld60.f45_g37.I1850Slim50RsGs.cheyenne_intel.clm-realistic_fromCLM5_1850Monthly
used mml_surdat = '/glade/work/slevis/git_slim/SLIM_files/generated_by_slevis/slim_unrealistic4x5.nc'
and passed.
./create_test ERP_D_Ld60.f10_f10_mg37.I1850Slim50RsGs.cheyenne_intel.clm-realistic_fromCLM5_1850Monthly
used mml_surdat = '/glade/work/slevis/git_slim/SLIM_files/generated_by_slevis/slim_unrealistic10x15.nc'
and passed.
@ekluzek if you agree, I will close this issue as complete.
This is great news!
Can you easily also try a f4x5 case? It also would be really good to put these files into inputdata and add tests for them in the test list. These low resolution tests are going to be really cheap and fast, so it would benefit our testing to have some low resolution tests that are done. It actually might be good to shift a lot of the testing over to low resolutions like we do with CTSM because it's so much cheaper.
Hi @slevisconsulting - sounds like you already have a script. Sorry for the delay on my end - I was out sick most of last week. Let me know if you still need/want what I've got - I had something not elegant in python but it can have issues with coastal cells; if the ocean had a nan rather than a reasonable value, that can end up in the regridded land files.
Can you easily also try a f4x5 case? It also would be really good to put these files into inputdata and add tests for them in the test list. These low resolution tests are going to be really cheap and fast, so it would benefit our testing to have some low resolution tests that are done. It actually might be good to shift a lot of the testing over to low resolutions like we do with CTSM because it's so much cheaper.
@ekluzek I ran this f45 test and it passed:
ERP_D_Ld60.f45_g37.I1850Slim50RsGs.cheyenne_intel.clm-realistic_fromCLM5_1850Monthly
using mml_surdat = '/glade/work/slevis/git_slim/SLIM_files/generated_by_slevis/slim_unrealistic4x5.nc'
- I can add the two new mml_surdat files to inputdata. I assume you mean with rimport, right?
- I like the idea of shifting much of the testing to the lower resolutions to save time. Do you prefer to review the testlist file together or should I go through it myself?
...actually, I do not have write permission in /glade/p/cesmdata/cseg/inputdata/lnd/slim/surdat
OK, I just gave you permissions on cheyenne and izumi to add to the lnd/slim directory and subdirectories. And yes we should add these files to the build-namelist namelist_defaults and in with rimport.
For now I'd just add a few new tests for both f45 and f10. That could take up several tests if you do several compilers and both cheyenne and izumi. We can't run SOM for these resolutions, but I think you could do both F compsets and I compsets for this. And technically you could do a few different configuration types. But, we shouldn't add too many more, just a few as the next step will be to switch a lot of the higher resolution tests for lower resolutions.
I think it would be good for us to collaborate together and talk through changing the test list to have more lower resolution tests. Thats one of the things where it's good to work on it together.
I looked at the CTSM test list and the other low resolution we use there is T31. T31 used to be "the Paleo" resolution, but I don't think it is anymore.
There are some other unstructured grids that I don't think make sense for SLIM. But, I do wonder if regional or single point would be useful for SLIM though?
I also like the idea of just trying different resolutions to see if we can break SLIM. It's just good to try crazy stuff out to see if you can break it. If you find something that breaks it -- well then you know about limitations; And if you don't break it you know it's robust in that fashion. So possibly we should try some of these unstructured grids just so we know if they'll work or not.
I copied the two new mml_surdat files to /glade/p/cesmdata/cseg/inputdata/lnd/slim/surdat.
First line of business is our naming convention. For now I named them:
slim_unrealistic_f10_20230131_from_realistic_f19_20190110.nc
slim_unrealistic_f45_20230131_from_realistic_f19_20190110.nc
Our fsurdat naming approach is not entirely relevant to SLIM but here's an example:
surfdata_10x15_hist_78pfts_CMIP6_1850_c230127.nc
Preferred names of the new files:
slim_realistic_f19_20190110_cutout_to_f10_c20230131.nc
slim_realistic_f19_20190110_cutout_to_f45_c20230131.nc
Put in the same PR as short restarts (#68) and add new short restart tests at the low resolutions (several compilers, izumi and cheyenne).
I ran the next two commands to put the new files on the repository:
./rimport -file lnd/slim/surdat/slim_realistic_f19_20190110_cutout_to_f10_c20230131.nc
./rimport -file lnd/slim/surdat/slim_realistic_f19_20190110_cutout_to_f45_c20230131.nc