I've been working on updates to run EddyPro on data from an IRGASON. Since the anemometer in the IRGASON is has the same dimensions as the CSAT3, those default values will suffice. I could just modify my .eddypro initialization file to list CSAT as the SONIC model and be done with it ... but I decided to check the parameters in the source code and and I've come across what I suspect is are some errors in the default eddypro parameters for the CSAT3 and other anemometers.
Looking at the EddyPro GUI metadata editor, there is a tool tip which come up when you hover over longitudinal path (instr_1_vpath_length in the GHG.metadata file) which indicates the vpath parameter is the distance between transducers while transversal path length (instr_1_hpath_length in the GHG.metadata file) indicates this parameter should be the diameter of the transducer.
However, inspecting the default sensor parameter definitions given here in Eddy Pro do not exactly match the specs in the manual. e.g., for the CSAT, they are defined as:
E2Col(u:ts)%Instr%vpath_length = 0.115d0
E2Col(u:ts)%Instr%hpath_length = 0.058d0
Assuming the tooltip suggestions are correct, hpath_length the CSAT3 (transducer diameter 0.0064 m) is off by almost an order of magnitude!? All of the default sonic hapth_lenght parameters given are far from reasonable if the width of the transducer is actually what the hapth_lenght parameter should represent! Further, there is no hpath_lenght parameter provided for the young 8100 series anemometers.
The hapth_lenght parameter is only used here in the Masman et al. (2000) correction, which is not a default setting, so this issue probably doesn't impact most analyses, but it would be a big issue for anyone using it. Table 1 in the Masman paper describes the parameters. From this, it does not read like the hpath_length parameter should be the transducer diameter. Rather it should either be: 1) the horizontal component of the sonic path, in which case hpath_lenght is correct but vapth_lenght should be the vertical component of the sonic path (10 cm). Or 2) hpath_lenght = vpath_lenght = distance between transducers as they assume here. From the way vpath is applied elsewhere (see below) I would assume it is case 2?
The vpath_lenght parameter is more important. It is used here) in the analytic low pass transfer function, which is used applied to all fluxes calculated in EddyPro. The correction is detailed in Annex A of the Moncireff paper which is based on the definition presented in Equation 9 and Fig2 of the Moore 1986 paper, and is its self obtained from integrating equation 16 in the Kaimal 1968 paper. Kaimal explicitly presents the equation with the qualification that it applies to "vertical velocity component averaged over a vertical path of length l".
In the context of Kamal et al. 1968 and Morse 1986, this transfer function was developed for and applied to anemometers with vertically oriented transducer pairs by, so there was no between the vertical path and the transducer path was not necessary. In the context of Moncrieff et al. 1997, it was applied to measurements from a Solent A1012R which does not have vertically oriented transducers. Likewise, this is the approach taken by the TK3 software package as described in table 2 of the manual when referencing the Moore 1986 correction. It is worth emphasizing that the transfer function was developed it was for the case of vertical winds averaged over a vertical path. Intuitively, it makes sense to substitute the longitudinal path for the vertical path in the case of anemometers without a vertically oriented transducer pair, as that is the distance over which sonic measurements are averaged. However, I have not been able to find a defense of this assumption in the literature.
Assuming that using longitudinal distance is the correct choice, the vpath_length values defined for the Gill instruments in the do not match the values used by the TK3 application, which are also reported here in table 2 of Mauder and Zeeman (2018). These Gill specs are not publicly available in their manual so I've contacted the manufacture to confirm if 15cm is the correct path length. In EddyPro, the listed values are all 12.5cm:
case('hs_50')
E2Col(u:ts)%Instr%vpath_length = 0.125d0
E2Col(u:ts)%Instr%hpath_length = 0.110d0
E2Col(u:ts)%Instr%tau = 1d0 / 50d0
case('hs_100')
E2Col(u:ts)%Instr%vpath_length = 0.125d0
E2Col(u:ts)%Instr%hpath_length = 0.110d0
E2Col(u:ts)%Instr%tau = 1d0 / 100d0
case('r2')
E2Col(u:ts)%Instr%vpath_length = 0.125d0
E2Col(u:ts)%Instr%hpath_length = 0.110d0
E2Col(u:ts)%Instr%tau = 1d0 / 50.d0
case('r3_50')
E2Col(u:ts)%Instr%vpath_length = 0.125d0
E2Col(u:ts)%Instr%hpath_length = 0.110d0
E2Col(u:ts)%Instr%tau = 1d0 / 50d0
case('r3_100')
E2Col(u:ts)%Instr%vpath_length = 0.125d0
E2Col(u:ts)%Instr%hpath_length = 0.110d0
E2Col(u:ts)%Instr%tau = 1d0 / 100d0
case('r3a_100')
E2Col(u:ts)%Instr%vpath_length = 0.125d0
E2Col(u:ts)%Instr%hpath_length = 0.110d0
E2Col(u:ts)%Instr%tau = 1d0 / 100d0
From the info provided in the link above, the vertical averaging path of the Gill instruments would be ~10.6 cm so the value does not appear to be a simple mix up of vertical path vs. longitudinal path. From the commit history, the specs listed here have been the same since 2014 so it would not be the case that the sensor specs have changed since these documents have beep published. This looks to be a rather serious issue for the Gill systems if all EddyPro analysis underrepresented the path length by 15%. This would necessitate reprocessing of all data for Gill systems with a corrected path length.
I've been working on updates to run EddyPro on data from an IRGASON. Since the anemometer in the IRGASON is has the same dimensions as the CSAT3, those default values will suffice. I could just modify my .eddypro initialization file to list CSAT as the SONIC model and be done with it ... but I decided to check the parameters in the source code and and I've come across what I suspect is are some errors in the default eddypro parameters for the CSAT3 and other anemometers.
Looking at the EddyPro GUI metadata editor, there is a tool tip which come up when you hover over longitudinal path (instr_1_vpath_length in the GHG.metadata file) which indicates the vpath parameter is the distance between transducers while transversal path length (instr_1_hpath_length in the GHG.metadata file) indicates this parameter should be the diameter of the transducer.
However, inspecting the default sensor parameter definitions given here in Eddy Pro do not exactly match the specs in the manual. e.g., for the CSAT, they are defined as:
Assuming the tooltip suggestions are correct, hpath_length the CSAT3 (transducer diameter 0.0064 m) is off by almost an order of magnitude!? All of the default sonic hapth_lenght parameters given are far from reasonable if the width of the transducer is actually what the hapth_lenght parameter should represent! Further, there is no hpath_lenght parameter provided for the young 8100 series anemometers.
The hapth_lenght parameter is only used here in the Masman et al. (2000) correction, which is not a default setting, so this issue probably doesn't impact most analyses, but it would be a big issue for anyone using it. Table 1 in the Masman paper describes the parameters. From this, it does not read like the hpath_length parameter should be the transducer diameter. Rather it should either be: 1) the horizontal component of the sonic path, in which case hpath_lenght is correct but vapth_lenght should be the vertical component of the sonic path (10 cm). Or 2) hpath_lenght = vpath_lenght = distance between transducers as they assume here. From the way vpath is applied elsewhere (see below) I would assume it is case 2?
The vpath_lenght parameter is more important. It is used here) in the analytic low pass transfer function, which is used applied to all fluxes calculated in EddyPro. The correction is detailed in Annex A of the Moncireff paper which is based on the definition presented in Equation 9 and Fig2 of the Moore 1986 paper, and is its self obtained from integrating equation 16 in the Kaimal 1968 paper. Kaimal explicitly presents the equation with the qualification that it applies to "vertical velocity component averaged over a vertical path of length l".
In the context of Kamal et al. 1968 and Morse 1986, this transfer function was developed for and applied to anemometers with vertically oriented transducer pairs by, so there was no between the vertical path and the transducer path was not necessary. In the context of Moncrieff et al. 1997, it was applied to measurements from a Solent A1012R which does not have vertically oriented transducers. Likewise, this is the approach taken by the TK3 software package as described in table 2 of the manual when referencing the Moore 1986 correction. It is worth emphasizing that the transfer function was developed it was for the case of vertical winds averaged over a vertical path. Intuitively, it makes sense to substitute the longitudinal path for the vertical path in the case of anemometers without a vertically oriented transducer pair, as that is the distance over which sonic measurements are averaged. However, I have not been able to find a defense of this assumption in the literature.
Assuming that using longitudinal distance is the correct choice, the vpath_length values defined for the Gill instruments in the do not match the values used by the TK3 application, which are also reported here in table 2 of Mauder and Zeeman (2018). These Gill specs are not publicly available in their manual so I've contacted the manufacture to confirm if 15cm is the correct path length. In EddyPro, the listed values are all 12.5cm:
From the info provided in the link above, the vertical averaging path of the Gill instruments would be ~10.6 cm so the value does not appear to be a simple mix up of vertical path vs. longitudinal path. From the commit history, the specs listed here have been the same since 2014 so it would not be the case that the sensor specs have changed since these documents have beep published. This looks to be a rather serious issue for the Gill systems if all EddyPro analysis underrepresented the path length by 15%. This would necessitate reprocessing of all data for Gill systems with a corrected path length.