gsee

gsee copied to clipboard

The current implementation in gsee.trigon has some problems around sunrise and sunset where PV capacities become unreasonably large. This is due to the 1/cos(solar-zenith) term and the way that timestepping is handled.

I suggest a different way to compute the 1/cos contribution that is more representative for cumulative data and can handle non-hourly input data better. The basic idea is to compute 1/cos repeatedly on a sub-timestep scale, set unreasonably large contributions to zero and then average everything. More details can be found here:

background.pdf

I attach plots made using 3h reanalysis data for the initial implementation, using my changes and the difference between both. There are arch-like structures close to the sunset/sunrise lines in individual timesteps (most visible in June and December) using the initial version which vanish in the proposed one.

Initial New Difference

Open questions:

• The sub-timestep calculations using N=20 steps slow down the code by a factor of around 5. Maybe one should tweak this a bit or leave it for the user to define in each individual application?
• In some function call, an additional variable is needed to flag data as either instantaneous (satellite, ground observation) or cumulative (most climate models, reanalysis).

Thanks @jwohland! I have added a stub to differentiate between accumulated/instantaneous.

I think it would also make sense to test what value works for N and how that affects overall runtime of the code. Also, can you differentiate between the two cases in the unit tests so that those don't fail?

I have also run black on all the main module files. See https://black.readthedocs.io/en/stable/. This auto-formats the code. Can you make sure you run that locally too on making further changes? Hound is not yet set up to account for that, but will be.