Hi Christoph,

On Wednesday, May 2, 2018 at 9:29:51 PM UTC-4, Christoph Junghans wrote:
>
> On Wed, May 2, 2018 at 4:37 PM, Alexander Alexander 
> <[email protected] <javascript:>> wrote: 
> > Thanks. 
> > 
> > On Wednesday, May 2, 2018 at 5:54:50 PM UTC-4, Christoph Junghans wrote: 
> >> 
> >> On Wed, May 2, 2018 at 3:37 PM, Alexander Alexander 
> >> <[email protected]> wrote: 
> >> > Hi Christoph, 
> >> > Thanks. 
> >> > 
> >> > On Wednesday, May 2, 2018 at 5:13:13 PM UTC-4, Christoph Junghans 
> wrote: 
> >> >> 
> >> >> On Wed, May 2, 2018 at 1:38 PM, Alexander Alexander 
> >> >> <[email protected]> wrote: 
> >> >> > Dear all, 
> >> >> > I did a 
> >> >> > My IBI-bonded-nonbonded (after getting the nonbonded potentials 
> via 
> >> >> > IBI-nonbonded only) crashes dues to the "...bonded interactions 
> could 
> >> >> > not be 
> >> >> > calculated because some atoms 
> >> >> > involved moved further apart ...". By replacing the ill-bond by a 
> >> >> > harmonic 
> >> >> > potential in topol.top file "2 3   N  0.3453  K" where N = 1,2 and 
> K 
> >> >> > = 
> >> >> > 5000, 
> >> >> > the simulation are going well. Now what? what is the relation 
> between 
> >> >> > this 
> >> >> > harmonic  and the table_b2.xvg which was replaced by the harmonic 
> >> >> > one? 
> >> >> > What 
> >> >> > would happen for the table_b2.xvg? 
> >> >> Sorry, I don't understand your question! Can you rephrase? 
> >> >> 
> >> > Let's say the calculation crashes when table_b2.xvg is used but it 
> works 
> >> > fine with "2 3   2  0.3453  1000" instead, then my question is that 
> >> > "should 
> >> > I continue the preregistration using "2 3   2  0.3453  1000" and 
> forget 
> >> > about the table_b2.xvg? If so, what would be the final right 
> >> > table_b2.xvg at 
> >> > the end? If not so, how I can take benefit from the knowledge of  "2 
> 3 
> >> > 2 
> >> > 0.3453  1000" to improve the table_b2.xvg so that it would work as 
> well? 
> >> You know generate a table with k*(r-r_0) (with r_0=0.3453 andk=1000, 
> >> clip out the middle part and replace it with the structured part from 
> >> BI.  
>
>> 
> > OK, I see. 
> > How about this instead: 
> > The reason that the calculation crashes with table_b2.xvg is that the 
> > table_b2.xvg represents a very low K (spring constant) so that the two 
> atoms 
> > are getting apart. I was reading somewhere in the mailing list that the 
> last 
> > number in "2 3   8  2  1  ; 1:bond-H1-L:1" is a kind of factor for the 
> third 
> > column of the table_b2.xvg, so, don't you think it would be possible to 
> > increase this factor to 2 or 3 (which means multiplying the third 
> column) 
> > until the calculation goes fine? 
> Yeah, that sounds reasonable! Increasing the K helps usually helps 
> with the atoms getting too far apart. 
>
> If you want to scale column 3 you will also have to modify column 2 
> accordingly. 
> Gromacs won't allow mismatching columns. 
>
I tried to scale both of the column 2 and 3 of table_b2.xvg using a lot of 
scale-factor, but they did not work and the missing bond ... error is still 
here., I guess finding the right factor is not easy. 
So, I tried your suggestion above, I mean k*(r-r_0) (with r_0=0.3453 
andk=1000. T do so, I first created a bond.pot.ib potential including 3 
columns as following:
#-----------------
bond.pot.in
#column1          #column2                          # column3
r                (1000/2)*(r-0.3453)^2         -(1000)*(r-0.3453)
#-------------------
And added the letter "i" to the end of each row.
Then I tried to converted the above bond.pot.in to table_b2.xvg using 
"csg_call --ia-type bond --ia-name bond-H1-L --options bond-H1-L.xml 
convert_potential gromacs ...". But then all of the second and third 
columns of the new table_b2.xvg was just nan -nan.
Would you please let me know if the procedure is right and where I am doing 
wrong? 

Thank you.
Alex

>> 
> >> 
> >> > 
> >> >> 
> >> >> > Figures in attachment are the plot of 
> >> >> > table_b2.xvg. 
> >> >> > I got the bonded tables including the table_b2.xvg by 
> "csg_boltzmann" 
> >> >> > --> 
> >> >> > "csg_call --sloppy-tables" ---> "csg_call --ia-type bond --ia-name 
> >> >> > bond 
> >> >> > ... 
> >> >> > gromacs table_b2.xvg". And I am using the bond(angle)-*.pot.in as 
> >> >> > initial 
> >> >> > guesses for my IBI-all. 
> >> >> > 
> >> >> > The table_b1.xvg in gromacs manual has been defined such that the 
> the 
> >> >> > r(nm), 
> >> >> > f(r), f'(r) are the first, second and third column of table_b2.xvg 
> >> >> > where 
> >> >> > f(r) is a cubic spline function in V_b(r_ij) = k*f(r_ij), If the 
> same 
> >> >> > definition is applied for the table_b2.xvg obtained by the above 
> >> >> > method? 
> >> >> To be clear, the gromacs table format is x, f(x), -f'(x) (see 
> gromacs 
> >> >> manual 4.2.14) 
> >> >> 
> >> >> I am not sure what your question is! Gromacs uses cubic spline 
> >> >> internal to interpolate  the table. 
> >> >> However, if you set cg.inverse.gromacs.table_bins in your xml file 
> >> >> small enough (you had something like 0.002), then there isn't much 
> to 
> >> >> interpolate. 
> >> >> 
> >> >> 
> >> >> > What is the unit of f(r)? 
> >> >> KJ/mol (gromacs energy units) 
> >> >> 
> >> >> > What is the unit of each column in table_b2.xvg in VOTCA? 
> >> >> KJ/mol/nm (gromacs force units) 
> >> > 
> >> > Just to sum up the table format, can you please confirm me that the 
> >> > table_b.xvg in VOTCA has the following format: 
> >> > first column : Distance with unit nm 
> >> > Second column : Energy with unit KJ/mol 
> >> > Thirst column: Force with unit KJ/mol/nm 
> >> For bonds (not angles) in gromacs that is the format! 
> > 
> > For angle the first column is degree probably. 
> >> 
> >> 
> >> Also for a different simulation backend, e.g. lammps this will be 
> >> different of course, too! 
> > 
> > 
> > I have one more question which your comment on would be highly 
> appreciated: 
> > In another IBI-bonded-nonbonded parameterization the "mpirun -np 64 
> gmx_mpi 
> > mdrun" work fine till step_021 of parameterization where it crashes 
> because 
> > it can not find any domain decomposition for 64 ranks that is compatible 
> > with the system size. Even it works in the minimization simulation in 
> > step_021. 
> > I have already read most of the discussions about the error of domain 
> > decomposition, and I have tried different options like using different 
> ranks 
> > (64, 32, 16, 8, 40, 36) and also -rdd ... or -dds. However, no success 
> yet. 
> > I am totally confused with these parameters and I can not solve the 
> issue. 
> > So, below I have shared the md.log files for the step_20 (which works 
> fine) 
> > and step_21 (minimization which works fine) and step_21 (which crashes), 
> and 
> > I would be so appreciated if one could help me overcome the issue. 
> > About the machine: Running on 4 nodes with total 64 cores, 64 logical 
> cores, 
> > Cores per node: 16. 
> > 
> > md.log-20 
> > https://drive.google.com/open?id=1ZwYggDI1Hy_eYY8_nT8I50t91Wla0Obr 
> > 
> > md.log-21-mini 
> > https://drive.google.com/open?id=1oYE4A6fC1L8u_vx4sR8RIq3EWiG9-7YB 
> > 
> > md.log-21 
> > https://drive.google.com/open?id=1ff_QJrdGvLFgwGU9xMY-IcqfxzF2jkAO 
> Sorry, that really is a question for the gromacs user mailing list. 
> ([email protected] <javascript:>) 
>
> Christoph 
>
> > 
> > 
> > Thank you very much. 
> > Regards, 
> > Alex 
> >> 
> >> 
> >> Christoph 
> >> >> 
> >> >> 
> >> >> > 
> >> >> > And would you please explain table_b2-1-3.png figure? 
> >> >> Not sure what there is to explain..the code on how the third column 
> is 
> >> >> calculated is here: 
> >> >> 
> >> >> 
> >> >> 
> https://github.com/votca/csg/blob/master/share/scripts/inverse/table_to_xvg.pl#L95
>  
> >> > 
> >> > Best regards, 
> >> > Alex 
> >> >> 
> >> >> 
> >> >> Christoph 
> >> >> 
> >> >> > Thank you very much. 
> >> >> > Regards, 
> >> >> > Alex 
> >> >> > 
> >> >> > -- 
> >> >> > 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. 
> >> 
> >> 
> >> 
> >> -- 
> >> 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] <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. 
>
>
>
> -- 
> 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.

Reply via email to