Errors in calculation of net solar radiation

[KevinShook]

crhmcode is returning differing values for net (net solar radiation) from the Borland version. Both the older and new versions of crhmcode give the same results. In this example, the crhmcode values are < the Borland values.

A few days previously, the crhmcode values are > the Borland values:

The values of net are determined in Classnetall. I can't find any difference in the code between the versions. Also, the forcings seem to be the same. The incoming radiation components are the same:

The albedo values are also the same:

as are the number of sun hours:

I don't think that the issue is another if threshold. Note that the if tests are based on values of hru_SunAct and SunMax which are much greater than zero.

 if(hru_SunAct[hh] > 0.0 && SunMax[hh] > 0.0)

Unfortunately we can't see the internal variables in the Borland code. I'll see if I can get Logan to debug the code to give us internal variables on some of the days in question.

[KevinShook]

Excellent. Can I try your code?

[jhs507]

Yes just give me a moment to push to that branch.

[KevinShook]

Thanks

[jhs507]

My code is committed on the comparison-tolerance branch. There is a logging line on common.cpp 343, and 375 that you may want to comment out before testing. Or send your output to file.

[KevinShook]

Thanks very much

[jhs507]

I just had a meeting with Kevin Schneider and we discussed our approach to these issues dealing with floating point precision. We think it would be productive to have a conversation with you about them.

What would be a good time for you? Kevin Schneider suggested that anytime after 2:00 today or after 1:00 tomorrow would work for him.

[KevinShook]

That would be great. I have a conference call from 1-2 today, so after 2 would be good for me.

[jhs507]

How about 2:15 then?

[KevinShook]

Works for me, thanks

[KevinShook]

Looking at Classebsm.cpp, line 205 is weird in that it is terminated with line break double eamean = Common::estar(tmean[hh]) * rhmean[hh] / 100.0; \ This was also in the original Borland code. Any idea why it's there?

[jhs507]

That is weird but the compiler should just ignore it as the statement is properly ended with a ';'

[jhs507]

I did a bit more looking at the switches in Classalbedo. As we discussed yesterday at a certain point what path execution takes is a bit arbitrary but I focused in on the comparison on line 131.

Because it is a zero threshold I thought it would be particularity sensitive and correction would be easier. Also it is looking at SWE which we know often contains very small values.

After a bit of digging I found that in a 2 year period that by implementing a threshold of 1e-5 that there are 8967 instances where the SWE is above zero but under 1e-5. I wanted to see if they were evenly distributed on the HRU's and came up with this chart.

It seems HRU 5, and 10 are outliers. I don't know if that is relevant.

As you suggested above I think this really should use the same or similar threshold parameter as the pbsm module. It seems to me a place where we should change borland crhm as well.

[KevinShook]

I've been talking to John, and I think we should leave all of the thesholding alone for now. There are too many of these things. Also, there are some issues with how we have been forcing the model with daily precip, but hourly air temps and humiidities. I'll send an update - an in the middle of soemthing right now.

[KevinShook]

I'm going to try re-running the model, using the old version of the code - the master branch. This time I'm not going to use the Harder method for partitioning the precipitation into rain and snow. I'm going to use air temperatures, which should be less susceptible to problems. As I said above, I think that the problem is that the daily precipitation data is causing precipitation during intervals when the RH is << 100%, which is not possible. This is very likely the cause of snowfalls when they cannot occur.

I have run the Borland code with this configuration, so I can compare the crhmcode output against that run.

[jhs507]

Sounds good, let me know how it goes.

[KevinShook]

I changed the precipitation partitioning to use the air temperature rather than the Harder method. As you can see, both models now the same evaporation values:

There are some issues with other values, but I think that we can consider this issue to be closed.