Hi Sikandar. Thanks for the insights. I am replying below.
On Sunday, December 2, 2018 at 4:56:06 AM UTC, sikandar wrote: > > Hi Andrey, > > Sorry for the late reply. I am traveling so I could not reply sooner. > > In regards to your question about discrepancies between CG-CG.param.init > and CG-CG.pot.new in Step_000, the difference is due to the definition of > the uniform cubic B-Spline functional form; see Eqs. 3.1 and 3.2 in Ref. > https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0131754#authcontrib > > . CG-CG.param.init are considered as knot-values, c_{i}, for the B-Spline > form, which are not the same as the potential values, u_{i}. Therefore, > CG-CG.param.init and CG-CG.pot.new > are not exactly the same. > - I understand that *.param.init files contain the potential input data on the knot grid which is coarser than the working interpolation grid in *.pot.new files. Of course I did not expect the two data sets to be exactly the same. But I would still expect the B-spline interpolation not to introduce noticeable systematic shifts in different x-regions, which it does apparently. From your explanation I gather it is normal with B-splines, as this type of interpolation does not go through, and hence does not preserve, the data values on the coarser grid (knots). > For example, in your CG1-CG1.param.init file with uniform spacing, \Delta > r, of 0.02, for i = 26, r_i = 0.5, c_i = -3.3745224. If you evaluate u_i > for i = 26 using the above B-Spline form, you get u(r=0.5) = -3.351, which > is not same as c(r=0.5)= -3.3745224 given in the CG1-CG1.param.init. This > explains the difference between your CG-CG.param.init and CG-CG.pot.new > plots. > - I suppose my next question is, what is (if there exist) the optimal procedure to choose the knot values (both the grid and the data)? Up to now I used the potential values produced by IBI on a uniform grid where I skipped intermediate x-bins between the knots. That is, the following sequence of data transformations occurs: *.pot.cur (IBI fine grid) -> *.param.init (coarser grid/knots) -> *.pot.new (interpolated at RE step_000) -> *.pot.cur & tables (prepared for a CG run at RE step_001). - Would I improve the resulting B-spline interpolation if I have chosen a non-uniform knot spacing, say more tight at shorter distances where the gradients are higher (if VOTCA allows that at all)? > In regards to Hessian Not Positive Definite Error, first check the CG-CG > RDFs computed in the Step_000. These should be very close to those obtained > from IBI since your initial potential guess is from IBI. Could you please > check the RDFs in Step_000? > - This is precisely the root of the problem! The RDFs produced at the very first RE iteration step (step_001) using the B-spline interpolated tables differ considerably from those obtained earlier with IBI (with the potential set that I used for seeding the RE iteration. I am pretty sure this is because the B-spline interpolated data for potentials (i.e. data sets and tables produced at step_000 and then fed to step_001) consideraby deviate from the original data obtained with IBI. Is there any room for improvement in my preparation procedure? Thanks Andrey > -- > Sikandar > > > > On Tue, Nov 20, 2018 at 3:28 AM 'Andrey Brukhno' via votca < > [email protected] <javascript:>> wrote: > >> Hi Sikandar, >> >> Sorry for the delay. Attached is the ZIP file containing the data: >> >> CG1-CG1.pot.in & CG1-CG2.pot.in - the original data obtained with IBI >> earlier; >> CG1-CG1.param.init & CG1-CG2.param.init - the above data interpolated >> onto coarser grid with cubic splines. >> >> I tried to run an RE iteration starting with the latter two files >> (actually 10 potentials in total) and using B-splines but ran into the >> systematic errors with csg_reupdate, as I reported previously. >> >> Thanks for looking into it. >> Andrey >> >> Below is a relevant extract from my settiings.xml (it is same for the >> second interaction): >> ----------------------- >> <non-bonded> >> <!-- name of the interaction --> >> <name>CG1-CG1</name> >> <!-- types involved in this interaction --> >> <type1>CG1</type1> >> <type2>CG1</type2> >> <!-- dimension + grid spacing of tables for calculations --> >> <min>0</min> >> <max>1.66</max> >> <step>0.005</step> >> <re> >> <!-- function>cbspl or lj126</function--> >> <function>cbspl</function> >> <cbspl> >> <nknots>84</nknots> >> <core>extrapolate</core> >> </cbspl> >> </re> >> <inverse> >> <!-- target distribution (rdf), just give gromas rdf.xvg --> >> <target>TCH-TCH.dist.tgt</target> >> <!-- update cycles --> >> <!--do_potential>1</do_potential--> >> <do_potential>1 0 0</do_potential> >> <!-- additional post processing of dU before added to potential --> >> <!--post_update></post_update--> >> <post_update>smooth</post_update> >> <!-- some options for the post update scripts --> >> <post_update_options> >> <!--scale>0.10</scale--> >> <smooth> >> <iterations>3</iterations> >> </smooth> >> </post_update_options> >> <!-- additional post processing of U after dU added to potential --> >> <!--post_add>acc_convergence average</post_add--> >> <post_add>acc_convergence average</post_add> >> <post_add_options> >> <!-- convergence check options --> >> <convergence> >> <!-- for RE we check change in potentials/parameters (new-cur) >> --> >> <what>pot</what> >> <weight>1.0</weight> >> <base>cur</base> >> <norm>2</norm> >> </convergence> >> <average> >> <what>param pot</what> >> </average> >> </post_add_options> >> <!-- name of the table for gromacs run --> >> <gromacs> >> <table>table_CG1_CG1.xvg</table> >> </gromacs> >> </inverse> >> </non-bonded> >> >> ----------------------- >> >> >> On Friday, November 16, 2018 at 6:49:21 PM UTC, sikandar wrote: >>> >>> Hi Andrey, >>> >>> Could you please send me the raw data of your plots? >>> >>> Thanks, >>> Sikandar >>> >>> On Tue, Nov 13, 2018 at 4:32 PM 'Andrey Brukhno' via votca < >>> [email protected]> wrote: >>> >>>> Hi Sikandar, >>>> >>>> I have tried different ranges and different number of knots in the >>>> initial data for CG-CG param.init files, yet I am getting obvious >>>> discrepancies between the data provided and the data generated by >>>> csg_reupdate for CG-CG.pot.new at the veryy beginning of the RE iteration, >>>> i.e. at step_000. >>>> >>>> Please check the new graph attached, exemplifying that the shifts along >>>> x-axis can be far from trivial (as opposed to what I thought before based >>>> on my first hands-on attempt). Clearly, the interpolated data (dashed >>>> lines) are not usable for a reliable RE iteration. I have 10 different >>>> potential types and all of them are skewed like that by csg_reupdate. >>>> >>>> I still hope that I am missing something which should be corrected in >>>> my input, and that it is not a typical interpolation behaviour with >>>> B-splines. >>>> >>>> Could you comment on this, please. >>>> >>>> Thanks >>>> Andrey >>>> >>>> On Monday, July 23, 2018 at 5:45:29 PM UTC+1, sikandar wrote: >>>>> >>>>> Hi Andrey, >>>>> >>>>> What do the lines in your plot correspond to? Are you plotting >>>>> param.init vs the potential computed from them? If so, the knot values in >>>>> parameter file and the potential are not the same. Please see Eq. 3.1 >>>>> from >>>>> http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0131754 >>>>> . >>>>> >>>>> Let me know if I missed anything. >>>>> >>>>> -- >>>>> Sikandar >>>>> >>>>> On Mon, Jul 23, 2018 at 9:11 AM Christoph Junghans <[email protected]> >>>>> wrote: >>>>> >>>>>> On Mon, Jul 23, 2018 at 9:28 AM, 'Andrey Brukhno' via votca >>>>>> <[email protected]> wrote: >>>>>> > Any comment on this "shift" issue? >>>>>> > I tried to find the relevant script in share/votca/scripts/inverse >>>>>> but it >>>>>> > seems that all interpolation is done by `csg_reupdate' app, and I >>>>>> didn't >>>>>> > have time up to now to look into the code. >>>>>> No idea, that is more a question for Sikandar! >>>>>> >>>>>> > >>>>>> > Thanks! / Andrey >>>>>> > >>>>>> > On Friday, July 20, 2018 at 11:59:37 AM UTC+1, Andrey Brukhno wrote: >>>>>> >> >>>>>> >> ... >>>>>> >> As a matter of fact, the problem appears to be not a poor >>>>>> interpolation >>>>>> >> but a systematic shift in the X axis (by the size of the grid bin >>>>>> in the >>>>>> >> original data, i. e. param.init files) - see the corrected graph >>>>>> where I >>>>>> >> simply shifted all the interpolation curves by dx=0.02. >>>>>> >> >>>>>> >> So I conclude that something is fishy about the x column in the >>>>>> pot.cur >>>>>> >> files. >>>>>> >> >>>>>> >> Andrey >>>>>> >> >>>>>> >> On Friday, July 20, 2018 at 11:45:27 AM UTC+1, Andrey Brukhno >>>>>> wrote: >>>>>> >>> >>>>>> >>> Hi Christoph & Sikandar, >>>>>> >>> >>>>>> >>> Thank you both for your replies! >>>>>> >>> >>>>>> >>> Per your suggestions, I have compared the potentials generated >>>>>> (i.e. >>>>>> >>> B-spline interpolated) based on the initial guesses provided as >>>>>> >>> CGi-CGj.param.init files with the original data (i.e. the >>>>>> contents of those >>>>>> >>> param.init files). I found systematic discrepancies (see the >>>>>> attached graph, >>>>>> >>> where only 3 potentials shown)! - No wonder I am getting into >>>>>> trouble after >>>>>> >>> a new simulation with the potentials being that much off, >>>>>> especially at >>>>>> >>> shorter distances. >>>>>> >>> >>>>>> >>> Is it normal to have such large differences with the interpolated >>>>>> data? >>>>>> >>> I would think that there must be a way to improve on the >>>>>> interpolation by >>>>>> >>> varying something in the input - ? >>>>>> >>> Is it where the LJ repulsive core would help? (Although I think >>>>>> that >>>>>> >>> would be an ad hoc workaround for the poor interpolation issue.) >>>>>> >>> >>>>>> >>> It seems I still need your advice here, based on your practical >>>>>> >>> experience. >>>>>> >>> >>>>>> >>> Andrey >>>>>> >>> >>>>>> >>> On Friday, July 20, 2018 at 7:39:45 AM UTC+1, sikandar wrote: >>>>>> >>>> >>>>>> >>>> Hi Andrey, >>>>>> >>>> >>>>>> >>>> Below are some of the things you can try to address this issue. >>>>>> >>>> >>>>>> >>>> 1. Make sure the potentials generated from your initial >>>>>> parameters are >>>>>> >>>> physically consistent >>>>>> >>>> 2. Increase number of timesteps in CG simulation >>>>>> >>>> 3. Decrease the scaling parameter >>>>>> >>>> 4. If your CG system has charges, then you may need to add a LJ >>>>>> type >>>>>> >>>> potential to your CBSPL CG potential after every CG update to >>>>>> ensure that >>>>>> >>>> the CG potential is repulsive enough at short distances and does >>>>>> not allow >>>>>> >>>> overlap of oppositely charged sites. You can enable this option >>>>>> by >>>>>> >>>> specifying post_update block for every CG potential pair as >>>>>> >>>> <non-bonded> >>>>>> >>>> ... >>>>>> >>>> <post_update>lj</post_update> >>>>>> >>>> <post_update_options> >>>>>> >>>> <lj> >>>>>> >>>> <c6> LJ C6 Value </c6> >>>>>> >>>> <c12> LJ C12 Value </c12> >>>>>> >>>> </lj> >>>>>> >>>> </post_update_options> >>>>>> >>>> ... >>>>>> >>>> </non-bonded> >>>>>> >>>> >>>>>> >>>> I hope this helps. >>>>>> >>>> >>>>>> >>>> Best, >>>>>> >>>> Sikandar >>>>>> >>>> >>>>>> >>>> On Thu, Jul 19, 2018 at 6:13 PM Christoph Junghans < >>>>>> [email protected]> >>>>>> >>>> wrote: >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> On Thu, Jul 19, 2018 at 18:15 'Andrey Brukhno' via votca >>>>>> >>>>> <[email protected]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> >>>>>> >>>>>> I managed to run the RE iteration for a system with 10 >>>>>> non-bonded >>>>>> >>>>>> potentials (types).. well, the first iteration anyway, where >>>>>> it terminated >>>>>> >>>>>> after about an hour of running csg_reupdate with the following >>>>>> error: >>>>>> >>>>>> >>>>>> >>>>>> Hessian NOT a positive definite! >>>>>> >>>>>> This can be a result of poor initial guess or ill-suited CG >>>>>> potential >>>>>> >>>>>> settings or poor CG sampling. >>>>>> >>>>>> >>>>>> >>>>>> My understanding is, sometimes this might happen, but this was >>>>>> my >>>>>> >>>>>> second trial where I virtually doubled (44 -> 88) the number >>>>>> of knots and >>>>>> >>>>>> (in both cases) I use potentials derived from an earlier IBI >>>>>> iteration. >>>>>> >>>>>> >>>>>> >>>>>> I would really appreciate clues, hints or general advice as to >>>>>> how to >>>>>> >>>>>> alleviate the issue. >>>>>> >>>>> >>>>>> >>>>> Sikandar will know more, but most likely you will need to throw >>>>>> away >>>>>> >>>>> some frames at the beginning of the trajectory and run the >>>>>> iterations for a >>>>>> >>>>> bit longer! >>>>>> >>>>> >>>>>> >>>>> Christoph >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Andrey >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> You received this message because you are subscribed to the >>>>>> Google >>>>>> >>>>>> Groups "votca" group. >>>>>> >>>>>> To unsubscribe from this group and stop receiving emails from >>>>>> it, send >>>>>> >>>>>> an email to [email protected]. >>>>>> >>>>>> To post to this group, send email to [email protected]. >>>>>> >>>>>> Visit this group at https://groups.google.com/group/votca. >>>>>> >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>>> >>>>> -- >>>>>> >>>>> Christoph Junghans >>>>>> >>>>> Web: http://www.compphys.de >>>>>> >>>>> >>>>>> >>>>> -- >>>>>> >>>>> You received this message because you are subscribed to the >>>>>> Google >>>>>> >>>>> Groups "votca" group. >>>>>> >>>>> To unsubscribe from this group and stop receiving emails from >>>>>> it, send >>>>>> >>>>> an email to [email protected]. >>>>>> >>>>> To post to this group, send email to [email protected]. >>>>>> >>>>> Visit this group at https://groups.google.com/group/votca. >>>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> > >>>>>> > -- >>>>>> > You received this message because you are subscribed to the Google >>>>>> Groups >>>>>> > "votca" group. >>>>>> > To unsubscribe from this group and stop receiving emails from it, >>>>>> send an >>>>>> > email to [email protected]. >>>>>> > To post to this group, send email to [email protected]. >>>>>> > Visit this group at https://groups.google.com/group/votca. >>>>>> > For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Christoph Junghans >>>>>> Web: http://www.compphys.de >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "votca" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To post to this group, send email to [email protected]. >>>>>> Visit this group at https://groups.google.com/group/votca. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "votca" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at https://groups.google.com/group/votca. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "votca" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] <javascript:> >> . >> Visit this group at https://groups.google.com/group/votca. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "votca" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/votca. For more options, visit https://groups.google.com/d/optout.
