Closed xiki-tempula closed 1 year ago
Hi @xiki-tempula ,
In dealing with the exact situation you are describing I usually just read each output file from the same simulation and concatenate them via concat
from alchemlyb
, without any issue!
The time
for each file is not directly read from the output file, but is computed from the starting time, the dt
, and the steps between output
.
The only problem may arise if one tries to concatenate files from different simulations, but this is the case also for GROMACS I think!
@DrDomenicoMarson Thanks. Do you think it would be fine if I just remove https://github.com/alchemistry/alchemlyb/blob/master/src/alchemlyb/parsing/amber.py#L361 Then issue a warning if there are more data after the finish?
I don't have the time to test this right now, but I think it shouldn't be an issue!
I think there should be an Error and not a Warning, if data is found after the finish because I don't know if the logic that is used now would deal with a single file that is a concatenation of several output AMBER files though.
Close this via the concatenation of the pandas dataframe #316
An error should be thrown if the input is a concatenated amber output file
In many occasions, one would need to run simulation in chunks. For 10 ns simulation, one run the first ns, the seconds ns and so on. For Gromacs, this is easy and the output would be a continuous file. However, given that AMBER doesn't have a checkpoint continue mechanism. A convention to do continuation would be that one generate a number of amber output files and concatenate the text files together. This would result in
So you have duplicated time points in the same input file. The current behaviour is that when we reach the end of the first file
5. TIMINGS
, we close the file parser, so the rest of the information is gone, which is not ideal.There are several ways of solving this problem. The easiest way would be to just to remove this break https://github.com/alchemistry/alchemlyb/blob/master/src/alchemlyb/parsing/amber.py#L361 This would allow the parser to continue. On the other hand, instead of logging the data for
0~1 ns, 0~1 ns, 0~1 ns
. This would log 0~1 ns, 1~2 ns, 2~3 ns
. In some sense this would mean that we are not reading the data as it is. On the other hand, this would probably be the expected behaviour in this case so this might be fine.The more involved way of solving this problem might be to log the data as it is, For example,
0~1 ns, 0~1 ns, 0~1 ns
. Then the user might need to change the time point by themselves.I'm in favour of the easy solution but is not sure of this would create some additional problem @DrDomenicoMarson Here is an example input file , note that only 50 data points are loaded. amber.out.zip