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
One of the reasons for issues #408 and #409 is that range checking is currently not being done for the fractions inside of CMEPS. Since, the ways that the fractions are computed is complex and could become incorrect it would be good to validate the range. This is also helpful when adding new grids to CMEPS where if it's out of range you know something is wrong. Otherwise, the model will run and you won't know about this issue unless you are able to look into it and figure it out. And figuring it out to a naive user is problematic and time-consuming.
The range for the fractions should be 0 to 1. But, allowing for some range within eps_fraclim would make sense. So something like this could be done.
if frac < eps_fraclim and frac > -eps_fraclim => frac = 0
if frac < 1+eps_fraclim and frac > 1-eps_fraclim => frac = 1
if frac < -eps_fraclim => abort
if frac > 1+eps_fraclim => abort
In some cases the truncation to zero is happening, but it would be good to make it consistent everywhere. The truncation changes would change answers so we'd need to be good with that, or else NOT add it in.
Note, this is the behavior that we had in the MCT coupler where range was checked for fractions and it would abort if out of range. I'm not sure if the truncation was done, but we could check.
The text was updated successfully, but these errors were encountered:
One of the reasons for issues #408 and #409 is that range checking is currently not being done for the fractions inside of CMEPS. Since, the ways that the fractions are computed is complex and could become incorrect it would be good to validate the range. This is also helpful when adding new grids to CMEPS where if it's out of range you know something is wrong. Otherwise, the model will run and you won't know about this issue unless you are able to look into it and figure it out. And figuring it out to a naive user is problematic and time-consuming.
The range for the fractions should be 0 to 1. But, allowing for some range within eps_fraclim would make sense. So something like this could be done.
In some cases the truncation to zero is happening, but it would be good to make it consistent everywhere. The truncation changes would change answers so we'd need to be good with that, or else NOT add it in.
Note, this is the behavior that we had in the MCT coupler where range was checked for fractions and it would abort if out of range. I'm not sure if the truncation was done, but we could check.
The text was updated successfully, but these errors were encountered: