Skip to content
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

Open
bena-nasa opened this issue Jun 16, 2020 · 4 comments
Open

Bug with species file handling in PCHEM #94

bena-nasa opened this issue Jun 16, 2020 · 4 comments

Comments

@bena-nasa
Copy link
Collaborator

bena-nasa commented Jun 16, 2020

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:

  1. It detects what month I am, so if you start on say March 7th, it returns two indices (indx1 and indx2) which are 2 and 3 in this example. If you start on December 21st, indx1 = 12 and indx2=13
  2. It gets the current year from the clock, which is set to the working year.
  3. If you are beyond the end year in the file, the working year is set to the end year
  4. It computes the file indexes like so:
    indx1 = indx1 + (working year - beginning year)*12
  5. It has some specialized lines that really only make sense if you have a single file with 12 times.

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.

@mmanyin
Copy link
Contributor

mmanyin commented Jun 16, 2020

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?

@bena-nasa
Copy link
Collaborator Author

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.

@mmanyin
Copy link
Contributor

mmanyin commented Jun 16, 2020

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.

@bena-nasa
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants