user200000 / revelsmd

Revels MD is a developmental code for calculating structural quantities from atomistic simulations with reduced variance
MIT License
0 stars 1 forks source link

The use of longdouble numpy types #1

Open JelleLagerweij opened 2 months ago

JelleLagerweij commented 2 months ago

Dear Samuel, I have been very interested in your research regarding "force rdf" calculations and implemented my own version to postprocess reaction properties from AIMD simultions in VASP. Your code majorly inspired me and of course it will be cited adequately.

I do have a question though, you rely on dtype=np.longdouble, is there a specific reason that you did not use a np.float64 here? Normally, I would avoid the longdouble as it is very badly defined and depends on the os of the computer. I tried to calculate the forcerdf with both and had very similar results. Could you explain why you selected the longdoubles?

I did notice that there seems to be an accumulation of rounding errors in both the "from zero" and the "from infinity" (or better L/2) cases. It mostly seems to occur in very steep parts of the rdf. Is this reduced when using longdoubles? I added a plot below where I have the rdf of the atoms inside a water molecule (you can derive the shape of the molecule from this). This plot shows this error clearly while the oxygen-oxygen rdf (now show) does not have this problem at all. Using the reduced covariance method really solved this issue, so I am using that one now.

Thanks in advance and kind regards, Jelle Lagerweij

rdf_water

JelleLagerweij commented 2 months ago

I have a second question regarding the fundamentals of your method. The rescale factor contains the temperature and some physical constants. In my code, I use rescale1 = 8*np.pi*(co.k/co.eV)*self.T_set and you have something similar: accumulated_storage_array*=prefactor/(4*np.pi*len(to_run)*generate_boltzmann(TS.units)*temp) (you do some of the rescaling in a different order so some terms you have in the prefactor are in my rescale1 ect.).

My question is regarding the temperature, I run MD simulations, so I have fluctuating temperatures. Would you advise using the instantaneous temperature of the specific time step or the average temperature? I loop over many time steps and average and rescale my rdf afterward. Now I am using my average temperature, but I got unsure about this. Maybe you can shed some light on my questions.

Thanks in advance, Jelle

user200000 commented 1 month ago

Hello JelleI’m so sorry for my delay in replying. I find the usage of the maximum amount of precision is useful for the method hence the use of long double. This as I remember was particularly important when calculating the frames in order to get the variance. I might look into setting a float128 over the next couple of days as I work on the code thanks for the suggestion.I was wondering what you mean by rounding errors is this something other than the Delta value we refer to in this publication: https://pubs.aip.org/aip/jcp/article/154/19/191101/565890I’ll reply to your next message as a separate postBest on sorry for the delay again Sam Sent from my iPhoneOn 31 May 2024, at 10:47, Jelle Lagerweij @.***> wrote: Dear Samuel, I have been very interested in your research regarding "force rdf" calculations and implemented my own version to postprocess reaction properties from AIMD simultions in VASP. Your code majorly inspired me and of course it will be cited adequately. I do have a question though, you rely on dtype=np.longdouble, is there a specific reason that you did not use a np.float64 here? Normally, I would avoid the longdouble as it is very badly defined and depends on the os of the computer. I tried to calculate the forcerdf with both and had very similar results. Could you explain why you selected the longdoubles? I did notice that there seems to be an accumulation of rounding errors in both the "from zero" and the "from infinity" (or better L/2) cases. It mostly seems to occur in very steep parts of the rdf. Is this reduced when using longdoubles? I added a plot below where I have the rdf of the atoms inside a water molecule (you can derive the shape of the molecule from this). This plot shows this error clearly while the oxygen-oxygen rdf (now show) does not have this problem at all. Using the reduced covariance method really solved this issue, so I am using that one now. Thanks in advance and kind regards, Jelle Lagerweij rdf_water.png (view on web)

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

user200000 commented 1 month ago

Hello JelleSo the temperature was something I looked into when I was looking at the delta offset. I found little computational difference between the two.The method is derived using the average temperature (free of fluctuations) and so Benjamin and I felt it was more proper to do this.I Hope this helpsPlease feel free to ask any further questions, if you’d like to discuss any of the science in more detail you should be able to find my professional email on the Cambridge university website. I’m in the ice group at the department of chemistry Have a nice daySamSent from my iPhoneOn 20 Jun 2024, at 15:26, Jelle Lagerweij @.**> wrote: I have a second question regarding the fundamentals of your method. The rescale factor contains the temperature and some physical constants. In my code, I use rescale1 = 8np.pi(co.k/co.eV)self.T_set and you have something similar: accumulated_storage_array=prefactor/(4np.pilen(to_run)generate_boltzmann(TS.units)*temp) (you do some of the rescaling in a different order so some terms you have in the prefactor are in my rescale1 ect.). My question is regarding the temperature, I run MD simulations, so I have fluctuating temperatures. Would you advise using the instantaneous temperature of the specific time step or the average temperature? I loop over many time steps and average and rescale my rdf afterward. Now I am using my average temperature, but I got unsure about this. Maybe you can shed some light on my questions. Thanks in advance, Jelle

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>