The product I'm currently using is LakeSP Version D. I'm facing a significant issue with the algorithm. After reviewing the LakeSP PDD and ATPD documentation regarding SWOT water storage data, I encountered a point that I find perplexing.
Their water storage data is presented as changes in water storage: ds1/l ds1/q. However, the official documentation states that changes in water storage are relative to the water storage at time t0 , specifically p_date_t0. Calculating it as using ΔV - p_ds_t0 yields the storage change. Yet, p_ds_t0 is officially defined as the storage change calculated relative to changes in the reference water level and area , and then treated as the storage change relative to the day p_date_t0.
So the question arises: if p_date_t0 is 2023-12-3, shouldn't ds1 for that day be 0? the row I selected corresponds to December 3, 2023. On that day, ds1 is not 0. I just can't figure it out. If you're using p_date_t0 as the reference, then the △V should equal the p_ds_t0 value for that day. Yet, after reviewing numerous files, I found that ds1 values for p_date_t0 are never zero.
So where exactly is the problem?
Questions about ds1/l/q on p_data_t0
Re: Questions about ds1/l/q on p_data_t0
Thank you for this important question. I have forwarded it to the CNES algorithm team and will get back with an answer soon.
Re: Questions about ds1/l/q on p_data_t0
Sorry about the delay. We have received a reply from the CNES product team, and here is the feedback.
"Indeed, the storage change at the date p_ref_t0 should, in theory, be equal to 0.
However, in practice, this is generally not the case, since the storage change attributes of the PLD are calculated using LakeSP products from the previous version.
Let me illustrate this with the example of lake_id 7830178863.
In PLD v2.02, we have the values p_ref_wse = 165.077 m, p_ref_area = 9.081902 km², and p_ds_t0 = -0.010621 km³ for p_date_t0 = 2023-04-02 08:17:03.
These attributes were calculated using LakeSP products from version C.
If we now look at the corresponding version D product at the date p_date_t0, the calculations having been improved between versions C and D, we obtain wse = 164.043 m and area_total = 10.360958 km².
Since these values differ from p_ref_wse and p_ref_area, we end up with a ds1 value that is close to 0, but not exactly zero.
Because of this approach, this discrepancy is observed in the majority of cases.
We would not encounter this issue if the reference storage change corresponded to an average or an 80% maximum “theoretical” state, with no associated date.
Since such a state would not change between versions, we would have ds1 = 0 for this reference.
I will describe this “feature” in the release notes for version D2 of the product."
Hope this helps. It seems that ds1 can still serve as the lake storage change; the only issue is that it does not necessarily start at 0 on t0. You could calibrate it by setting the value at t0 to 0, that is, by subtracting the t0 value from the value on each day—and it should be fine. Please do not hesitate to let me know if you have any questions.
"Indeed, the storage change at the date p_ref_t0 should, in theory, be equal to 0.
However, in practice, this is generally not the case, since the storage change attributes of the PLD are calculated using LakeSP products from the previous version.
Let me illustrate this with the example of lake_id 7830178863.
In PLD v2.02, we have the values p_ref_wse = 165.077 m, p_ref_area = 9.081902 km², and p_ds_t0 = -0.010621 km³ for p_date_t0 = 2023-04-02 08:17:03.
These attributes were calculated using LakeSP products from version C.
If we now look at the corresponding version D product at the date p_date_t0, the calculations having been improved between versions C and D, we obtain wse = 164.043 m and area_total = 10.360958 km².
Since these values differ from p_ref_wse and p_ref_area, we end up with a ds1 value that is close to 0, but not exactly zero.
Because of this approach, this discrepancy is observed in the majority of cases.
We would not encounter this issue if the reference storage change corresponded to an average or an 80% maximum “theoretical” state, with no associated date.
Since such a state would not change between versions, we would have ds1 = 0 for this reference.
I will describe this “feature” in the release notes for version D2 of the product."
Hope this helps. It seems that ds1 can still serve as the lake storage change; the only issue is that it does not necessarily start at 0 on t0. You could calibrate it by setting the value at t0 to 0, that is, by subtracting the t0 value from the value on each day—and it should be fine. Please do not hesitate to let me know if you have any questions.
Re: Questions about ds1/l/q on p_data_t0
Thank you very much for your reply. It cleared up my confusion.
I have one more question: Will the D2 product be updated to ds2<l/q>? If so, when is it expected to be updated?
I have one more question: Will the D2 product be updated to ds2<l/q>? If so, when is it expected to be updated?