pele-python / mcpele

Monte Carlo and parallel tempering routines built on the pele foundation
Other
20 stars 5 forks source link

Store trajectory #73

Closed smcantab closed 8 years ago

smcantab commented 8 years ago

I have implemented a base function to store a vector timeseries (I used a deque of pele arrays) and implemented child class to record the coordinates as a function of time at regular intervals.

js850 commented 8 years ago

I was trying to find where you record the trajectories to disk, but couldn't find it. Maybe you mean something else by "record"?

kjs73 commented 8 years ago

It seems that this also contains parts of PR #72.

smcantab commented 8 years ago

Hi, yes this contains part of the other PR but it will be resolved when I merge the other one first. Regarding Jake's question, the class has a get_time_series and a clear function, so the dumping to disk can be dealt with from python. I have written a couple of utility functions that allow one to dump the trajectory to a hf5 database which has really fast i/o. I'll add those functions to this PR.

kjs73 commented 8 years ago

Looks good to me. Would there be a way to re-use the computation of mean and variance that we coded up elsewhere? Maybe not.

smcantab commented 8 years ago

I don't understand why this test keeps failing, it works fine on my machine

smcantab commented 8 years ago

The computation of mean and variance are coded up as part of the other PR. It should have been a separate PR but I forgot to change branch. We decided that we wanted to keep the two classes distinct: one action class stores the trajectory alone and the other stores the average coordinate position and its elementwise variance. The two are related to be honest and it would make sense for the two functionalities to be integrated in the same class. The relevant commit is here

https://github.com/pele-python/mcpele/commit/14cdc951bea1d8b7e71e5f481f0647a15878fcff

Opinions?

kjs73 commented 8 years ago

The test is failing on my computer as well. Can it be that the precision requirement on the eigenvalues is too strict?

fabs(series[i])/(fabs(series[i])+fabs(eigenvalue_reference)+1) evaluates to 0.49999999992741601,
fabs(eigenvalue_reference)/(fabs(series[i])+fabs(eigenvalue_reference)+1) evaluates to 0.50000000007258405, and
1e-10 evaluates to 1e-10.
smcantab commented 8 years ago

I've lowered the threshold in one of the commits, now it passes On 17 Nov 2015 9:53 am, "Julian Schrenk" notifications@github.com wrote:

The test is failing on my computer as well. Can it be that the precision requirement on the eigenvalues is too strict?

fabs(series[i])/(fabs(series[i])+fabs(eigenvalue_reference)+1) evaluates to 0.49999999992741601, fabs(eigenvalue_reference)/(fabs(series[i])+fabs(eigenvalue_reference)+1) evaluates to 0.50000000007258405, and 1e-10 evaluates to 1e-10.

— Reply to this email directly or view it on GitHub https://github.com/pele-python/mcpele/pull/73#issuecomment-157323539.