Closed mattiarighi closed 4 years ago
@jvegasbsc how do you run the cmorizers with the new interface?
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:
I am on it, but in the meanwhile you can just past there an empty dict and it should work
cheers @jvegasbsc - why are we on GitHub on a Saturday? :beach_umbrella:
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.
@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?
Correct.
@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.
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?
recipe_seaice_drift is ongoing
Finished ok
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:
@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?
@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.
@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?
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?
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)
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:
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?
@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...
We are almost there:
recipe_autoassess_radiation_rms_cfMon_all.yml
?yes - done, forgot to check the box :grin:
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.
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.
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?