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

SW radiation reversed in toposub runs #37

Open
joelfiddes opened this issue May 10, 2022 · 16 comments
Open

SW radiation reversed in toposub runs #37

joelfiddes opened this issue May 10, 2022 · 16 comments

Comments

@joelfiddes
Copy link
Collaborator

SW seems to be high on north face and low on south in toposub runs (here blue is low rad, greens/yellows high rad)

image
image

am investigating....

@ArcticSnow
Copy link
Owner

what is the colorscale on your plot? And I suspect those are DEM artefacts?

@joelfiddes
Copy link
Collaborator Author

2022-06-22_09-51
image

@joelfiddes
Copy link
Collaborator Author

confirmed for the Alps (Kandersteg) This is Sw direct 2015-06-01 12:00. Values 0 (blue) - 529 (yellow) Wm-2. North face has higher SWdir than South face

@joelfiddes
Copy link
Collaborator Author

I still dont understand l.149 in topo_param.py:

ds['aspect'] = (["y", "x"], np.deg2rad(aspect - 180))

why do we subtract 180 deg? doesnt this reverses the aspect?

@ArcticSnow
Copy link
Owner

ArcticSnow commented Jun 22, 2022

This is indeed strange! Could it be to bring aspect in the same convention as solar geom or Horizon which assumes the south at 0, west in negative and east in positive?

Then this should be done otherwise as it clearly messes with the rest.

And if you remove that 180?

@joelfiddes
Copy link
Collaborator Author

with GST results I just made I get cold N and warm S - just rerunning case above to see how SW is affected.....

@joelfiddes
Copy link
Collaborator Author

.... with the 180 removed, that is.

@joelfiddes
Copy link
Collaborator Author

image

@joelfiddes
Copy link
Collaborator Author

removed the 180 ...looks a bit better :) this is Jan 31 2015 12:00 with similar color scale as above. S now has 400+ Wm2 and N 0-ish

much better!

@ArcticSnow
Copy link
Owner

shouldn't there be some diffuse SW reaching the north? it is not dark there

@joelfiddes
Copy link
Collaborator Author

prob not steep north in January - I think its realistic. Better than before :)

@joelfiddes
Copy link
Collaborator Author

2022-06-23_15-33

@joelfiddes
Copy link
Collaborator Author

23 Jan 2022 lighting at 12pm from GE - the steep north face here is the one that dominates the scene above

@joelfiddes
Copy link
Collaborator Author

sorry misread your comment - this is just SW-direct component above.

joelfiddes added a commit that referenced this issue Jun 24, 2022
… slopes and warm N slopes. Still has not been established why this was there in first place, possibly for solar geom conventions. see issue #37 (comment)
@joelfiddes
Copy link
Collaborator Author

pushed the commit - however I leave open as we still need to fully understand if there are any implications on eg solar geom or horizon as mentioned above (-180 convention)

@krisaalstad
Copy link
Collaborator

Sorry for not following your discussions guys, but this sounds like an aspect convention issue to me. I would always recommend using Dozier's convention of south=0, east=pi/2 (90 deg), north=pi (180 deg), west=-pi/2 (-90 deg), that way we have a right handed coordinate system which is much easier to work with mathematically. This has to be used for everything, so we should just be sure that both the solar azimuth and slope aspect are defined with the same convention (that should be relatively easy to check, since we know roughly where the sun rises and sets and we know where the north and south facing slopes are). For visualization it's always possible to convert aspects to the more usual bearing convention in post-processing, but for the actual math I would always use Dozier's convention. I don't think that simply removing or adding 180 degrees is the right way to convert between these systems (sorry if you inherited this from my code, then that was wrong too), since that only works for half the circle.

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

3 participants