-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Update the VARIABLE_MAP in the srml.py module #2356
Comments
This is the structure I am thinking of (and comparison to the current structure)
It looks like I will need to update the test as well which I don't mind doing. I just need a yay or nay and some comments on the this naming scheme. I tried to follow the nomenclature where possible. We use bp internally at Sandia for barometric pressure. Hence the abbreviation there. I think sometimes 'e' is used for irradiance, but wanted to confirm that before I used it on the tilt measurements. I think 'gri' is the same as ' global ground facing irradiance', but correct me if that is wrong. For the 7000s, I am not sure 'beam' is better than 'norm' in that prefix. Let me know on anything else you see. |
Already spotted an inconsistancy: Is it better to put the min and max after the temp_air? Does pvlib tend to use acis.py also uses epw.py uses snow_depth so we probably need to fix that inconsistency. That files has a number of these column name replacements. Will update these. |
For the tilted pyranometer measurements: I would use I'm not sure what to recommend for the 7000s. What are these quantities? If 'std_wind_direction' is the standard deviation of wind direction, I would put the modifier 'std' at the end. |
For 7xxx, from the documentation: "Spectral solar radiation data" I don't really have anymore insight than this. I will implement your suggestions. Lets go with the voltage_15_180 format. This allows for the off chance that someone has a strange angle they want to use (127 degrees for example). |
By the way, to format multiline code blocks, use triple back quotes (github docs) |
I went ahead with implementing the changes on my own fork. I was not sure if it was ready to for a pull request. I went with snow_depth because it appears that snowfall and snowdepth are actually two different measurements It could be that one is for real time snowfall conditions and the other is for accumulated snow fall conditions. I am not sure. I can look into it though. I can modify it to horizontal_ if preferred I tend to be the type that writes very long variables in python. Usually people get annoyed by that. If that is the preference here all the better.
|
I think that's correct but it would be great to confirm.
I agree with Let's leave the 7xxx data out of the map if we can't find clarification on the quantities. |
I am currently in contact with someone at University of Oregon to discuss the 7xxx data descriptions. He said he did not have time this week to talk, but would get back to me next week when things had lightened up a bit. Hopefully we can get a satisfactory answer on what exactly each measurement there represents. |
Via our discussion and recommendations on the discussion thread found here #2351 this issue is being submitted (first step in the pull request process).
The goal of this issue is to expand the VARIABLE_MAP to include other variables not included in pvlib-python as well as some of those that are included but never have been implemented.
Right now the srml.py module cannot be used as a general, stand alone tool for replacing the numbered column headers in an srml file with actual readable strings (only for a select 9 values that make up a small part of the total srml parsing set).
The full list can be found here and gives suggested naming conventions.
http://solardata.uoregon.edu/DataElementNumbers.html
A few iteration are planned on this to get the naming scheme correct.
Filling out the VARIABLE_MAP will allow the parser to act as a stand alone tool for porting out updated data files (which is our end use goal).
The text was updated successfully, but these errors were encountered: