I wrote in HPSCTerrSys/eCLM_static-file-generator#22:
I use here years instead of the faulty iyear, so it's consistent with near-future changeset.
I don't remember what I meant precisely, but at the very least a minor refactoring where i* variables are used for counters is in order.
In my experience,
./extract_ERA5_meteocloud.sh years=2017 months=07 worked
./extract_ERA5_meteocloud.sh years=2017 months=7 failed
./extract_ERA5_meteocloud.sh iyear=2017 imonth=7 ihour=(00 01) failed
./extract_ERA5_meteocloud.sh iyear=2017 imonth=7 ihour=(00 01) failed
- There is no
days, but maybe this was intentional
- Check for
meteocloud_${year}_${month}.{grb,nc} at start of script is nice to have (to catch unnecessary recomputation) but optional
I wrote in HPSCTerrSys/eCLM_static-file-generator#22:
I don't remember what I meant precisely, but at the very least a minor refactoring where
i*variables are used for counters is in order.In my experience,
./extract_ERA5_meteocloud.sh years=2017 months=07worked./extract_ERA5_meteocloud.sh years=2017 months=7failed./extract_ERA5_meteocloud.sh iyear=2017 imonth=7 ihour=(00 01)failed./extract_ERA5_meteocloud.sh iyear=2017 imonth=7 ihour=(00 01)faileddays, but maybe this was intentionalmeteocloud_${year}_${month}.{grb,nc}at start of script is nice to have (to catch unnecessary recomputation) but optional