ESMValGroup / ESMValTool

ESMValTool: A community diagnostic and performance metrics tool for routine evaluation of Earth system models in CMIP
https://www.esmvaltool.org
Apache License 2.0
217 stars 127 forks source link

Final test for v2.0.0 release #1697

Closed mattiarighi closed 4 years ago

mattiarighi commented 4 years ago

A checklist of the ESMValTool recipes to be tested before the release

And here the same for the cmorizers:

Should we also test the download scripts?

mattiarighi commented 4 years ago

@jvegasbsc how do you run the cmorizers with the new interface?

valeriupredoi commented 4 years ago

like this @mattiarighi (not sure about tcsh, this is for bash only though):

if [ $"day" = "Saturday" ]; then
    cmorizers="Mattia shouldn't work"
else
    cmorizers="Broken, see below"
fi

and the broken bit is because:

(esmvaltool_users) [valeriu@jasmin-sci1 ~]$ cmorize_obs -o WOA --config-file esmvaltool_var_test/config-user.yml 
Traceback (most recent call last):
  File "/home/users/valeriu/anaconda3R/envs/esmvaltool_users/bin/cmorize_obs", line 11, in <module>
    load_entry_point('ESMValTool', 'console_scripts', 'cmorize_obs')()
  File "/home/users/valeriu/esmvaltool_users/esmvaltool/cmorizers/obs/cmorize_obs.py", line 166, in main
    config_user = read_config_user_file(config_file, 'cmorize_obs')
TypeError: read_config_user_file() missing 1 required positional argument: 'options'

@jvegasbsc you need to make that arg optional for console scripts :beer:

jvegreg commented 4 years ago

I am on it, but in the meanwhile you can just past there an empty dict and it should work

valeriupredoi commented 4 years ago

cheers @jvegasbsc - why are we on GitHub on a Saturday? :beach_umbrella:

mattiarighi commented 4 years ago

We are getting there. @bouweandela @valeriupredoi @jvegasbsc it would be good if you could test the recipes assigned to you, unfortunately I missed the data to do this myself.

@earnone @jhardenberg please fix the errors related to your recipes, @katjaweigel can also help with this.

@tomaslovato there are two of your cmorizers which are not working, it would be great if you could fix them.

I still have to test recipe_collins13ipcc.yml, but it requires lots of memory and the DKRZ job scheduler was down in the last few days. I will try again today.

earnone commented 4 years ago

@mattiarighi great. I understood #1752 by @katjaweigel solved the issues with recipe_hyint.yml (#1716), recipe_hyint_extreme_events.yml (#1711) and recipe_extreme_events.yml (#1718). So we are left with recipe_rainfarm.yml (#1715) @jhardenberg . OK?

mattiarighi commented 4 years ago

Correct.

katjaweigel commented 4 years ago

@earnone currently I'm just testing recipe_hyint.yml. Yesterday I had a version which run, but now something went wrong again when I tried to sort my changes into a new branch. Hope I have at least recipe_hyint.yml running again, soon.

jvegreg commented 4 years ago

Regarding my recipes, recipe_seaice_feedback already tested and recipe_seaice_drift is ongoing. I had to cmorize the NSIDC data, as we only have ERA5 and ERA-Interim in the Tier3 of the common data pool. This is intended, @valeriupredoi ? Should I put the data I cmorized there?

jvegreg commented 4 years ago

recipe_seaice_drift is ongoing

Finished ok

valeriupredoi commented 4 years ago

I will spend a good bit of next week making sure all my autoassess shtuff still works fine and is ready for the big launch :rocket: Dealing with some other annoyances, ahem, interesting phenomena in the meantime :grin:

jvegreg commented 4 years ago

@bouweandela, I tried to run the hydrology recipes but I can not find where to get the shapefiles that they require. It is nor in the recipe nor in the documentation. Is there a reason why you are not telling where to get them?

bouweandela commented 4 years ago

@jvegasbsc In principle, the recipes are intended to work with any shapefile describing a river catchment. We recently discussed adding a link to the place where we downloaded them from to the recipe documentation, but this hasn't been done yet. Maybe @nielsdrost can say more about this?

Specifically, copies of the shapefiles mentioned in the recipes can be found here: https://github.com/eWaterCycle/recipes_auxiliary_datasets, but they are just examples.

nielsdrost commented 4 years ago

@jvegasbsc In principle, the recipes are intended to work with any shapefile describing a river catchment. We recently discussed adding a link to the place where we downloaded them from to the recipe documentation, but this hasn't been done yet. Maybe @nielsdrost can say more about this?

Specifically, copies of the shapefiles mentioned in the recipes can be found here: https://github.com/eWaterCycle/recipes_auxiliary_datasets, but they are just examples.

The hydrology recipes should in principle work with any shape. Usually these will come from HydroSHEDS (https://www.hydrosheds.org/), or some custom shape depending on the use-case. We though about including a few example shapes, but could not figure out how to best do this in ESMValTool. Committing them to the repo did not seem to be the best idea, but I also do not really regard them as a "dataset" worth publishing separately. Something for a future ESMValTool workshop discussion, I think.

In the mean time, shall we add a hint on how to get an example shapefile to the recipes?

bouweandela commented 4 years ago

In the mean time, shall we add a hint on how to get an example shapefile to the recipes?

Yes, I think it would be really helpful to put a link to HydroSHEDS in https://github.com/ESMValGroup/ESMValTool/blob/master/doc/sphinx/source/recipes/recipe_hydrology.rst. Maybe we could replace the names of shapefiles in the recipes so their names match a shapefile from that site?

nielsdrost commented 4 years ago

In the mean time, shall we add a hint on how to get an example shapefile to the recipes?

Yes, I think it would be really helpful to put a link to HydroSHEDS in https://github.com/ESMValGroup/ESMValTool/blob/master/doc/sphinx/source/recipes/recipe_hydrology.rst. Maybe we could replace the names of shapefiles in the recipes so their names match a shapefile from that site?

Created a separate issue (#1762)

valeriupredoi commented 4 years ago

tested the ones that had my name against them plus the two validation ones plus the preprocessor derive (note for the last one no OImon data for HadGEM2-A on Jasmin/BADC neither in output1 nor output2, maybe we should use a slightly less obscure dataset?) :beer:

bouweandela commented 4 years ago

preprocessor derive (note for the last one no OImon data for HadGEM2-A on Jasmin/BADC neither in output1 nor output2, maybe we should use a slightly less obscure dataset?)

I changed the mip of the last diagnostic in #1768, so now at least it runs, but just realized that it probably was the wrong way to fix it, because the description is Test sispeed, so probably the variable name was wrong too. A more likely test would be

  diag8:
    description: Test sispeed
    variables:
      sipeed:
        project: CMIP5
        mip: day
        exp: historical
        start_year: 1985
        end_year: 1986
        ensemble: r1i1p1
        derive: true
        force_derivation: false
        additional_datasets:
          - {dataset: MPI-ESM-MR}
    scripts: null

@jvegasbsc I think you originally added this. Is it OK to leave it as is? If not, can you fix it?

jvegreg commented 4 years ago

@jvegasbsc I think you originally added this. Is it OK to leave it as is? If not, can you fix it?

Fixed, waiting for the test to finish on Jasmin...

mattiarighi commented 4 years ago

We are almost there:

valeriupredoi commented 4 years ago

yes - done, forgot to check the box :grin:

bouweandela commented 4 years ago

it looks like we can't fix #1742 without a new ESMValCore release, is there a workaround?

We could try removing the multi model statistics from the recipes as a workaround, but it looks like @ledm is still working on these recipes in #1331 and #1621, so my impression is that this is not ready for the current release.

mattiarighi commented 4 years ago

That's bad, because it is in the Part II paper. I would suggest to at least remove the multimodel stats if the recipe is running.