Description
With the new AMBER2022 code, if the user adopts the new lambda scheduling, the DV/DL is supposed to be exactly 0.00000 at lambda==1.0 and lambda==0.0.
As far as I understand, a user still should want to perform computations at lambda==0 or 1, to collect u_nk data, but here our parsers and our workflows have some problems in dealing with dHdl extraction/analysis.
a) The first problem is a parser one, as AMBER doesn't output a value of DV/DL when it is exactly 0.0, so we'll have files in simulations performed at lambda 0.0 and 1.0 with MBAR data, but no DV/DL data.
Regarding this issue, I already asked in the amber mailing list if they can change the behavior of AMBER and make it print DV/DL values even when they are exactly 0.0, if a TI simulation is performed.
Otherwise, the solution can be to make some careful checks whether we are in a simulation with lambda scheduling & lambda==0.0 or 1.0, and if that's the case, we can add 0.0 as the dHdl value each time MBAR data is found.
Here the issue is that the check could be not so simple, as this assumption is right only if the standard lambda scheduling is used, but if a custom scheduling it's used different cases can arise. On this point, advanced lambda scheduling should be used only by advanced users, so maybe just throwing a warning and stating that we are adding 0.0 to dHdl could be enough.
b) if we collect a Series of 0.000000 values at lambda==0 or 1, common workflows in which the user uses subsampling/equilibrium detection will break, because when such functions are run on a series of 0.0, they will have a st.dev==0.0 and an exception rises.
I encountered problems a)+b) right now, and I "resolved" temporarily in a very inelegant and quick way by adding very small values (randint(-1000,1000)/100000000)) instead of 0.0 at lambda==0 or 1 in dHdl when MBAr data is collected, in such a way equilibrium detection and subsampling don't complain and the results are produced with my current workflow (results which are really nice by the way with this new method :-) ).
Problems a) and b) (especially b)) are an issue just if we want to maintain the compatibility with the current workflows users could have implemented. If a user is aware of the edge cases at lambda==0 or 1, he/she could easily adapt its workflow to just skip equilibrium detection/subsampling for dHdl at these windows.
I don't know which could be the best route to follow now. It's not urgent as we should wait also to see if AMBER will print DV/DL==0 values with a future patch, but I wanted to raise the attention on this issue now so we can discuss at least for case b).