wl changelog

• 2019/11/04 (今日有两个重要发现) 1. (记住结论: 关于ratioree的误差, 提升perbin即可, 这可以放到prod去做, 当然mc move采样有硬伤perbin加大也很明显的case不行. 而norm阶段目标是快速准确得到DOS: 基于此, 20180101 zaxisfree保持; 使用 20191103 reptate_tether(对这个体系, 本身ratioree不好采样, norm iter最后几次ratioree仍有涨落差异, 最终prod多跑几个样本计算error bar即可, 想要进一步减小涨落只能未来考虑广义系综; 而且tether体系可以尝试不选w-3.0, 选w-5.0更好算而且要研究tether effect也更合理): 2019110x代码在最后几次迭代ratioree较为平滑一致的前提下, 哪个norm阶段收敛快用哪个.

• 此条在实战中有提升有降低, 据具体confine width而定, 不同width最优的mixMC ratio可能有差异. 计算结果中, iter ratioree有差异, 20180101更稳定(其实也依赖于perbin,这样看, 虽然20180102总耗时更少, 但要达到同样的ratioree迭代稳定度, 20180102可能总耗时更多). 而rw Cv 两种代码差异不明显. 有些案例虽然单个mcstep耗时减少, 但每次iter的mcstep相对增多且更不稳定, 以后或可尝试适当增多mcstep中一些mv的次数, 可能单次耗时总的mcstep以及耗时反而减少. zaxisfree还是保持20180101代码, 只调mix_reptate数值还是不单独开一个新版本代码了) 发现可以调节mix_reptate ratio, 比如20191104 reptate_tether代码, mix_reptate 从N降到sqrt(N), 查看energy log发现采样效率反而提升, 而且计算用时更少. 赶紧试试对之前20180101 zaxisfree代码改进mix_reptate, 得到的20180102仅仅也是把mix_reptate 从N降到sqrt(N), 查看energy log发现也有类似效果, 棒! 而且vmd查看采样到的构象, 很容易就发现backfold Odijk结构, 棒! 之前mix_reptate=N时的结构反而皱皱巴巴的. 2. 发现对于tether体系写代码, 可以区分两种情形, 一种tether site, 还是可以用改进的reptate_tether明显提升采样效率, 再配合1中的mix_reptate优化. 另一种tether on plane, 或许就不能用reptate, 有待未来做到tether on plane时再试.

• 2018/01/01 20180101的代码中, 优化了mc updates fraction, 删去不必要的mc update, 结果提升了采样效率(相同mcstep, energy traj变动更剧烈), 并且相比之前, 整个程序的收敛时间缩短了.
  counr_num_tgt的初始化也改正了:
  bak.free-semiflexible-hardsphere.20180101.tar.gz
  bak.zaxisfree-semiflexible-hardsphere.20180101.tar.gz

• 之前几乎所有的代码中, count_num_tgt(i)的初始化都有bug, 此数组0:level_2nd, 初始化时却1:chainlength
  之前并未暴露此bug, 因为只在prod时计算count_num_tgt, 虽然count_num_tgt初始化有bug, 但在声明count_num_tgt时即已初始化, 并且之前prod都只是跑一次迭代(iter.24), 所以此bug未暴露, 结果也未受影响.

• 代码2017-12-15 v6之前的代码, 凡是包含array_xyz_in_wall(涉及到system under confinement体系的代码), 都需要修正初始化bug, 后果是move_pivot, crank_shaft在程序中几乎没有起作用, 对结构的sampling效果可能差些. free chain代码中无此bug (不涉及in_wall相关的东西).

• 代码2017-11-28(也在开发中, 还未最终发布) 之前的涉及到WCA或者hardsphere的代码, 计算的coor, SID的结果不具有参考价值. 因为里面的if嵌套, 先 < rc 再 < rcut_coor, 但对WCA, hardsphere并不适用, 在2017-11-28 cell-list代码修改时, 对此处进行了修改, 改为两个独立if, 并且 dist > 0 (默认pairdist设为-1.0).

• 2017/11/27 笔记本上测试, fortran二维数组赋值(无论统一初值还是各个元素不一样的值), 统一向量化赋值不如双重循环快.

• 2017/11/23 除了cluster-WL-code.fixed-cluster-pcf-bug.20170707.tar.gz 之外, 其它的代码(之前的chain以及基于此, 最近开发的semiflexible chain), 都有一个bug, 有时会产生错误: 每次对一帧构型计算pcf(calc_single_pcf), sum_pcf_num_xx 都进行一次初始化: sum_pcf_num_xx = 0
  有时, 所有粒子对的距离都大于rcut, 这时依然是sum_pcf_num_xx = 0,
  如果还计算dble(pcf_num_xx(i))/dble(sum_pcf_num_xx)
  会使得pcf 3d 的第三列为NaN
  解决办法:
  :::fortran
  sub calc_group_pcf 中: 添加判断 sum_pcf_num_xx是否为0的if语句

:::fortran
if (sum_pcf_num_xx /= 0) then
do i=0, reachbin_idx(1)
pcf_xx(i) = dble(pcf_num_xx(i))/dble(sum_pcf_num_xx)
enddo
endif

• 2017/07/06 发现wl cluster中的一个bug, 会使得pcf计算出现无穷大 NaN, 已找到方法避免, 打包备份cluster-WL-code.fixed-cluster-pcf-bug.20170707.tar.gz
  目前是一个基本的, 能跑起来, 结果正确与MD对照的cluster-WL程序. 未来还会在此基础上开发, 添加功能, 增大可算的尺寸.

• 2017/03/20 cluster-WL-code.add-single-particle-moves.20170320.tar.gz (lj2nn, 可用一个模板f90设定参数后编译出对应n的执行程序)

• 2016/09/xx (2016/05/xx有一个eip初始化bug, 已经在2016/09/xx中修正) lj2nn wl chain sidmap (主要是homo, 但hetero也可用, 并且2016/09 修正了6-3 eip的一个初始化bug), 是多个独立的程序, 还没有改造成从一个模板f90编译

• 2015/04/15 wl chain hetero 程序 (无完整sidmap功能, 但可计算基态百分数; 后继10-10程序可以计算最低10个能级的各态百分数. 功能有些记不清了, 回去仔细看当时的输出文件4-17-2015)