-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG/ISSUE] dry run for data download w/ 13.0.1 not recognizing files are missing past day 2 of month for MERRA-2 global and GEOS-FP nested NA #686
Comments
Thanks @hmhorow. Yes, I can see that the 0.25 x 0.3125 dry run is only picking up a day of data:
I think it might be related to this commit in HEMCO, which was added in 13.0.1. geoschem/HEMCO@1506fb7. This is related to feature request #667. Long story short, we introduced a new HEMCO flag (
We needed In any case, try changing the |
Thanks so much for your help!! I will try this out ASAP and get back to you. |
I replaced EFY with ECY for all of the met fields (but not the restart file, I kept that EFY).
I tried for both the MERRA-2 4x5 and GEOS-FP 0.25x0.3125 dry runs that I mentioned previously. Both of them seg faulted due to 'invalid memory reference'. here are the error files: For reference this is the first error, line 344 of hco_driver_mod.F90 starts here: I'm confident the only thing I changed was the HEMCO_Config.rc file, I did not change input.geos or the run scripts that I had previously sent along. But I don't know if there's anything wonky happening on our campus cluster. |
Thanks @hmhorow. I just spun up a cloud instance to do a dry-run and confirmed that ECF is not the proper setting. It should be ECY (use exact year, read continuously). If I grep for the A1 met field in my dry-run logfile, I now get:
so as you can see, ECY is now picking up all the files for the month of my dry-run. I think we'll have to issue a patch version 13.0.2 ASAP to fix this. Thanks for bringing this to our attention! |
After consulting with the GCST, ECY might not be correct, as it will keep cycling to the closest available, which is not what we want. I think we have to add a new flag in HEMCO to cover the met fields. EFY was correct but then the behavior changed in 13.0.1. Thanks for your patience, we'll fix it soon! |
Thanks Bob! |
Hi @hmhorow. For now I have a fix in the bugfix/bmy/TimeCycleEFYO branch. You can get it with:
or if you want to get that into an existing code directory you can do:
I probably won't have time to push version 13.0.2 tonight but I'll do it 1st thing Monday. This will also give me time to run some integration tests. Long story short:
|
Thank you so much @yantosca! I will try out updating from my existing 13.0.1 code directory. |
FYI I tried the bugfix/bmy/TimeCycleEFYO branch, made a new run directory, did a dry run with no changes to anything except input.geos to set the time period, and it now lists all the files needed for the entire time, which also successfully downloaded based on the log file from that dry run. thanks! |
Thanks @hmhorow. I am fixing a minor issue that was uncovered during the integration tests and should be able to push 13.0.2 later today. Thank you for reporting this issue! Good catch! |
Also note, the integration tests revealed the need to modify this statement in the run directory generation file # Sample restarts for several simulations do not contain all species. For those
# simulations, print a warning and change the time cycle option in HEMCO config
# so that we do not force an error if not found (i.e. EFYO --> EY)
if [[ "x${sim_extra_option}" == "xaciduptake" ||
"x${sim_extra_option}" == "xmarinePOA" ||
"x${sim_extra_option}" == "xcomplexSOA_SVPOA" ||
"x${sim_extra_option}" == "xAPM" ||
"x${sim_name}" == "xPOPs" ||
"x${sim_name}" == "xtagCH4" ||
"x${sim_name}" == "xtagO3" ]]; then
old="SpeciesRst_?ALL? \$YYYY/\$MM/\$DD/\$HH EFYO"
new="SpeciesRst_?ALL? \$YYYY/\$MM/\$DD/\$HH EY "
sed_ie "s|${old}|${new}|" HEMCO_Config.rc
printf "\n -- The sample restart provided for this simulation may not"
printf "\n contain all species defined in this simulation. Missing"
printf "\n species will be assigned default background concentrations."
printf "\n Check your GEOS-Chem log file for details. As always, it"
printf "\n is recommended that you spin up your simulation to ensure"
printf "\n proper initial conditions.\n"
fi I will push this fix today and run a new set of integration tests. Then I'll release 13.0.2. |
This issue is now fixed and included in GEOS-Chem 13.0.2. Please update to this version when it is convenient. I will close out this issue for now but please keep us posted of any other problems you encounter. |
Description of the problem
I cloned the GEOS-Chem code for version 13.0.1. I created two different run directories, one for GEOS-FP 0.25x0.3125 North America, one for MERRA-2 global 4x5, following the wiki; compiled the code; and did a dry run. for GEOS-FP 0.25x0.3125 NA it was for the month of July 2019. For MERRA-2 global 4x5 it was January - April 2018. I just noticed that in both cases, the only meteorological data that was recognized as required and missing files stopped on the 2nd day of the month. There are no files past day 2 of the initial month in the log files for the dry run, and so when I did the download data scripts based on those dry runs, no files past day 2 were downloaded of course. I tried to see if anyone had a similar issue but I haven't found.
GEOS-FP files listed in the dry run log file, and downloaded for July 2019:
GEOSFP.20190701.A1.025x03125.nc GEOSFP.20190701.A3cld.025x03125.nc GEOSFP.20190701.A3dyn.025x03125.nc GEOSFP.20190701.A3mstC.025x03125.nc GEOSFP.20190701.A3mstE.025x03125.nc GEOSFP.20190701.I3.025x03125.nc GEOSFP.20190702.I3.025x03125.nc
Same but for MERRA-2 for January - April 2018, only has one folder for January 2018 with these files:
MERRA2.20180101.A1.4x5.nc4 MERRA2.20180101.A3cld.4x5.nc4 MERRA2.20180101.A3dyn.4x5.nc4 MERRA2.20180101.A3mstC.4x5.nc4 MERRA2.20180101.A3mstE.4x5.nc4 MERRA2.20180101.I3.4x5.nc4 MERRA2.20180102.I3.4x5.nc4
I followed the exact same workflow as what I had done with 13.0.0-rc, which successfully recognized all the files that were needed so for those dry runs of different time periods and meteorological fields I have been able to download multiple full months with all of the days of meteorological data. After switching to 13.0.1 they both seem to stop in day 2 after the I3 file.
GEOS-Chem version
13.0.1
Description of modifications
none
Log files
Build log (if applicable):
Run logs (if applicable): dry run log for MERRA-2, 2018 Jan-Apr: log.dryrun.201801_201804.txt with this input file:
input.geos.201801_201804.txt ; list of unique files log file: log.dryrun.201801_201804.unique.txt
dry run log for GEOS-FP, July 2019: log.nested.dryrun.07.txt with this input file input.geos.txt ; list of unique files log file: log.nested.dryrun.07.unique.txt
Run script (if applicable): run script for MERRA-2, 2018 Jan-Apr dry run: dryrun_201801_201804.sbatch.txt ; run script for downloading data: dl_data_201801_201804.sbatch.txt
run script for GEOS-FP, July 2019 dry run: nested_dryrun_07.sbatch.txt ; run script for downloading data: download_data_07.sbatch.txt
Software versions
The text was updated successfully, but these errors were encountered: