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. 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. 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? -- Sikandar On Tue, Nov 20, 2018 at 3:28 AM 'Andrey Brukhno' via votca < [email protected]> 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]. > 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.
