You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When ending a time period on a leap year, an index error occurs. For example, doing RAPIDpy for 1971-1972 crashes, because 1972 is a leap year. But if you do RAPIDpy for 1971-1973, it works fine.
Also, on some installations (problem on my Linux desktop, but not on the HPC install), generating the m3 file for a multi-year time period has an error related to leap years. A problem in the m3 file data occurs every four years, and the number of days is only 365 times the number of years, instead of some years having 366 days.
The text was updated successfully, but these errors were encountered:
I think it is because it bases the number of time steps by the initial file in the group. So, if you start with a file with 365 days, then it assumes all of them are 365 days. This works when the files are divided into days. However, leap years make this assumption invalid for files grouped by year as some will have 366 days.
When ending a time period on a leap year, an index error occurs. For example, doing RAPIDpy for 1971-1972 crashes, because 1972 is a leap year. But if you do RAPIDpy for 1971-1973, it works fine.
Also, on some installations (problem on my Linux desktop, but not on the HPC install), generating the m3 file for a multi-year time period has an error related to leap years. A problem in the m3 file data occurs every four years, and the number of days is only 365 times the number of years, instead of some years having 366 days.
The text was updated successfully, but these errors were encountered: