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
Just like for continuous surface height, I believe this calculation should come after the merging of transmissions and raw files, so that it is not run twice on redundant periods. It is also not so time critical, so it is fine if it is done after the core observations are being processed and sent to WMO. It is also unnecessary to run it on 10 min data, which would be very computationally expensive while of no practical use.
It uses a database of maintenance information including dates of visits and reported depth of installation for the thermistors. It is currently a google sheet but could be hosted on GitHub.
A natural consequence of estimating a continuous surface height is that we can now calculate the thermistor depth for each time stamp.
I made a first implementation here: https://github.com/GEUS-Glaciology-and-Climate/pypromice/tree/surface-height-thermistor-depth-processing
Just like for continuous surface height, I believe this calculation should come after the merging of transmissions and raw files, so that it is not run twice on redundant periods. It is also not so time critical, so it is fine if it is done after the core observations are being processed and sent to WMO. It is also unnecessary to run it on 10 min data, which would be very computationally expensive while of no practical use.
It uses a database of maintenance information including dates of visits and reported depth of installation for the thermistors. It is currently a google sheet but could be hosted on GitHub.
Some example of the depths estimated with the new pypromice branch: https://github.com/GEUS-Glaciology-and-Climate/PROMICE-AWS-diagnostic/tree/main/figures/string_processing
The text was updated successfully, but these errors were encountered: