It has been noted that the EXT model causes slightly different maps to be created by SMURF makemap when the number of threads changes. The discrepancy is of the order of the noise and so it quite noticeable.
I think that this is caused by the code that splits up the data into chunks not splitting on WVM measurement boundaries. The WVM is readout every 1.2 seconds or so and so there can be 200 TCS readings for every WVM reading. The WVM calculation depends on the airmass of the telescope but once calculated should not change as the telescope moves until the next reading is made. If we split the data between threads between readings the tau reading for the start of the next chunk will be different to the reading from the end of the previous chunk despite them being nominally the same reading. The number of threads will therefore control how many of these jumps there are (and the telescope can move quite a long way in a second).
After an estimate for the thread boundaries has been calculated the actually boundary should be finessed by running forward until the WVM measurement changes.
To be pedantic we should really be reading the telescope position for WVM_TIME but at the moment we simply assume that the TCS_AIRMASS reading is appropriate for the associated WVM_* readings despite the WVM_TIME indicating that an earlier telescope reading should be used (by looking at TCS_TAI).
It has been noted that the EXT model causes slightly different maps to be created by SMURF
makemapwhen the number of threads changes. The discrepancy is of the order of the noise and so it quite noticeable.I think that this is caused by the code that splits up the data into chunks not splitting on WVM measurement boundaries. The WVM is readout every 1.2 seconds or so and so there can be 200 TCS readings for every WVM reading. The WVM calculation depends on the airmass of the telescope but once calculated should not change as the telescope moves until the next reading is made. If we split the data between threads between readings the tau reading for the start of the next chunk will be different to the reading from the end of the previous chunk despite them being nominally the same reading. The number of threads will therefore control how many of these jumps there are (and the telescope can move quite a long way in a second).
After an estimate for the thread boundaries has been calculated the actually boundary should be finessed by running forward until the WVM measurement changes.
To be pedantic we should really be reading the telescope position for
WVM_TIMEbut at the moment we simply assume that theTCS_AIRMASSreading is appropriate for the associatedWVM_*readings despite theWVM_TIMEindicating that an earlier telescope reading should be used (by looking atTCS_TAI).