-
Notifications
You must be signed in to change notification settings - Fork 4
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 with species file handling in PCHEM #94
Comments
Good catch. I suspect that this code was originally designed and tested using a file that had a number of whole years, without a partial year at the end. Do you propose to change its behavior so that it repeats the last 12 months in the file? Or have it use the last complete year, Jan - Dec, as a climatology? |
I was proposing disabling the climatology by default. So unless you have the DAS file with 1 year, it just does not exercise this extra logic for the climatology. In this way you could not run the existing merra2 pchem file at all out side of the valid range, it would fail anytime you are outside of the data range, rather than the confusing condition we have now where it works for part of the year, then just fails in May. Beyond that you could have it repeat the last FULL year Jan-Dec. That gets a little tricky as you have to do some more work to detect what are the time indices on the file that really do represent the last full Jan-Dec cycle, but doable. Probably would want the ability to turn this on and off. |
I like the idea of disabling the climatology behavior by default, but I think it should still be available as an option. And would it be more appropriate to cycle through the last 12 months in the file, regardless of which month it ends with? For example, if the file ends in November 2020, then subsequent months would use Dec 2019, Jan 2020, Feb 2020, etc. This makes more sense to me than reverting to 2019 as a climatology after getting through most of 2020. |
ok, I'll take a look and see if this is easy to implement, I see what you mean now about using the previous 12 months. |
I've identified a bug in the GEOS_PChemGridComp.F90 with the handling of the species file. I tracked this down because we know there is an issue when using the default MERRA2 species file which currently goes through 2017. People have been crashing when running past 2017 and using this file. What was confusing me is that when looking into this more, people were able to run for a while when using this before crashing. For example, in the latest crash the user started on 4/1/2020 and it ran to mid May which was just confusing me so I looked into this.
It turns out the issue is that the way this file is handled in the component is just not robust. It is always treating the file as a climatology even when that is not appropriate.
First GEOS_PChemGridComp.F90 assumes the file being read is monthly data and interpolates between the monthly data. The resource file specifies the number of years in the file (pchem_clim_year) and the component detects the beginning year and ending year from global attributes in the file.
It updates the brackteting data at mid-month, the actual algorithm is as follow:
indx1 = indx1 + (working year - beginning year)*12
This all works if you have a file with 12 times and you say the pchem_clim_year=1 as the das runs.
However, it fails for a data file like the merra2 one that ends in may 2017, essentially if you are running in 2020, and your file ends in 2017 it detects you are past the end time and sets the current working year back to 2017 like this is a climatology, but now it tries to go past the last file index if you are past may. But the failure mode is weird because you can run for the first part of the year unaware there is a problem.
So either, the logic needs to be made more robust so is it not automatically assuming a climatology and not exercise that part of the code to get less bizarre failure modes or the appearance of working when it should not be. This should be straightforward for me to do.
Or if every dataset were complete years, then I suppose the currently logic would work.
The text was updated successfully, but these errors were encountered: