Re: [votca] Hessian NOT a positive definite!

['Andrey Brukhno' via votca]

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 <
> vo...@googlegroups.com > 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):
>> ---
>>   
>> 
>> CG1-CG1
>> 
>> CG1
>> CG1
>> 
>> 0
>> 1.66
>> 0.005
>>   
>> 
>> cbspl
>> 
>> 84
>> extrapolate
>> 
>>   
>> 
>>   
>>   TCH-TCH.dist.tgt
>>   
>>   
>>   1 0 0
>>   
>>   
>>   smooth
>>   
>>   
>> 
>> 
>>   3
>> 
>>   
>>   
>>   
>>   acc_conve

Re: [votca] Hessian NOT a positive definite!

['Andrey Brukhno' via votca]

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):
---
  

CG1-CG1

CG1
CG1

0
1.66
0.005
  

cbspl

84
extrapolate

  

  
  TCH-TCH.dist.tgt
  
  
  1 0 0
  
  
  smooth
  
  


  3

  
  
  
  acc_convergence average
  


  
  pot
  1.0
  cur
  2


  param pot

  
  
  
table_CG1_CG1.xvg
  

  

---


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 <
> vo...@googlegroups.com > 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  
>>> wrote:
>>>
>>>> On Mon, Jul 23, 2018 at 9:28 AM, 'Andrey Brukhno' via votca
>>>>  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 

Re: [votca] Hessian NOT a positive definite!

['Andrey Brukhno' via votca]

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  > wrote:
>
>> On Mon, Jul 23, 2018 at 9:28 AM, 'Andrey Brukhno' via votca
>> > 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 ensu

Re: [votca] libhdf5.so

['Andrey Brukhno' via votca]

On Sat, Sep 8, 2018 at 8:08 PM Christoph Junghans 
wrote:

>
> On Sat, Sep 8, 2018 at 12:52 'Andrey Brukhno' via votca <
> votca@googlegroups.com> wrote:
>
>>
>> On Saturday, September 8, 2018 at 7:40:43 PM UTC+1, Christoph Junghans
>> wrote:
>>>
>>>
>>> On Sat, Sep 8, 2018 at 11:58 'Andrey Brukhno' via votca <
>>> vo...@googlegroups.com> wrote:
>>>
>>>>
>>>> On Saturday, September 8, 2018 at 6:42:03 PM UTC+1, Christoph Junghans
>>>> wrote:
>>>>
>>>
>>>>> Just for completeness, I did try to update my LD_LIBRARY_PATH
>>>>> including both standard and non-standard locations for the related lib
>>>>> files. However, I still see the following in the cmake report, where I
>>>>> flagged all the supposedly relevant lines with triple asterisk ***
>>>>>
>>>> ...
>>>> *-- Found HDF5:
>>>> /home/andrey/anaconda2/lib/libhdf5.so;/usr/lib/x86_64-linux-gnu/librt.so;/usr/lib/x86_64-linux-gnu/libpthread.so;/home/andrey/anaconda2/lib/libz.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libm.so
>>>> (found version "1.10.1")  
>>>> -- Could NOT find GMX (missing:  GMX_EXECUTABLE)
>>>> -- Boost version: 1.58.0
>>>> -- Found the following Boost libraries:
>>>> --   program_options
>>>> -- Checking for module 'libvotca_tools'
>>>> --   No package 'libvotca_tools' found
>>>> -- Intel(R) MKL could not be found.
>>>> -- Checking for module 'libvotca_csg'
>>>> --   No package 'libvotca_csg' found
>>>> -- Found VOTCA_CSG: votca_csg
>>>> *-- Could NOT find CLANG_FORMAT (missing:  CLANG_FORMAT_EXECUTABLE) 
>>>> --
>>>> -- The following OPTIONAL packages have been found:
>>>>
>>>>  * Git
>>>>  * FFTW3
>>>>  * EXPAT
>>>>  * TXT2TAGS
>>>>  * UnixCommands
>>>>  ** HDF5 
>>>>  * Eigen3
>>>>  * PkgConfig
>>>>  * Doxygen
>>>> ---
>>>>
>>>> I have two questions regarding the above.
>>>>
>>>> 1. Is the line complaining about not found CLANG_FORMAT related in any
>>>> way to the libhdf5?
>>>>
>>> No, that is just another things which didn’t get found, but it is also
>>> optional!
>>>
>>
>> OK! After reading a bit about HDF5 data objects I thought CLANG_FORMAT
>> might be an attribute in some data structure or container related to the C
>> language.
>>
>>
>>>
>>>> 2. Can it be that at the building time the libraries from different
>>>> sources are confused or mixed up somehow upon linking? (so that at run time
>>>> a wrong library is searched for)
>>>>
>>> Not sure what you mean! CMake uses the libraries it detects for building
>>> and linking. However, once you install things the Linux loader, ld, is in
>>> charge. You can check what it is trying to load by running: “ldd
>>> ”.
>>> For csg_map that will show a missing libhdf5 in your case.
>>> LD_LIBRARY_PATH is just a way to help ld find stuff.
>>>
>>
>> I asked this question because merely adding my non-standard location for
>> libhdf5.so (anaconda2/lib) to LD_LIBRARY_PATH did not resolve the issue. I
>> had to rebuild and re-install the whole thing, and only then the error
>> stopped popping up (which implies that it is not that simple as you
>> describe).
>>
>> Anyway it works now.
>>
> Cool, if you feel something needs to get added to installation guide,
> please propose a file change here:
> https://github.com/votca/votca/blob/master/share/doc/INSTALL.md
>

I am not sure what you mean here: adding the description for the flag
omitting hdf5? or the fact that one needs to add non-standard library
locations to the LD_LIBRARY_PATH and then recompile everything?

Andrey


> Christoph
>
>>
>> Andrey
>>
>>
>>>
>>> Christoph
>>>
>>>>
>>>> Andrey
>>>>
>>>>
>>>>> Christoph
>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Andrey
>>>>>>
>>>>>>
>>>>>> On Saturday, September 8, 2018 at 6:01:02 PM UTC+1, Christoph
>>>>>> Junghans wrote:
>>>>>>
>>>>>>> On Sat, Sep 8, 2018, 09:43 'Andrey Brukhno' vi

Re: [votca] libhdf5.so

['Andrey Brukhno' via votca]

On Saturday, September 8, 2018 at 7:40:43 PM UTC+1, Christoph Junghans 
wrote:
>
>
> On Sat, Sep 8, 2018 at 11:58 'Andrey Brukhno' via votca <
> vo...@googlegroups.com > wrote:
>
>>
>> On Saturday, September 8, 2018 at 6:42:03 PM UTC+1, Christoph Junghans 
>> wrote:
>>>
>>>
>>> Just for completeness, I did try to update my LD_LIBRARY_PATH including 
>>> both standard and non-standard locations for the related lib files. 
>>> However, I still see the following in the cmake report, where I flagged all 
>>> the supposedly relevant lines with triple asterisk ***
>>>
>> ...
>> *-- Found HDF5: 
>> /home/andrey/anaconda2/lib/libhdf5.so;/usr/lib/x86_64-linux-gnu/librt.so;/usr/lib/x86_64-linux-gnu/libpthread.so;/home/andrey/anaconda2/lib/libz.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libm.so
>>  
>> (found version "1.10.1")  
>> -- Could NOT find GMX (missing:  GMX_EXECUTABLE) 
>> -- Boost version: 1.58.0
>> -- Found the following Boost libraries:
>> --   program_options
>> -- Checking for module 'libvotca_tools'
>> --   No package 'libvotca_tools' found
>> -- Intel(R) MKL could not be found.
>> -- Checking for module 'libvotca_csg'
>> --   No package 'libvotca_csg' found
>> -- Found VOTCA_CSG: votca_csg  
>> *-- Could NOT find CLANG_FORMAT (missing:  CLANG_FORMAT_EXECUTABLE) 
>> -- 
>> -- The following OPTIONAL packages have been found:
>>
>>  * Git
>>  * FFTW3
>>  * EXPAT
>>  * TXT2TAGS
>>  * UnixCommands
>>  ** HDF5 
>>  * Eigen3
>>  * PkgConfig
>>  * Doxygen
>> ---
>>
>> I have two questions regarding the above.
>>
>> 1. Is the line complaining about not found CLANG_FORMAT related in any 
>> way to the libhdf5?
>>
> No, that is just another things which didn’t get found, but it is also 
> optional!
>

OK! After reading a bit about HDF5 data objects I thought CLANG_FORMAT 
might be an attribute in some data structure or container related to the C 
language.
 

>
>> 2. Can it be that at the building time the libraries from different 
>> sources are confused or mixed up somehow upon linking? (so that at run time 
>> a wrong library is searched for)
>>
> Not sure what you mean! CMake uses the libraries it detects for building 
> and linking. However, once you install things the Linux loader, ld, is in 
> charge. You can check what it is trying to load by running: “ldd 
> ”.
> For csg_map that will show a missing libhdf5 in your case. LD_LIBRARY_PATH 
> is just a way to help ld find stuff.
>

I asked this question because merely adding my non-standard location for 
libhdf5.so (anaconda2/lib) to LD_LIBRARY_PATH did not resolve the issue. I 
had to rebuild and re-install the whole thing, and only then the error 
stopped popping up (which implies that it is not that simple as you 
describe).

Anyway it works now.

Andrey
 

>
> Christoph 
>
>>
>> Andrey
>>
>>
>>> Christoph 
>>>
>>>>
>>>>
>>>> Thanks
>>>> Andrey
>>>>
>>>>
>>>> On Saturday, September 8, 2018 at 6:01:02 PM UTC+1, Christoph Junghans 
>>>> wrote:
>>>>
>>>>> On Sat, Sep 8, 2018, 09:43 'Andrey Brukhno' via votca <
>>>>> vo...@googlegroups.com> wrote:
>>>>>
>>>>>> Just to make sure, I have done it for the third time now, with the 
>>>>>> same result (error about libhdf5).
>>>>>> This is strange because the camke log reports it as found:
>>>>>>
>>>>>> $ grep HDF master-cmake.log
>>>>>> -- Found HDF5: 
>>>>>> /home/andrey/anaconda2/lib/libhdf5.so;/usr/lib/x86_64-linux-gnu/librt.so;/usr/lib/x86_64-linux-gnu/libpthread.so;/home/andrey/anaconda2/lib/libz.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libm.so
>>>>>>  
>>>>>> (found version "1.10.1") 
>>>>>>  * HDF5
>>>>>>
>>>>>> whereas the 'stable' branch does not require it, apparently; at least 
>>>>>> cmake does not report anything about libhdf5.
>>>>>>
>>>>> Yeah, in the stable branch the hdf5 I/O backend is off by default, 
>>>>> while it gets enabled automatically in master when an HDF5 library is 
>>>>> found! The code has matured enough since it was added in 1.4!
>>>>>
>>>>> There error is due to the fact that your libhdf5 is in non-common 
>

Re: [votca] libhdf5.so

['Andrey Brukhno' via votca]

After all, it did work and now I get no error when I tried csg_call, 
csg_map, csg_stat or csg_reupdate etc.
However it did complain all the way during installation:

cmake: /home/andrey/anaconda2/lib/libssl.so.1.0.0: no version information 
available (required by /usr/lib/x86_64-linux-gnu/libcurl.so.4)
cmake: /home/andrey/anaconda2/lib/libssl.so.1.0.0: no version information 
available (required by /usr/lib/x86_64-linux-gnu/libcurl.so.4)
cmake: /home/andrey/anaconda2/lib/libssl.so.1.0.0: no version information 
available (required by /usr/lib/x86_64-linux-gnu/libcurl.so.4)
cmake: /home/andrey/anaconda2/lib/libcrypto.so.1.0.0: no version 
information available (required by /usr/lib/x86_64-linux-gnu/libcurl.so.4)

Not sure how important it is though.

Thanks for your help!
Andrey

On Saturday, September 8, 2018 at 6:58:49 PM UTC+1, Andrey Brukhno wrote:
>
>
> On Saturday, September 8, 2018 at 6:42:03 PM UTC+1, Christoph Junghans 
> wrote:
>>
>>
>>
>> On Sat, Sep 8, 2018 at 11:24 'Andrey Brukhno' via votca <
>> vo...@googlegroups.com> wrote:
>>
>>> The question is, what is the significance of this library (libhdf5)? - 
>>> from what you say I gather, it is not required in general, but it is only 
>>> necessary if I myself indent to use hdf5 files/data (which obviously I am 
>>> not currently; unless it is used by VOTCA tools or scripts somewhere under 
>>> the hood - ?).
>>>
>> HDF5 is used to read H5MD files!
>>
>
> Alright, whatever.. I suppose it is from here: 
> https://support.hdfgroup.org/HDF5/Tutor/
>  
>
>>
>>
>>> Anyway, what is the cmake option to switch it off (I could not find it)?
>>>
>> -DCMAKE_DISABLE_FIND_PACKAGE_HDF5=ON
>>
>
> OK, thanks a lot!
>
> Just for completeness, I did try to update my LD_LIBRARY_PATH including 
> both standard and non-standard locations for the related lib files. 
> However, I still see the following in the cmake report, where I flagged all 
> the supposedly relevant lines with triple asterisk ***
> ...
> *-- Found HDF5: 
> /home/andrey/anaconda2/lib/libhdf5.so;/usr/lib/x86_64-linux-gnu/librt.so;/usr/lib/x86_64-linux-gnu/libpthread.so;/home/andrey/anaconda2/lib/libz.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libm.so
>  
> (found version "1.10.1")  
> -- Could NOT find GMX (missing:  GMX_EXECUTABLE) 
> -- Boost version: 1.58.0
> -- Found the following Boost libraries:
> --   program_options
> -- Checking for module 'libvotca_tools'
> --   No package 'libvotca_tools' found
> -- Intel(R) MKL could not be found.
> -- Checking for module 'libvotca_csg'
> --   No package 'libvotca_csg' found
> -- Found VOTCA_CSG: votca_csg  
> *-- Could NOT find CLANG_FORMAT (missing:  CLANG_FORMAT_EXECUTABLE) 
> -- 
> -- The following OPTIONAL packages have been found:
>
>  * Git
>  * FFTW3
>  * EXPAT
>  * TXT2TAGS
>  * UnixCommands
>  ** HDF5 
>  * Eigen3
>  * PkgConfig
>  * Doxygen
> ---
>
> I have two questions regarding the above.
>
> 1. Is the line complaining about not found CLANG_FORMAT related in any way 
> to the libhdf5?
>
> 2. Can it be that at the building time the libraries from different 
> sources are confused or mixed up somehow upon linking? (so that at run time 
> a wrong library is searched for)
>
> Andrey
>
>
>> Christoph 
>>
>>>
>>>
>>> Thanks
>>> Andrey
>>>
>>>
>>> On Saturday, September 8, 2018 at 6:01:02 PM UTC+1, Christoph Junghans 
>>> wrote:
>>>
>>>> On Sat, Sep 8, 2018, 09:43 'Andrey Brukhno' via votca <
>>>> vo...@googlegroups.com> wrote:
>>>>
>>>>> Just to make sure, I have done it for the third time now, with the 
>>>>> same result (error about libhdf5).
>>>>> This is strange because the camke log reports it as found:
>>>>>
>>>>> $ grep HDF master-cmake.log
>>>>> -- Found HDF5: 
>>>>> /home/andrey/anaconda2/lib/libhdf5.so;/usr/lib/x86_64-linux-gnu/librt.so;/usr/lib/x86_64-linux-gnu/libpthread.so;/home/andrey/anaconda2/lib/libz.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libm.so
>>>>>  
>>>>> (found version "1.10.1") 
>>>>>  * HDF5
>>>>>
>>>>> whereas the 'stable' branch does not require it, apparently; at least 
>>>>> cmake does not report anything about libhdf5.
>>>>>
>>>> Yeah, in the stable branch the hdf5 I/O backend is off by default, 
>>>> while it gets enabled automatically in master when an HDF5

Re: [votca] libhdf5.so

['Andrey Brukhno' via votca]

On Saturday, September 8, 2018 at 6:42:03 PM UTC+1, Christoph Junghans 
wrote:
>
>
>
> On Sat, Sep 8, 2018 at 11:24 'Andrey Brukhno' via votca <
> vo...@googlegroups.com > wrote:
>
>> The question is, what is the significance of this library (libhdf5)? - 
>> from what you say I gather, it is not required in general, but it is only 
>> necessary if I myself indent to use hdf5 files/data (which obviously I am 
>> not currently; unless it is used by VOTCA tools or scripts somewhere under 
>> the hood - ?).
>>
> HDF5 is used to read H5MD files!
>

Alright, whatever.. I suppose it is from here: 
https://support.hdfgroup.org/HDF5/Tutor/
 

>
>
>> Anyway, what is the cmake option to switch it off (I could not find it)?
>>
> -DCMAKE_DISABLE_FIND_PACKAGE_HDF5=ON
>

OK, thanks a lot!

Just for completeness, I did try to update my LD_LIBRARY_PATH including 
both standard and non-standard locations for the related lib files. 
However, I still see the following in the cmake report, where I flagged all 
the supposedly relevant lines with triple asterisk ***
...
*-- Found HDF5: 
/home/andrey/anaconda2/lib/libhdf5.so;/usr/lib/x86_64-linux-gnu/librt.so;/usr/lib/x86_64-linux-gnu/libpthread.so;/home/andrey/anaconda2/lib/libz.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libm.so
 
(found version "1.10.1")  
-- Could NOT find GMX (missing:  GMX_EXECUTABLE) 
-- Boost version: 1.58.0
-- Found the following Boost libraries:
--   program_options
-- Checking for module 'libvotca_tools'
--   No package 'libvotca_tools' found
-- Intel(R) MKL could not be found.
-- Checking for module 'libvotca_csg'
--   No package 'libvotca_csg' found
-- Found VOTCA_CSG: votca_csg  
*-- Could NOT find CLANG_FORMAT (missing:  CLANG_FORMAT_EXECUTABLE) 
-- 
-- The following OPTIONAL packages have been found:

 * Git
 * FFTW3
 * EXPAT
 * TXT2TAGS
 * UnixCommands
 ** HDF5 
 * Eigen3
 * PkgConfig
 * Doxygen
---

I have two questions regarding the above.

1. Is the line complaining about not found CLANG_FORMAT related in any way 
to the libhdf5?

2. Can it be that at the building time the libraries from different sources 
are confused or mixed up somehow upon linking? (so that at run time a wrong 
library is searched for)

Andrey


> Christoph 
>
>>
>>
>> Thanks
>> Andrey
>>
>>
>> On Saturday, September 8, 2018 at 6:01:02 PM UTC+1, Christoph Junghans 
>> wrote:
>>
>>> On Sat, Sep 8, 2018, 09:43 'Andrey Brukhno' via votca <
>>> vo...@googlegroups.com> wrote:
>>>
>>>> Just to make sure, I have done it for the third time now, with the same 
>>>> result (error about libhdf5).
>>>> This is strange because the camke log reports it as found:
>>>>
>>>> $ grep HDF master-cmake.log
>>>> -- Found HDF5: 
>>>> /home/andrey/anaconda2/lib/libhdf5.so;/usr/lib/x86_64-linux-gnu/librt.so;/usr/lib/x86_64-linux-gnu/libpthread.so;/home/andrey/anaconda2/lib/libz.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libm.so
>>>>  
>>>> (found version "1.10.1") 
>>>>  * HDF5
>>>>
>>>> whereas the 'stable' branch does not require it, apparently; at least 
>>>> cmake does not report anything about libhdf5.
>>>>
>>> Yeah, in the stable branch the hdf5 I/O backend is off by default, while 
>>> it gets enabled automatically in master when an HDF5 library is found! The 
>>> code has matured enough since it was added in 1.4!
>>>
>>> There error is due to the fact that your libhdf5 is in non-common place 
>>> and hence LD cannot find it at runtime! Either add that directory to your 
>>> LD_LIBRARY_PATH or try the new inject rpath option in master. Or you could 
>>> also disable the HDF5 backend if you don't need it.
>>>
>>> Christoph
>>>
>>>
>>>> Andrey
>>>>
>>>> On Saturday, September 8, 2018 at 4:05:08 PM UTC+1, Andrey Brukhno 
>>>> wrote:
>>>>>
>>>>> Hi Christoph, thanks for your response.
>>>>>
>>>>> On Friday, September 7, 2018 at 7:05:28 PM UTC+1, Christoph Junghans 
>>>>> wrote:
>>>>>>
>>>>>> On Fri, Sep 7, 2018 at 11:03 AM 'Andrey Brukhno' via votca 
>>>>>>  wrote: 
>>>>>> > 
>>>>>> > Hello, 
>>>>>> > 
>>>>>> > Upon a successful installation of the VOTCA's development (master) 
>>>>>> branch I get this error: 
>>>>>> > 
>>>>>> > ~/votca-dev/bin/csg_map

Re: [votca] libhdf5.so

['Andrey Brukhno' via votca]

The question is, what is the significance of this library (libhdf5)? - from 
what you say I gather, it is not required in general, but it is only 
necessary if I myself indent to use hdf5 files/data (which obviously I am 
not currently; unless it is used by VOTCA tools or scripts somewhere under 
the hood - ?).

Anyway, what is the cmake option to switch it off (I could not find it)?

Thanks
Andrey


On Saturday, September 8, 2018 at 6:01:02 PM UTC+1, Christoph Junghans 
wrote:
>
> On Sat, Sep 8, 2018, 09:43 'Andrey Brukhno' via votca <
> vo...@googlegroups.com > wrote:
>
>> Just to make sure, I have done it for the third time now, with the same 
>> result (error about libhdf5).
>> This is strange because the camke log reports it as found:
>>
>> $ grep HDF master-cmake.log
>> -- Found HDF5: 
>> /home/andrey/anaconda2/lib/libhdf5.so;/usr/lib/x86_64-linux-gnu/librt.so;/usr/lib/x86_64-linux-gnu/libpthread.so;/home/andrey/anaconda2/lib/libz.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libm.so
>>  
>> (found version "1.10.1") 
>>  * HDF5
>>
>> whereas the 'stable' branch does not require it, apparently; at least 
>> cmake does not report anything about libhdf5.
>>
> Yeah, in the stable branch the hdf5 I/O backend is off by default, while 
> it gets enabled automatically in master when an HDF5 library is found! The 
> code has matured enough since it was added in 1.4!
>
> There error is due to the fact that your libhdf5 is in non-common place 
> and hence LD cannot find it at runtime! Either add that directory to your 
> LD_LIBRARY_PATH or try the new inject rpath option in master. Or you could 
> also disable the HDF5 backend if you don't need it.
>
> Christoph
>
>
>> Andrey
>>
>> On Saturday, September 8, 2018 at 4:05:08 PM UTC+1, Andrey Brukhno wrote:
>>>
>>> Hi Christoph, thanks for your response.
>>>
>>> On Friday, September 7, 2018 at 7:05:28 PM UTC+1, Christoph Junghans 
>>> wrote:
>>>>
>>>> On Fri, Sep 7, 2018 at 11:03 AM 'Andrey Brukhno' via votca 
>>>>  wrote: 
>>>> > 
>>>> > Hello, 
>>>> > 
>>>> > Upon a successful installation of the VOTCA's development (master) 
>>>> branch I get this error: 
>>>> > 
>>>> > ~/votca-dev/bin/csg_map 
>>>> > /home/andrey/votca-dev/bin/csg_map: error while loading shared 
>>>> libraries: libvotca_csg.so.5: cannot open shared object file: No such file 
>>>> or directory 
>>>> That just means you have to source VOTCARC.bash 
>>>>
>>>
>>> Yes, sorry I missed to include that from my terminal output (I meant to 
>>> show that resulting error):
>>> ---
>>> build > ~/votca-dev/bin/csg_map
>>> /home/andrey/votca-dev/bin/csg_map: error while loading shared 
>>> libraries: libvotca_csg.so.5: cannot open shared object file: No such file 
>>> or directory
>>> build > . ~/votca-dev/bin/VOTCARC.bash 
>>> build > ~/votca-dev/bin/csg_map
>>> /home/andrey/votca-dev/bin/csg_map: error while loading shared 
>>> libraries: libhdf5.so.101: cannot open shared object file: No such file or 
>>> directory
>>> ---
>>> Note that I tried to install the 'master' twice, repeating the entire 
>>> process, starting with "git clone -b master ...", both times I ended up 
>>> with the above error message about missing libhdf5.so.101, whereas it was 
>>> installed and the installation of 'stable' branch did not complain at all.
>>>
>>>
>>>> We also recently added the option to inject an rpath on Linux, i.e. 
>>>> -DENABLE_RPATH_INJECT=ON, then the location of libvotca_csg.so.5 will 
>>>> be stored in csg_map itself. 
>>>>
>>>
>>> What does it help? (before it seemed to work fine without it)
>>>  
>>>
>>>>
>>>> > 
>>>> > I tried to reinstall libhdf5-dev twice, also checked for all the 
>>>> other dependencies, everything looks fine, yet the error. 
>>>> Not sure how this related to libhdf5, the above error refers to 
>>>> libvotca_csg.so.5, right? 
>>>>
>>>> > 
>>>> > Meanwhile the 'stable' branch (1.4.1 apparently) did install 
>>>> correctly and appears to work. 
>>>> > 
>>>> > Would appreciate any clues or a fix. 
>>>> > 
>>>> > Thanks 
>>>> > Andrey 
>>>> > 
>>>> >

Re: [votca] libhdf5.so

['Andrey Brukhno' via votca]

Just to make sure, I have done it for the third time now, with the same 
result (error about libhdf5).
This is strange because the camke log reports it as found:

$ grep HDF master-cmake.log
-- Found HDF5: 
/home/andrey/anaconda2/lib/libhdf5.so;/usr/lib/x86_64-linux-gnu/librt.so;/usr/lib/x86_64-linux-gnu/libpthread.so;/home/andrey/anaconda2/lib/libz.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libm.so
 
(found version "1.10.1") 
 * HDF5

whereas the 'stable' branch does not require it, apparently; at least cmake 
does not report anything about libhdf5.

Andrey

On Saturday, September 8, 2018 at 4:05:08 PM UTC+1, Andrey Brukhno wrote:
>
> Hi Christoph, thanks for your response.
>
> On Friday, September 7, 2018 at 7:05:28 PM UTC+1, Christoph Junghans wrote:
>>
>> On Fri, Sep 7, 2018 at 11:03 AM 'Andrey Brukhno' via votca 
>>  wrote: 
>> > 
>> > Hello, 
>> > 
>> > Upon a successful installation of the VOTCA's development (master) 
>> branch I get this error: 
>> > 
>> > ~/votca-dev/bin/csg_map 
>> > /home/andrey/votca-dev/bin/csg_map: error while loading shared 
>> libraries: libvotca_csg.so.5: cannot open shared object file: No such file 
>> or directory 
>> That just means you have to source VOTCARC.bash 
>>
>
> Yes, sorry I missed to include that from my terminal output (I meant to 
> show that resulting error):
> ---
> build > ~/votca-dev/bin/csg_map
> /home/andrey/votca-dev/bin/csg_map: error while loading shared libraries: 
> libvotca_csg.so.5: cannot open shared object file: No such file or directory
> build > . ~/votca-dev/bin/VOTCARC.bash 
> build > ~/votca-dev/bin/csg_map
> /home/andrey/votca-dev/bin/csg_map: error while loading shared libraries: 
> libhdf5.so.101: cannot open shared object file: No such file or directory
> ---
> Note that I tried to install the 'master' twice, repeating the entire 
> process, starting with "git clone -b master ...", both times I ended up 
> with the above error message about missing libhdf5.so.101, whereas it was 
> installed and the installation of 'stable' branch did not complain at all.
>
>
>> We also recently added the option to inject an rpath on Linux, i.e. 
>> -DENABLE_RPATH_INJECT=ON, then the location of libvotca_csg.so.5 will 
>> be stored in csg_map itself. 
>>
>
> What does it help? (before it seemed to work fine without it)
>  
>
>>
>> > 
>> > I tried to reinstall libhdf5-dev twice, also checked for all the other 
>> dependencies, everything looks fine, yet the error. 
>> Not sure how this related to libhdf5, the above error refers to 
>> libvotca_csg.so.5, right? 
>>
>> > 
>> > Meanwhile the 'stable' branch (1.4.1 apparently) did install correctly 
>> and appears to work. 
>> > 
>> > Would appreciate any clues or a fix. 
>> > 
>> > Thanks 
>> > Andrey 
>> > 
>> > PS: for reference, below is the output messages from cmake for my 
>> attempted installation of 'master' 
>> > 
>> > build > cmake -DBUILD_CSGAPPS=ON -DBUILD_TOOLS=ON -DWITH_GMX=ON 
>> -DWITH_SQLITE3=OFF -DCMAKE_INSTALL_PREFIX=$HOME/votca-dev .. 
>> And yeah there is no BUILD_TOOLS option. 
>>
>
> Okay, I noticed. I think including it did not affect anything (?).
>
> Andrey
>
>  
>
>>
>> > -- Boost version: 1.58.0 
>> > -- Found the following Boost libraries: 
>> > --   program_options 
>> > --   filesystem 
>> > --   system 
>> > -- Intel(R) MKL could not be found. 
>> > -- Boost version: 1.58.0 
>> > -- Found the following Boost libraries: 
>> > --   program_options 
>> > --   filesystem 
>> > --   system 
>> > -- Intel(R) MKL could not be found. 
>> > -- Checking for module 'libgromacs_d' 
>> > --   No package 'libgromacs_d' found 
>> > -- Could NOT find GMX (missing:  GMX_EXECUTABLE) 
>> > -- Boost version: 1.58.0 
>> > -- Found the following Boost libraries: 
>> > --   program_options 
>> > -- Intel(R) MKL could not be found. 
>> > -- Could NOT find CLANG_FORMAT (missing:  CLANG_FORMAT_EXECUTABLE) 
>> > -- 
>> > -- The following OPTIONAL packages have been found: 
>> > 
>> >  * Git 
>> >  * FFTW3 
>> >  * EXPAT 
>> >  * TXT2TAGS 
>> >  * UnixCommands 
>> >  * HDF5 
>> >  * Eigen3 
>> >  * PkgConfig 
>> >  * Doxygen 
>> > 
>> > -- The following REQUIRED packages have been found: 
>> > 
>> >  * Threads 
>>

Re: [votca] libhdf5.so

['Andrey Brukhno' via votca]

Hi Christoph, thanks for your response.

On Friday, September 7, 2018 at 7:05:28 PM UTC+1, Christoph Junghans wrote:
>
> On Fri, Sep 7, 2018 at 11:03 AM 'Andrey Brukhno' via votca 
> > wrote: 
> > 
> > Hello, 
> > 
> > Upon a successful installation of the VOTCA's development (master) 
> branch I get this error: 
> > 
> > ~/votca-dev/bin/csg_map 
> > /home/andrey/votca-dev/bin/csg_map: error while loading shared 
> libraries: libvotca_csg.so.5: cannot open shared object file: No such file 
> or directory 
> That just means you have to source VOTCARC.bash 
>

Yes, sorry I missed to include that from my terminal output (I meant to 
show that resulting error):
---
build > ~/votca-dev/bin/csg_map
/home/andrey/votca-dev/bin/csg_map: error while loading shared libraries: 
libvotca_csg.so.5: cannot open shared object file: No such file or directory
build > . ~/votca-dev/bin/VOTCARC.bash 
build > ~/votca-dev/bin/csg_map
/home/andrey/votca-dev/bin/csg_map: error while loading shared libraries: 
libhdf5.so.101: cannot open shared object file: No such file or directory
---
Note that I tried to install the 'master' twice, repeating the entire 
process, starting with "git clone -b master ...", both times I ended up 
with the above error message about missing libhdf5.so.101, whereas it was 
installed and the installation of 'stable' branch did not complain at all.


> We also recently added the option to inject an rpath on Linux, i.e. 
> -DENABLE_RPATH_INJECT=ON, then the location of libvotca_csg.so.5 will 
> be stored in csg_map itself. 
>

What does it help? (before it seemed to work fine without it)
 

>
> > 
> > I tried to reinstall libhdf5-dev twice, also checked for all the other 
> dependencies, everything looks fine, yet the error. 
> Not sure how this related to libhdf5, the above error refers to 
> libvotca_csg.so.5, right? 
>
> > 
> > Meanwhile the 'stable' branch (1.4.1 apparently) did install correctly 
> and appears to work. 
> > 
> > Would appreciate any clues or a fix. 
> > 
> > Thanks 
> > Andrey 
> > 
> > PS: for reference, below is the output messages from cmake for my 
> attempted installation of 'master' 
> > 
> > build > cmake -DBUILD_CSGAPPS=ON -DBUILD_TOOLS=ON -DWITH_GMX=ON 
> -DWITH_SQLITE3=OFF -DCMAKE_INSTALL_PREFIX=$HOME/votca-dev .. 
> And yeah there is no BUILD_TOOLS option. 
>

Okay, I noticed. I think including it did not affect anything (?).

Andrey

 

>
> > -- Boost version: 1.58.0 
> > -- Found the following Boost libraries: 
> > --   program_options 
> > --   filesystem 
> > --   system 
> > -- Intel(R) MKL could not be found. 
> > -- Boost version: 1.58.0 
> > -- Found the following Boost libraries: 
> > --   program_options 
> > --   filesystem 
> > --   system 
> > -- Intel(R) MKL could not be found. 
> > -- Checking for module 'libgromacs_d' 
> > --   No package 'libgromacs_d' found 
> > -- Could NOT find GMX (missing:  GMX_EXECUTABLE) 
> > -- Boost version: 1.58.0 
> > -- Found the following Boost libraries: 
> > --   program_options 
> > -- Intel(R) MKL could not be found. 
> > -- Could NOT find CLANG_FORMAT (missing:  CLANG_FORMAT_EXECUTABLE) 
> > -- 
> > -- The following OPTIONAL packages have been found: 
> > 
> >  * Git 
> >  * FFTW3 
> >  * EXPAT 
> >  * TXT2TAGS 
> >  * UnixCommands 
> >  * HDF5 
> >  * Eigen3 
> >  * PkgConfig 
> >  * Doxygen 
> > 
> > -- The following REQUIRED packages have been found: 
> > 
> >  * Threads 
> >  * GROMACS (required version >= 2016) 
> >  * Boost (required version >= 1.57.0) 
> >  * EIGEN3 (required version >= 3.3.0) 
> >  * VOTCA_TOOLS 
> >  * VOTCA_CSG 
> > 
> > -- The following OPTIONAL packages have not been found: 
> > 
> >  * MKL 
> > 
> > -- Configuring done 
> > -- Generating done 
> > CMake Warning: 
> >   Manually-specified variables were not used by the project: 
> > 
> > BUILD_TOOLS 
> > 
> > 
> > -- Build files have been written to: 
> /home/andrey/Progs/votca-dev/votca-1.5-master/build 
> > 
> > [bg:0](st:0) andrey@AndysHome: build > make 
> > ... 
> > 
> > -- 
> > 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 votca+un...@googlegroups.com . 
> > To post to this group, send email to vo...@googlegroups.com 
> . 
> > 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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

[votca] libhdf5.so

['Andrey Brukhno' via votca]

Hello,

Upon a successful installation of the VOTCA's development (master) branch I 
get this error:

~/votca-dev/bin/csg_map
/home/andrey/votca-dev/bin/csg_map: error while loading shared libraries: 
libvotca_csg.so.5: cannot open shared object file: No such file or directory

I tried to reinstall libhdf5-dev twice, also checked for all the other 
dependencies, everything looks fine, yet the error.

Meanwhile the 'stable' branch (1.4.1 apparently) did install correctly and 
appears to work. 

Would appreciate any clues or a fix.

Thanks
Andrey

PS: for reference, below is the output messages from cmake for my attempted 
installation of 'master'

build > cmake -DBUILD_CSGAPPS=ON -DBUILD_TOOLS=ON -DWITH_GMX=ON 
-DWITH_SQLITE3=OFF -DCMAKE_INSTALL_PREFIX=$HOME/votca-dev ..
-- Boost version: 1.58.0
-- Found the following Boost libraries:
--   program_options
--   filesystem
--   system
-- Intel(R) MKL could not be found.
-- Boost version: 1.58.0
-- Found the following Boost libraries:
--   program_options
--   filesystem
--   system
-- Intel(R) MKL could not be found.
-- Checking for module 'libgromacs_d'
--   No package 'libgromacs_d' found
-- Could NOT find GMX (missing:  GMX_EXECUTABLE) 
-- Boost version: 1.58.0
-- Found the following Boost libraries:
--   program_options
-- Intel(R) MKL could not be found.
-- Could NOT find CLANG_FORMAT (missing:  CLANG_FORMAT_EXECUTABLE) 
-- 
-- The following OPTIONAL packages have been found:

 * Git
 * FFTW3
 * EXPAT
 * TXT2TAGS
 * UnixCommands
 * HDF5
 * Eigen3
 * PkgConfig
 * Doxygen

-- The following REQUIRED packages have been found:

 * Threads
 * GROMACS (required version >= 2016)
 * Boost (required version >= 1.57.0)
 * EIGEN3 (required version >= 3.3.0)
 * VOTCA_TOOLS
 * VOTCA_CSG

-- The following OPTIONAL packages have not been found:

 * MKL

-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

BUILD_TOOLS


-- Build files have been written to: 
/home/andrey/Progs/votca-dev/votca-1.5-master/build

[bg:0](st:0) andrey@AndysHome: build > make 
...

-- 
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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

Re: [votca] Re: csg_reupdate error: property not found: re.function

['Andrey Brukhno' via votca]

Hi Christoph & Sikandar,

It's been a while since I asked the question below...

On Monday, July 23, 2018 at 7:51:14 PM UTC+1, Andrey Brukhno wrote:
>
>
> >>> Actually, I am a bit confused not seeing re.traj tag for atomistic
>> >>> trajectory. I thought RE iteration requires recalculating CG averages 
>> in
>> >>> over atomistic ensemble (trajectory) for every new set of CG 
>> potentials?
>> >>>
>> >>> Also, what about the corresponding re.topology tag - specifying what?
>> >>
>> >> Both options exist:
>> >>
>> >> 
>> https://github.com/votca/csg/blob/master/share/scripts/inverse/update_re.sh#L30
>> >>
>> >
>> > Just to clarify: above you confirm that the two tags
>> > `cg.inverse.$sim_prog.re.topol' and `cg.inverse.$sim_prog.re.traj' 
>> specify
>> > the tpr and xtc/trr files for the original fine-detail (atomistic)
>> > simulation?
>> No these are just options, which allow you to overwrite the
>> coarse-grained topology and trajectory.
>> Nothing atomistic here!
>
>
 

> If so, I am back to my question of how are the averages over fine detail 
> (atomistic) ensemble calculated for a new CG model/FF at each iteration?
> I am referring to Eqs. 2.24 and 2.26 in the manual (page 8).
>

According to the equations each RE iteration should recalculate the 
averages corresponding to the "AA" (fine-detail) ensemble using a new CG 
representation (i.e. updated force-field), and this is what I fail to find 
in the tutorial for spce/re. 

Could you please clarify this.

Andrey

 

>  
>
>>
>> > For reference, below is the extract from 
>> `share/votca/xml/csg_defaults.xml',
>> > where no traj tag is present (this is for v1.4.1, so perhaps in v1.5.1 
>> the
>> > tag is there?):
>> >
>> >   
>> >   
>> > Special topology file to be used for
>> > csg_reupdate
>> >   
>> >   
>> >
>> > Btw, my original question was: why these are not specified in 
>> `settings.xml'
>> > in the (spce/re) case you referred to above?
>> If they are not specified the default topology (topol.tpr) and default
>> trajectory (traj.xtc) are used.
>>
>> >
>> > Thanks / Andrey
>> >
>> >> Christoph
>> >>
>> >>>
>> >>> 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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

Re: [votca] special tpr for RDF calculations

['Andrey Brukhno' via votca]

I guess the mapping xml for special exclusions might be needed with
packages other than Gromacs.
E.g. DL_POLY certainly does not provide an easy way of altering exclusion
lists.

This remark is just for completeness of discussion...

Andrey


On Tue, Jul 24, 2018 at 1:47 PM, 'Andrey Brukhno' via votca <
votca@googlegroups.com> wrote:

>
> On Tuesday, July 24, 2018 at 12:48:40 PM UTC+1, Christoph Junghans wrote:
>>
>> On Tue, Jul 24, 2018 at 2:31 AM, 'Andrey Brukhno' via votca
>>  wrote:
>> >
>> >
>> > On Tue, Jul 24, 2018 at 1:34 AM, Christoph Junghans 
>>
>> > wrote:
>> >>
>> >> >
>> >> > 1) the case where topol.tpr has nrexcl = 3 and  topol-map11-rdf.xml
>> >> > defines
>> >> > all pairs as bonded
>> >> >
>> >> >> csg_dump --top topol.tpr --map topol-map11-rdf.xml --excl
>> >> > Reading file topol.tpr, VERSION 2018.2 (single precision)
>> >> > I have 12 beads in 1 molecule
>> >> >
>> >> > List of exclusions:
>> >> > 1 2 3 4
>> >> > 2 3 4 9
>> >> > 3 4 9 10 11
>> >> > 4 8 9 10 11 12
>> >> > 5 6 7 8
>> >> > 6 7 8 10
>> >> > 7 8 9 10
>> >> > 8 9 10 11
>> >> > 9 10 11 12
>> >> > 10 11 12
>> >> > 11 12
>> >> >
>> > This is why I preferred to use topol-rdf.tpr and not the mapping xml
>> file.
>> > But since you suggested that a mapping file might be needed in some
>> cases,
>> > like IMC with bonds, I tried that as well. But apparently mapping file
>> does
>> > not affect the exclusions at all (there is no difference for my two
>> mapping
>> > files)!
>> Just to clarify, the section 7.3.2 of the manual, which suggest you
>> need a mapping file, is obsolete and got removed in:
>> https://github.com/votca/csg-manual/pull/8.
>> Mapping files are only implemented for RDF calculations for IBI (and
>> the optimizer) at this point and aren't used for methods like IMC and
>> RE.
>> It would be easy to add, but nobody has asked for it yet.
>>
>
> For my current purposes (and I think generally) taking exclusions from a
> special tpr file is more convenient.
> It is also much less hassle to prepare, as well as to implement in the
> workflows.
>
>
>> >
>> > The bottom line here: adding bonds for all pairs in mapping file does
>> not
>> > affect the exclusion list at all - it does look like exclusion list
>> comes
>> > from tpr only.
>> Sorry, but that statement is just wrong, but must have made a mistake
>> in your mapping file.
>>
>
> OK, I have to admit to using a wrong flag `--map' instead of `--cg' above.
> With the correct flag the exclusions are calculated correctly based on
> mapping xml file.
>
> Andrey
>
>
>> VOTCA reads the exclusions from the topology file (tpr, xml or
>> whatever), but if a mapping file is specified a mapping is done (1:1
>> or not) and after the mapping exclusions get re-generated from the
>> bonded interactions in the mapping with an "nrexcl=1"-like algorithm,
>> i.e. beads in a bond, angle or dihedral are excluded.
>>
>> One can test that very easily using the "hexane/ibi_all" example:
>> These are the exclusions in the tpr (from step_001):
>> $ csg_dump --top topol.tpr --excl | head -5
>> I have 3000 beads in 1000 molecules
>>
>> List of exclusions:
>> 1 2 3
>> 2 3
>>
>> Using the included mapping file with 2 bonds and 1 angle, one can get
>> the same exclusions:
>>  $ csg_dump --top topol.tpr --excl --cg ../hexane_cg.xml | head -6
>> I have 3000 beads in 1000 molecules
>> I have 3000 beads in 1000 molecules for the coarsegraining
>>
>> List of exclusions:
>> 1 2 3
>> 2 3
>>
>> When removing the angle from the mapping file, one get less exclusions:
>> $ csg_dump --top topol.tpr --excl --cg ./hexane_noangle.xml | head -6
>> I have 3000 beads in 1000 molecules
>> I have 3000 beads in 1000 molecules for the coarsegraining
>>
>> List of exclusions:
>> 1 2
>> 2 3
>>
>> When removing the bonds and angle from the mapping file, one get no
>> exclusions:
>> csg_dump --top topol.tpr --excl --cg ./hexane_cg.xml | head -6
>> I have 3000 beads in 1000 molecules
>> I have 3000 beads in 1000 molecules for the coarsegraining
>>
>> List of exclusions:
>> 
>>
>> So everything works like

Re: [votca] special tpr for RDF calculations

['Andrey Brukhno' via votca]

On Tuesday, July 24, 2018 at 12:48:40 PM UTC+1, Christoph Junghans wrote:
>
> On Tue, Jul 24, 2018 at 2:31 AM, 'Andrey Brukhno' via votca 
> > wrote: 
> > 
> > 
> > On Tue, Jul 24, 2018 at 1:34 AM, Christoph Junghans  > 
> > wrote: 
> >> 
> >> > 
> >> > 1) the case where topol.tpr has nrexcl = 3 and  topol-map11-rdf.xml 
> >> > defines 
> >> > all pairs as bonded 
> >> > 
> >> >> csg_dump --top topol.tpr --map topol-map11-rdf.xml --excl 
> >> > Reading file topol.tpr, VERSION 2018.2 (single precision) 
> >> > I have 12 beads in 1 molecule 
> >> > 
> >> > List of exclusions: 
> >> > 1 2 3 4 
> >> > 2 3 4 9 
> >> > 3 4 9 10 11 
> >> > 4 8 9 10 11 12 
> >> > 5 6 7 8 
> >> > 6 7 8 10 
> >> > 7 8 9 10 
> >> > 8 9 10 11 
> >> > 9 10 11 12 
> >> > 10 11 12 
> >> > 11 12 
> >> > 
> > This is why I preferred to use topol-rdf.tpr and not the mapping xml 
> file. 
> > But since you suggested that a mapping file might be needed in some 
> cases, 
> > like IMC with bonds, I tried that as well. But apparently mapping file 
> does 
> > not affect the exclusions at all (there is no difference for my two 
> mapping 
> > files)! 
> Just to clarify, the section 7.3.2 of the manual, which suggest you 
> need a mapping file, is obsolete and got removed in: 
> https://github.com/votca/csg-manual/pull/8. 
> Mapping files are only implemented for RDF calculations for IBI (and 
> the optimizer) at this point and aren't used for methods like IMC and 
> RE. 
> It would be easy to add, but nobody has asked for it yet. 
>

For my current purposes (and I think generally) taking exclusions from a 
special tpr file is more convenient.
It is also much less hassle to prepare, as well as to implement in the 
workflows.
 

> > 
> > The bottom line here: adding bonds for all pairs in mapping file does 
> not 
> > affect the exclusion list at all - it does look like exclusion list 
> comes 
> > from tpr only. 
> Sorry, but that statement is just wrong, but must have made a mistake 
> in your mapping file. 
>

OK, I have to admit to using a wrong flag `--map' instead of `--cg' above. 
With the correct flag the exclusions are calculated correctly based on 
mapping xml file.
 
Andrey


> VOTCA reads the exclusions from the topology file (tpr, xml or 
> whatever), but if a mapping file is specified a mapping is done (1:1 
> or not) and after the mapping exclusions get re-generated from the 
> bonded interactions in the mapping with an "nrexcl=1"-like algorithm, 
> i.e. beads in a bond, angle or dihedral are excluded. 
>
> One can test that very easily using the "hexane/ibi_all" example: 
> These are the exclusions in the tpr (from step_001): 
> $ csg_dump --top topol.tpr --excl | head -5 
> I have 3000 beads in 1000 molecules 
>
> List of exclusions: 
> 1 2 3 
> 2 3 
>
> Using the included mapping file with 2 bonds and 1 angle, one can get 
> the same exclusions: 
>  $ csg_dump --top topol.tpr --excl --cg ../hexane_cg.xml | head -6 
> I have 3000 beads in 1000 molecules 
> I have 3000 beads in 1000 molecules for the coarsegraining 
>
> List of exclusions: 
> 1 2 3 
> 2 3 
>
> When removing the angle from the mapping file, one get less exclusions: 
> $ csg_dump --top topol.tpr --excl --cg ./hexane_noangle.xml | head -6 
> I have 3000 beads in 1000 molecules 
> I have 3000 beads in 1000 molecules for the coarsegraining 
>
> List of exclusions: 
> 1 2 
> 2 3 
>
> When removing the bonds and angle from the mapping file, one get no 
> exclusions: 
> csg_dump --top topol.tpr --excl --cg ./hexane_cg.xml | head -6 
> I have 3000 beads in 1000 molecules 
> I have 3000 beads in 1000 molecules for the coarsegraining 
>
> List of exclusions: 
>  
>
> So everything works like expected. However, you won't be able to use 
> exclusions from mapping files out side of IBI anyhow. 
>
> > I am stopping now testing this, because the workflow works now for me, 
> with 
> > my modifications in mc_stat_generic.sh 
> The modification you did is already part of the current development 
> branch since Aug 2017 and hence will be part of VOTCA v1.5. 
>
> Christoph 
> > 
> > Andrey 
> >> 
> >> >> 
> >> >> 
> >> >>> 
> >> >>> 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "votca" group. 
> > To un

Re: [votca] special tpr for RDF calculations

['Andrey Brukhno' via votca]

It seems that mapping files are only used for IBI.

Andrey


On Tue, Jul 24, 2018 at 1:31 AM, Christoph Junghans 
wrote:

> On Mon, Jul 23, 2018 at 4:14 PM, 'Andrey Brukhno' via votca
>  wrote:
> > On Monday, July 23, 2018 at 3:17:49 PM UTC+1, Christoph Junghans wrote:
> >>
> >> On Mon, Jul 23, 2018 at 7:41 AM, 'Andrey Brukhno' via votca
> >>  wrote:
> >> > In this case, it's not an error message which is lost ;) Why does it
> go
> >> > to
> >> > stderr at all?
> >> The code has the reason right there:
> >> #print this message to stderr because $(critical something) is used very
> >> often
> >>
> >> > Moreover, if I try to run the iteration a second time, everything
> >> > including
> >> > errors is reported back
> >> Well that is good, nevertheless we just spend 5 E-Mails back and
> >> forth, hunting down a bug you introduced yourself.
> >> And I now recall you made that change to filter gromacs "Read frame
> >> XXX" message, which is fixed when using a newer gromacs version
> >> (>=2016.3), see:
> >>
> >> https://github.com/votca/csg/commit/155eb770873a6f65bac372c9f8c5ef
> c9f3a4be75
> >>
> >> >
> >> > Anyway, my primary issue is not about messages, but to make it work
> >> > correctly for distributions.
> >> Like I said in the other email if section 7.3.2 is right, a mapping
> >> file might be needed only for IMC, but even that I think is not true
> >> anymore in v1.3.1.
> >> So you need to figure out, which exclusions you want to read the ones
> >> from the mapping file or the ones the tpr.
> >> For the former specify a mapping file or the latter don't.
> >>
> >> And then you can use csg_dump with or without --cg option to check the
> >> exclusions!
> >> $ csg_dump --top topol.tpr --excl
> >> or
> >> $ csg_dump --top topol.tpr --excl --cg mapping.xml.
> >>
> >> Christoph
> >
> >
> > Well, I can of course, but v1.4.1 does not use any special rdf.topol tag
> (so
> > I have to introduce it myself):
> >
> > sim_prog="$(csg_get_property cg.inverse.program)"
> >
> > topol=$(csg_get_property cg.inverse.$sim_prog.topol)
> > [[ -f $topol ]] || die "${0##*/}: topol file '$topol' not found, possibly
> > you have to add it to cg.inverse.filelist"
> >
> > traj=$(csg_get_property cg.inverse.$sim_prog.traj)
> > [[ -f $traj ]] || die "${0##*/}: traj file '$traj' not found"
> >
> > equi_time="$(csg_get_property cg.inverse.$sim_prog.equi_time)"
> > if [[ ${CSG_RUNTEST} ]] && csg_calc "$equi_time" ">" "0"; then
> >   msg --color blue --to-stderr "Automatically setting equi_time to 0,
> > because CSG_RUNTEST was set"
> >   equi_time=0
> > fi
> >
> > first_frame="$(csg_get_property cg.inverse.$sim_prog.first_frame)"
> >
> > tasks=$(get_number_tasks)
> > msg "Calculating IMC statistics using $tasks tasks"
> > if is_done "imc_analysis"; then
> >   echo "IMC analysis is already done"
> > else
> >   #copy+resample all target dist in $this_dir
> >   for_all "non-bonded bonded" do_external resample target
> > '$(csg_get_interaction_property inverse.target)'
> > '$(csg_get_interaction_property name).dist.tgt'
> >
> >   critical csg_stat --do-imc --options "$CSGXMLFILE" --top "$topol" --trj
> > "$traj" --begin $equi_time --first-frame $first_frame --nt $tasks
> >   mark_done "imc_analysis"
> This is interesting, too! csg_stat for IMC is always called without
> mapping files.
>
> Christoph
> > fi
> >
> >
> >>
> >>
> >> >
> >> > Andrey
> >> >
> >> > On Monday, July 23, 2018 at 2:33:44 PM UTC+1, Christoph Junghans
> wrote:
> >> >>
> >> >> On Mon, Jul 23, 2018 at 7:28 AM, 'Andrey Brukhno' via votca
> >> >>  wrote:
> >> >> > Christoph,
> >> >> >
> >> >> > I think I figured why there is no log msg for critical csg_stat in
> >> >> > calc_rdfgeneric.sh.
> >> >> > The fact is I override the inverse.sh script with the one having
> this
> >> >> > (to
> >> >> > avoid all the frame numbers when reading trajectory files):
> >> >> >
> >> >> >log="$

Re: [votca] special tpr for RDF calculations

['Andrey Brukhno' via votca]

On Tue, Jul 24, 2018 at 1:34 AM, Christoph Junghans 
wrote:

> On Mon, Jul 23, 2018 at 5:26 PM, 'Andrey Brukhno' via votca
>  wrote:
> >
> >
> > On Monday, July 23, 2018 at 8:18:39 PM UTC+1, Andrey Brukhno wrote:
> >>
> >> On Monday, July 23, 2018 at 3:17:49 PM UTC+1, Christoph Junghans wrote:
> >>>
> >>> On Mon, Jul 23, 2018 at 7:41 AM, 'Andrey Brukhno' via votca
> >>>  wrote:
> >>> > In this case, it's not an error message which is lost ;) Why does it
> go
> >>> > to
> >>> > stderr at all?
> >>> The code has the reason right there:
> >>> #print this message to stderr because $(critical something) is used
> very
> >>> often
> >>>
> >>> > Moreover, if I try to run the iteration a second time, everything
> >>> > including
> >>> > errors is reported back
> >>> Well that is good, nevertheless we just spend 5 E-Mails back and
> >>> forth, hunting down a bug you introduced yourself.
> >>> And I now recall you made that change to filter gromacs "Read frame
> >>> XXX" message, which is fixed when using a newer gromacs version
> >>> (>=2016.3), see:
> >>>
> >>> https://github.com/votca/csg/commit/155eb770873a6f65bac372c9f8c5ef
> c9f3a4be75
> >>>
> >>> >
> >>> > Anyway, my primary issue is not about messages, but to make it work
> >>> > correctly for distributions.
> >>> Like I said in the other email if section 7.3.2 is right, a mapping
> >>> file might be needed only for IMC, but even that I think is not true
> >>> anymore in v1.3.1.
> >>
> >>
> >> My test IMC iteration went through without tagging the 1:1 CG map file.
> >>
> >>>
> >>> So you need to figure out, which exclusions you want to read the ones
> >>> from the mapping file or the ones the tpr.
> >>> For the former specify a mapping file or the latter don't.
> >>
> >>
> >> OK, I preferred the exclusions from topol-rdf.tpr (which appears to work
> >> now for IBI), so I skipped the map tags in my settings file for IMC too.
> >> However, the distributions are still wrong in the case of IMC.
> >
> >
> > As a matter of fact including a 1:1 topology xml where all the
> > intra-molecular pairs are counted as bonded does not affect the exclusion
> > list (so only tpr file matters) for csg_dump:
> >
> > 1) the case where topol.tpr has nrexcl = 3 and  topol-map11-rdf.xml
> defines
> > all pairs as bonded
> >
> >> csg_dump --top topol.tpr --map topol-map11-rdf.xml --excl
> > Reading file topol.tpr, VERSION 2018.2 (single precision)
> > I have 12 beads in 1 molecule
> >
> > List of exclusions:
> > 1 2 3 4
> > 2 3 4 9
> > 3 4 9 10 11
> > 4 8 9 10 11 12
> > 5 6 7 8
> > 6 7 8 10
> > 7 8 9 10
> > 8 9 10 11
> > 9 10 11 12
> > 10 11 12
> > 11 12
> >
> > 2) the case where topol.tpr has nrexcl = 3 and no topol-map11-rdf.xml is
> > used
> >
> >> csg_dump --top topol.tpr  --excl
> > Reading file topol.tpr, VERSION 2018.2 (single precision)
> > I have 12 beads in 1 molecule
> >
> > List of exclusions:
> > 1 2 3 4
> > 2 3 4 9
> > 3 4 9 10 11
> > 4 8 9 10 11 12
> > 5 6 7 8
> > 6 7 8 10
> > 7 8 9 10
> > 8 9 10 11
> > 9 10 11 12
> > 10 11 12
> > 11 12
> > 13 14 15 16
> > 14 15 16 21
> > 15 16 21 22 23
> > 16 20 21 22 23 24
> > 17 18 19 20
> > 18 19 20 22
> > 19 20 21 22
> > 20 21 22 23
> > 21 22 23 24
> > 22 23 24
> > 23 24
> >
> > 3) the case where topol-rdf.tpr has nrexcl = 10 so all pairs within a
> chain
> > are excluded from RDF calculation
> >
> >> csg_dump --top topol-rdf.tpr  --excl
> > Reading file topol-rdf.tpr, VERSION 2018.2 (single precision)
> > I have 12 beads in 1 molecule
> >
> > List of exclusions:
> > 1 2 3 4 5 6 7 8 9 10 11 12
> > 2 3 4 5 6 7 8 9 10 11 12
> > 3 4 5 6 7 8 9 10 11 12
> > 4 5 6 7 8 9 10 11 12
> > 5 6 7 8 9 10 11 12
> > 6 7 8 9 10 11 12
> > 7 8 9 10 11 12
> > 8 9 10 11 12
> > 9 10 11 12
> > 10 11 12
> > 11 12
> >
>
> I am quite sure what you want to tell us with that comparison! If you
> want to achieve the same as nrexcl=10 with a mapping file, you will
> need to add 12*11/2=66 bonds between all possible pairs to that
> mapping file.
>
> Christoph
>

This is why I preferred to use topol-rdf.tpr and not the mapping xml file.
But since you suggested that a mapping file might be needed in some cases,
like IMC with bonds, I tried that as well. But apparently mapping file does
not affect the exclusions at all (there is no difference for my two mapping
files)!

The bottom line here: adding bonds for all pairs in mapping file does not
affect the exclusion list at all - it does look like exclusion list comes
from tpr only.
I am stopping now testing this, because the workflow works now for me, with
my modifications in mc_stat_generic.sh

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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

Re: [votca] special tpr for RDF calculations

['Andrey Brukhno' via votca]

On Monday, July 23, 2018 at 8:18:39 PM UTC+1, Andrey Brukhno wrote:
>
> On Monday, July 23, 2018 at 3:17:49 PM UTC+1, Christoph Junghans wrote:
>>
>> On Mon, Jul 23, 2018 at 7:41 AM, 'Andrey Brukhno' via votca 
>>  wrote: 
>> > In this case, it's not an error message which is lost ;) Why does it go 
>> to 
>> > stderr at all? 
>> The code has the reason right there: 
>> #print this message to stderr because $(critical something) is used very 
>> often 
>>
>> > Moreover, if I try to run the iteration a second time, everything 
>> including 
>> > errors is reported back 
>> Well that is good, nevertheless we just spend 5 E-Mails back and 
>> forth, hunting down a bug you introduced yourself. 
>> And I now recall you made that change to filter gromacs "Read frame 
>> XXX" message, which is fixed when using a newer gromacs version 
>> (>=2016.3), see: 
>>
>> https://github.com/votca/csg/commit/155eb770873a6f65bac372c9f8c5efc9f3a4be75 
>>
>> > 
>> > Anyway, my primary issue is not about messages, but to make it work 
>> > correctly for distributions. 
>> Like I said in the other email if section 7.3.2 is right, a mapping 
>> file might be needed only for IMC, but even that I think is not true 
>> anymore in v1.3.1. 
>>
>
> My test IMC iteration went through without tagging the 1:1 CG map file.
>  
>
>> So you need to figure out, which exclusions you want to read the ones 
>> from the mapping file or the ones the tpr. 
>> For the former specify a mapping file or the latter don't. 
>>
>
> OK, I preferred the exclusions from topol-rdf.tpr (which appears to work 
> now for IBI), so I skipped the map tags in my settings file for IMC too. 
> However, the distributions are still wrong in the case of IMC.
>

As a matter of fact including a 1:1 topology xml where all the 
intra-molecular pairs are counted as bonded does not affect the exclusion 
list (so only tpr file matters) for csg_dump:

1) the case where topol.tpr has nrexcl = 3 and  topol-map11-rdf.xml defines 
all pairs as bonded

> csg_dump --top topol.tpr --map topol-map11-rdf.xml --excl
Reading file topol.tpr, VERSION 2018.2 (single precision)
I have 12 beads in 1 molecule

List of exclusions:
1 2 3 4
2 3 4 9
3 4 9 10 11
4 8 9 10 11 12
5 6 7 8
6 7 8 10
7 8 9 10
8 9 10 11
9 10 11 12
10 11 12
11 12

2) the case where topol.tpr has nrexcl = 3 and no topol-map11-rdf.xml is 
used

> csg_dump --top topol.tpr  --excl
Reading file topol.tpr, VERSION 2018.2 (single precision)
I have 12 beads in 1 molecule

List of exclusions:
1 2 3 4
2 3 4 9
3 4 9 10 11
4 8 9 10 11 12
5 6 7 8
6 7 8 10
7 8 9 10
8 9 10 11
9 10 11 12
10 11 12
11 12
13 14 15 16
14 15 16 21
15 16 21 22 23
16 20 21 22 23 24
17 18 19 20
18 19 20 22
19 20 21 22
20 21 22 23
21 22 23 24
22 23 24
23 24

3) the case where topol-rdf.tpr has nrexcl = 10 so all pairs within a chain 
are excluded from RDF calculation

> csg_dump --top topol-rdf.tpr  --excl
Reading file topol-rdf.tpr, VERSION 2018.2 (single precision)
I have 12 beads in 1 molecule

List of exclusions:
1 2 3 4 5 6 7 8 9 10 11 12
2 3 4 5 6 7 8 9 10 11 12
3 4 5 6 7 8 9 10 11 12
4 5 6 7 8 9 10 11 12
5 6 7 8 9 10 11 12
6 7 8 9 10 11 12
7 8 9 10 11 12
8 9 10 11 12
9 10 11 12
10 11 12
11 12
 

>  
>
>>
>> And then you can use csg_dump with or without --cg option to check the 
>> exclusions! 
>> $ csg_dump --top topol.tpr --excl 
>> or 
>> $ csg_dump --top topol.tpr --excl --cg mapping.xml. 
>>
>> Christoph 
>>
>> > 
>> > Andrey 
>> > 
>> > On Monday, July 23, 2018 at 2:33:44 PM UTC+1, Christoph Junghans wrote: 
>> >> 
>> >> On Mon, Jul 23, 2018 at 7:28 AM, 'Andrey Brukhno' via votca 
>> >>  wrote: 
>> >> > Christoph, 
>> >> > 
>> >> > I think I figured why there is no log msg for critical csg_stat in 
>> >> > calc_rdfgeneric.sh. 
>> >> > The fact is I override the inverse.sh script with the one having 
>> this 
>> >> > (to 
>> >> > avoid all the frame numbers when reading trajectory files): 
>> >> > 
>> >> >log="${PWD}/${log##*/}" 
>> >> >export CSGLOG="$log" 
>> >> >if [[ -f $CSGLOG ]]; then 
>> >> >  exec 3>&1 4>&2 >> "$CSGLOG" 2>&1 
>> >> >  echo -e "\n\n##" 
>> >> >  #echo "# Appending to existing logfile #" 
>> >> >  echo"# Appending to logfile (+errors) #" 
>> >> >  

Re: [votca] special tpr for RDF calculations

['Andrey Brukhno' via votca]

On Monday, July 23, 2018 at 3:17:49 PM UTC+1, Christoph Junghans wrote:
>
> On Mon, Jul 23, 2018 at 7:41 AM, 'Andrey Brukhno' via votca 
> > wrote: 
> > In this case, it's not an error message which is lost ;) Why does it go 
> to 
> > stderr at all? 
> The code has the reason right there: 
> #print this message to stderr because $(critical something) is used very 
> often 
>
> > Moreover, if I try to run the iteration a second time, everything 
> including 
> > errors is reported back 
> Well that is good, nevertheless we just spend 5 E-Mails back and 
> forth, hunting down a bug you introduced yourself. 
> And I now recall you made that change to filter gromacs "Read frame 
> XXX" message, which is fixed when using a newer gromacs version 
> (>=2016.3), see: 
>
> https://github.com/votca/csg/commit/155eb770873a6f65bac372c9f8c5efc9f3a4be75 
>
> > 
> > Anyway, my primary issue is not about messages, but to make it work 
> > correctly for distributions. 
> Like I said in the other email if section 7.3.2 is right, a mapping 
> file might be needed only for IMC, but even that I think is not true 
> anymore in v1.3.1. 
> So you need to figure out, which exclusions you want to read the ones 
> from the mapping file or the ones the tpr. 
> For the former specify a mapping file or the latter don't. 
>
> And then you can use csg_dump with or without --cg option to check the 
> exclusions! 
> $ csg_dump --top topol.tpr --excl 
> or 
> $ csg_dump --top topol.tpr --excl --cg mapping.xml. 
>
> Christoph 
>

Well, I can of course, but v1.4.1 does not use any special rdf.topol tag 
(so I have to introduce it myself):

sim_prog="$(csg_get_property cg.inverse.program)"

topol=$(csg_get_property cg.inverse.$sim_prog.topol)
[[ -f $topol ]] || die "${0##*/}: topol file '$topol' not found, possibly 
you have to add it to cg.inverse.filelist"

traj=$(csg_get_property cg.inverse.$sim_prog.traj)
[[ -f $traj ]] || die "${0##*/}: traj file '$traj' not found"

equi_time="$(csg_get_property cg.inverse.$sim_prog.equi_time)"
if [[ ${CSG_RUNTEST} ]] && csg_calc "$equi_time" ">" "0"; then
  msg --color blue --to-stderr "Automatically setting equi_time to 0, 
because CSG_RUNTEST was set"
  equi_time=0
fi

first_frame="$(csg_get_property cg.inverse.$sim_prog.first_frame)"

tasks=$(get_number_tasks)
msg "Calculating IMC statistics using $tasks tasks"
if is_done "imc_analysis"; then
  echo "IMC analysis is already done"
else
  #copy+resample all target dist in $this_dir
  for_all "non-bonded bonded" do_external resample target 
'$(csg_get_interaction_property inverse.target)' 
'$(csg_get_interaction_property name).dist.tgt'

  critical csg_stat --do-imc --options "$CSGXMLFILE" --top "$topol" --trj 
"$traj" --begin $equi_time --first-frame $first_frame --nt $tasks
  mark_done "imc_analysis"
fi

 

>
> > 
> > Andrey 
> > 
> > On Monday, July 23, 2018 at 2:33:44 PM UTC+1, Christoph Junghans wrote: 
> >> 
> >> On Mon, Jul 23, 2018 at 7:28 AM, 'Andrey Brukhno' via votca 
> >>  wrote: 
> >> > Christoph, 
> >> > 
> >> > I think I figured why there is no log msg for critical csg_stat in 
> >> > calc_rdfgeneric.sh. 
> >> > The fact is I override the inverse.sh script with the one having this 
> >> > (to 
> >> > avoid all the frame numbers when reading trajectory files): 
> >> > 
> >> >log="${PWD}/${log##*/}" 
> >> >export CSGLOG="$log" 
> >> >if [[ -f $CSGLOG ]]; then 
> >> >  exec 3>&1 4>&2 >> "$CSGLOG" 2>&1 
> >> >  echo -e "\n\n##" 
> >> >  #echo "# Appending to existing logfile #" 
> >> >  echo"# Appending to logfile (+errors) #" 
> >> >  echo -e "##\n\n" 
> >> >  msg --color blue "Appending to existing logfile (+errors) 
> >> > ${CSGLOG##*/}" 
> >> >else 
> >> >  exec 3>&1 4>&2 >> "$CSGLOG" 2>/dev/null 
> >> >  echo -e "\n\n##" 
> >> >  echo"# Creating new logfile (-errors) #" 
> >> >  echo -e "##\n\n" 
> >> >  msg "For a more verbose log see: ${CSGLOG##*/} (or 
> >> > csg_inverse.log)" 
> >

Re: [votca] special tpr for RDF calculations

['Andrey Brukhno' via votca]

On Monday, July 23, 2018 at 3:17:49 PM UTC+1, Christoph Junghans wrote:
>
> On Mon, Jul 23, 2018 at 7:41 AM, 'Andrey Brukhno' via votca 
> > wrote: 
> > In this case, it's not an error message which is lost ;) Why does it go 
> to 
> > stderr at all? 
> The code has the reason right there: 
> #print this message to stderr because $(critical something) is used very 
> often 
>
> > Moreover, if I try to run the iteration a second time, everything 
> including 
> > errors is reported back 
> Well that is good, nevertheless we just spend 5 E-Mails back and 
> forth, hunting down a bug you introduced yourself. 
> And I now recall you made that change to filter gromacs "Read frame 
> XXX" message, which is fixed when using a newer gromacs version 
> (>=2016.3), see: 
>
> https://github.com/votca/csg/commit/155eb770873a6f65bac372c9f8c5efc9f3a4be75 
>
> > 
> > Anyway, my primary issue is not about messages, but to make it work 
> > correctly for distributions. 
> Like I said in the other email if section 7.3.2 is right, a mapping 
> file might be needed only for IMC, but even that I think is not true 
> anymore in v1.3.1. 
>

My test IMC iteration went through without tagging the 1:1 CG map file.
 

> So you need to figure out, which exclusions you want to read the ones 
> from the mapping file or the ones the tpr. 
> For the former specify a mapping file or the latter don't. 
>

OK, I preferred the exclusions from topol-rdf.tpr (which appears to work 
now for IBI), so I skipped the map tags in my settings file for IMC too. 
However, the distributions are still wrong in the case of IMC.
 

>
> And then you can use csg_dump with or without --cg option to check the 
> exclusions! 
> $ csg_dump --top topol.tpr --excl 
> or 
> $ csg_dump --top topol.tpr --excl --cg mapping.xml. 
>
> Christoph 
>
> > 
> > Andrey 
> > 
> > On Monday, July 23, 2018 at 2:33:44 PM UTC+1, Christoph Junghans wrote: 
> >> 
> >> On Mon, Jul 23, 2018 at 7:28 AM, 'Andrey Brukhno' via votca 
> >>  wrote: 
> >> > Christoph, 
> >> > 
> >> > I think I figured why there is no log msg for critical csg_stat in 
> >> > calc_rdfgeneric.sh. 
> >> > The fact is I override the inverse.sh script with the one having this 
> >> > (to 
> >> > avoid all the frame numbers when reading trajectory files): 
> >> > 
> >> >log="${PWD}/${log##*/}" 
> >> >export CSGLOG="$log" 
> >> >if [[ -f $CSGLOG ]]; then 
> >> >  exec 3>&1 4>&2 >> "$CSGLOG" 2>&1 
> >> >  echo -e "\n\n##" 
> >> >  #echo "# Appending to existing logfile #" 
> >> >  echo"# Appending to logfile (+errors) #" 
> >> >  echo -e "##\n\n" 
> >> >  msg --color blue "Appending to existing logfile (+errors) 
> >> > ${CSGLOG##*/}" 
> >> >else 
> >> >  exec 3>&1 4>&2 >> "$CSGLOG" 2>/dev/null 
> >> >  echo -e "\n\n##" 
> >> >  echo"# Creating new logfile (-errors) #" 
> >> >  echo -e "##\n\n" 
> >> >  msg "For a more verbose log see: ${CSGLOG##*/} (or 
> >> > csg_inverse.log)" 
> >> >fi 
> >> > 
> >> > This worked before and did not affect the workflow. 
> >> Glad, you found it and it is not VOTCA's original code. 
> >> I remember now that you did this modification for a reason, which I 
> >> didn't like exactly because error message will get lost. 
> >> 
> >> Anyhow, well in conclusion if you send the errors to dev/null, you 
> >> won't see some messages (like critical) in the log file. 
> >> 
> >> Christoph 
> >> > 
> >> > Andrey 
> >> > 
> >> > On Mon, Jul 23, 2018 at 1:50 PM, Christoph Junghans <
> jung...@votca.org> 
> >> > wrote: 
> >> >> 
> >> >> On Mon, Jul 23, 2018 at 6:46 AM, 'Andrey Brukhno' via votca 
> >> >>  wrote: 
> >> >> > Sorry, I forgot - below is the output of `grep critical 
> inverse.log' 
> >> >> > for 
> >> >> > one 
> >> >> > iteration: 
> >> >> > 
> >> >> > Running critical command 

Re: [votca] Re: csg_reupdate error: property not found: re.function

['Andrey Brukhno' via votca]

On Mon, Jul 23, 2018 at 5:07 PM, Christoph Junghans 
wrote:

> On Mon, Jul 23, 2018 at 9:22 AM, 'Andrey Brukhno' via votca
>  wrote:
> >
> >
> > On Friday, July 20, 2018 at 2:08:19 AM UTC+1, Christoph Junghans wrote:
> >>
> >>
> >>
> >> On Thu, Jul 19, 2018 at 17:26 'Andrey Brukhno' via votca
> >>  wrote:
> >>>
> >>>
> >>>
> >>> On Thursday, July 19, 2018 at 7:57:57 PM UTC+1, Christoph Junghans
> wrote:
> >>>>
> >>>> On Thu, Jul 19, 2018 at 10:44 AM, 'Andrey Brukhno' via votca
> >>>>  wrote:
> >>>> > I get:
> >>>> >
> >>>> > ...  ...
> >>>> > Total number of parameters to optimize: 333
> >>>> > an error occurred:
> >>>> > property not found: scale
> >>>> See here:
> >>>>
> >>>> https://github.com/votca/csg-tutorials/blob/master/spce/re/
> settings.xml#L69
> >>>>
> >>>> Christoph
> >>>>
> >>>
> >>> Actually, I am a bit confused not seeing re.traj tag for atomistic
> >>> trajectory. I thought RE iteration requires recalculating CG averages
> in
> >>> over atomistic ensemble (trajectory) for every new set of CG
> potentials?
> >>>
> >>> Also, what about the corresponding re.topology tag - specifying what?
> >>
> >> Both options exist:
> >>
> >> https://github.com/votca/csg/blob/master/share/scripts/
> inverse/update_re.sh#L30
> >>
> >
> > Just to clarify: above you confirm that the two tags
> > `cg.inverse.$sim_prog.re.topol' and `cg.inverse.$sim_prog.re.traj'
> specify
> > the tpr and xtc/trr files for the original fine-detail (atomistic)
> > simulation?
> No these are just options, which allow you to overwrite the
> coarse-grained topology and trajectory.
> Nothing atomistic here!
>

If so, I am back to my question of how are the averages over fine detail
(atomistic) ensemble calculated for a new CG model/FF at each iteration?
I am referring to Eqs. 2.24 and 2.26 in the manual (page 8).



>
> > For reference, below is the extract from `share/votca/xml/csg_defaults.
> xml',
> > where no traj tag is present (this is for v1.4.1, so perhaps in v1.5.1
> the
> > tag is there?):
> >
> >   
> >   
> > Special topology file to be used for
> > csg_reupdate
> >   
> >   
> >
> > Btw, my original question was: why these are not specified in
> `settings.xml'
> > in the (spce/re) case you referred to above?
> If they are not specified the default topology (topol.tpr) and default
> trajectory (traj.xtc) are used.
>
> >
> > Thanks / Andrey
> >
> >> Christoph
> >>
> >>>
> >>> 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 votca+un...@googlegroups.com.
> >>> To post to this group, send email to vo...@googlegroups.com.
> >>> 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 votca+unsubscr...@googlegroups.com.
> > To post to this group, send email to votca@googlegroups.com.
> > 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 a topic in the
> Google Groups "votca" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/votca/2Otu4QhLG_A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> votca+unsubscr...@googlegroups.com.
> To post to this group, send email to votca@googlegroups.com.
> 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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

Re: [votca] Hessian NOT a positive definite!

['Andrey Brukhno' via votca]

Hi Sikandar,

I think the notation in my graphs is pretty clear: I compare *.param-init
files and the interpolated data stored as *.pot.cur files which should
overlay on top of each other (if interpolation works well).

Regarding the grids, sure the knot points are not the same as the grid
points for interpolated data, otherwise there is no reason to interpolate.
However, in the tutorial for `spcre/re' the lines for param.init and
-ln(g_{target}(r)) are not shifted with respect to each other along X axis.
Whereas upon interpolation of my data provided in param.init files the
lines get shifted by the bin size of the knot grid (not the finer
interpolation grid).

The question is why interpolation with B-splines results in shifted along X
data?

Thanks
Andrey

On Mon, Jul 23, 2018 at 5:45 PM, Sikandar Mashayak 
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 
> wrote:
>
>> On Mon, Jul 23, 2018 at 9:28 AM, 'Andrey Brukhno' via votca
>>  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
>> >

Re: [votca] Re: csg_reupdate error: property not found: re.function

['Andrey Brukhno' via votca]

On Friday, July 20, 2018 at 2:08:19 AM UTC+1, Christoph Junghans wrote:
>
>
>
> On Thu, Jul 19, 2018 at 17:26 'Andrey Brukhno' via votca <
> vo...@googlegroups.com > wrote:
>
>>
>>
>> On Thursday, July 19, 2018 at 7:57:57 PM UTC+1, Christoph Junghans wrote:
>>
>>> On Thu, Jul 19, 2018 at 10:44 AM, 'Andrey Brukhno' via votca 
>>>  wrote: 
>>> > I get: 
>>> > 
>>> > ...  ... 
>>> > Total number of parameters to optimize: 333 
>>> > an error occurred: 
>>> > property not found: scale 
>>> See here: 
>>>
>>> https://github.com/votca/csg-tutorials/blob/master/spce/re/settings.xml#L69 
>>>
>>> Christoph 
>>>
>>>
>> Actually, I am a bit confused not seeing re.traj tag for atomistic 
>> trajectory. I thought RE iteration requires recalculating CG averages in 
>> over atomistic ensemble (trajectory) for every new set of CG potentials? 
>>
>> Also, what about the corresponding re.topology tag - specifying what? 
>>
> Both options exist:
>
> https://github.com/votca/csg/blob/master/share/scripts/inverse/update_re.sh#L30
>  
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fvotca%2Fcsg%2Fblob%2Fmaster%2Fshare%2Fscripts%2Finverse%2Fupdate_re.sh%23L30=D=1=AFQjCNEEozkeKJ5aVFQqSFNQw33vb5y8OA>
>
>
Just to clarify: above you confirm that the two tags 
`cg.inverse.$sim_prog.re.topol' and `cg.inverse.$sim_prog.re.traj' specify 
the tpr and xtc/trr files for the original fine-detail (atomistic) 
simulation?
For reference, below is the extract from 
`share/votca/xml/csg_defaults.xml', where no traj tag is present (this is 
for v1.4.1, so perhaps in v1.5.1 the tag is there?):

  
  
Special topology file to be used for 
csg_reupdate
  
  

Btw, my original question was: why these are not specified in 
`settings.xml' in the (spce/re) case you referred to above?

Thanks / Andrey

Christoph 
>
>
>> 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 votca+un...@googlegroups.com .
>> To post to this group, send email to vo...@googlegroups.com 
>> .
>> 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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

Re: [votca] special tpr for RDF calculations

['Andrey Brukhno' via votca]

In this case, it's not an error message which is lost ;) Why does it go to 
stderr at all?
Moreover, if I try to run the iteration a second time, everything including 
errors is reported back

Anyway, my primary issue is not about messages, but to make it work 
correctly for distributions.

Andrey

On Monday, July 23, 2018 at 2:33:44 PM UTC+1, Christoph Junghans wrote:
>
> On Mon, Jul 23, 2018 at 7:28 AM, 'Andrey Brukhno' via votca 
> > wrote: 
> > Christoph, 
> > 
> > I think I figured why there is no log msg for critical csg_stat in 
> > calc_rdfgeneric.sh. 
> > The fact is I override the inverse.sh script with the one having this 
> (to 
> > avoid all the frame numbers when reading trajectory files): 
> > 
> >log="${PWD}/${log##*/}" 
> >export CSGLOG="$log" 
> >if [[ -f $CSGLOG ]]; then 
> >  exec 3>&1 4>&2 >> "$CSGLOG" 2>&1 
> >  echo -e "\n\n##" 
> >  #echo "# Appending to existing logfile #" 
> >  echo"# Appending to logfile (+errors) #" 
> >  echo -e "##\n\n" 
> >  msg --color blue "Appending to existing logfile (+errors) 
> > ${CSGLOG##*/}" 
> >else 
> >  exec 3>&1 4>&2 >> "$CSGLOG" 2>/dev/null 
> >  echo -e "\n\n##" 
> >  echo"# Creating new logfile (-errors) #" 
> >  echo -e "##\n\n" 
> >  msg "For a more verbose log see: ${CSGLOG##*/} (or 
> csg_inverse.log)" 
> >fi 
> > 
> > This worked before and did not affect the workflow. 
> Glad, you found it and it is not VOTCA's original code. 
> I remember now that you did this modification for a reason, which I 
> didn't like exactly because error message will get lost. 
>
> Anyhow, well in conclusion if you send the errors to dev/null, you 
> won't see some messages (like critical) in the log file. 
>
> Christoph 
> > 
> > Andrey 
> > 
> > On Mon, Jul 23, 2018 at 1:50 PM, Christoph Junghans  > 
> > wrote: 
> >> 
> >> On Mon, Jul 23, 2018 at 6:46 AM, 'Andrey Brukhno' via votca 
> >> > wrote: 
> >> > Sorry, I forgot - below is the output of `grep critical inverse.log' 
> for 
> >> > one 
> >> > iteration: 
> >> > 
> >> > Running critical command 'gmx grompp -n index.ndx -f grompp.mdp -p 
> >> > topol.top 
> >> > -o topol.tpr -c conf.gro' 
> >> > Running critical command 'gmx grompp -n index.ndx -f grompp.mdp -p 
> >> > topol.top 
> >> > -o topol.tpr -c conf.gro' 
> >> > Running critical command 'gmx grompp -n index.ndx -f grompp.mdp -p 
> >> > topol.top 
> >> > -o topol.tpr -c conf.gro' 
> >> > Running critical command 'gmx grompp -n index.ndx -f grompp.mdp -p 
> >> > topol.top 
> >> > -o topol.tpr -c conf.gro' 
> >> > Running critical command 'mpirun -n 4 mdrun_mpi -s topol.tpr -c 
> >> > confout.gro 
> >> > -o traj.trr -x traj.xtc -cpi state.cpt -maxh 47.8289 -multidir sim_0 
> >> > sim_1 
> >> > sim_2 sim_3 -tablep table.xvg -tableb table_b1.xvg table_b2.xvg 
> >> > table_b3.xvg 
> >> > table_b4.xvg table_b5.xvg table_a1.xvg table_a2.xvg table_a3.xvg 
> >> > table_a4.xvg table_a5.xvg table_d1.xvg table_d2.xvg table_d3.xvg 
> >> > table_d4.xvg table_d5.xvg table_d6.xvg' 
> >> > Doing: critical csg_stat --nt 4 --options 
> >> > 
> >> > 
> /home/andrey/Work/Models/DOPC-long-wtip4p-new/ibi-Rc1.65nm-freeN-dihs_CG-fits1-151cNT/dopc_cg-int-map11.xml
>  
>
> >> > --top topol-rdf.tpr --trj traj.xtc --begin 0 --first-frame 0 
> >> > --block-length 
> >> > 100 --ext dist.block --cg 
> >> > 
> >> > 
> /home/andrey/Work/Models/DOPC-long-wtip4p-new/ibi-Rc1.65nm-freeN-dihs_CG-fits1-151cNT/dopc_cg-map11.xml;
>  
>
> >> > 
> >> > As you can see, the only mention of `critical csg_stat' is due to my 
> >> > addition of echo. 
> >> Well, the other lines with "Running critical command" show that the 
> >> logging actually works. 
> >> Did you overload calc_rdf_generic.sh with your own version? 
> >> Otherwise, I would say your installation is bourked up. 
> >> 
> >> Christoph 
> >> >

Re: [votca] special tpr for RDF calculations

['Andrey Brukhno' via votca]

t; >> > ‘sim_0/topol-rdf.tpr’ -> ‘./topol-rdf.tpr’
> >> >> >> > Calculating rdfs with csg_stat using 4 tasks
> >> >> >> > Calculating average rdfs and its errors for interaction TCH-TCH
> >> >> >> > rdf calculation is already done
> >> >> >> > Calculating average rdfs and its errors for interaction TCH-TCO
> >> >> >> > rdf calculation is already done
> >> >> >> > Calculating average rdfs and its errors for interaction TCO-TCO
> >> >> >> > rdf calculation is already done
> >> >> >> > Calculating average rdfs and its errors for interaction TCH-PO
> >> >> >> > rdf calculation is already done
> >> >> >> > Calculating average rdfs and its errors for interaction TCH-NH
> >> >> >> > rdf calculation is already done
> >> >> >> > Calculating average rdfs and its errors for interaction TCO-PO
> >> >> >> > rdf calculation is already done
> >> >> >> > Calculating average rdfs and its errors for interaction TCO-NH
> >> >> >> > rdf calculation is already done
> >> >> >> > Calculating average rdfs and its errors for interaction PO-PO
> >> >> >> > rdf calculation is already done
> >> >> >> > Calculating average rdfs and its errors for interaction PO-NH
> >> >> >> > rdf calculation is already done
> >> >> >> > Calculating average rdfs and its errors for interaction NH-NH
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > On Sun, Jul 22, 2018 at 1:26 PM, Christoph Junghans
> >> >> >> > 
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> On Sat, Jul 21, 2018 at 9:01 PM, 'Andrey Brukhno' via votca
> >> >> >> >>  wrote:
> >> >> >> >> > Hello,
> >> >> >> >> >
> >> >> >> >> > I encountered a very strange (looks like legacy) issue with
> >> >> >> >> > v1.4.1.
> >> >> >> >> > In my earlier IBI iterations (with v1.3) I normally used
> >> >> >> >> > special
> >> >> >> >> > topol-rdf.tpr which was different from normal CG simulation
> >> >> >> >> > topol.tpr
> >> >> >> >> > by
> >> >> >> >> > not
> >> >> >> >> > including the intra-molecular pairs in the RDF stats (done by
> >> >> >> >> > csg_stat).
> >> >> >> >> > I
> >> >> >> >> > wanted to make sure my previous results are reproduced by
> >> >> >> >> > v1.4.1,
> >> >> >> >> > so
> >> >> >> >> > copied
> >> >> >> >> > all the initialisation files into a new directory and tried
> to
> >> >> >> >> > run
> >> >> >> >> > once
> >> >> >> >> > again. After the very first iteration I checked the obtained
> >> >> >> >> > RDFs
> >> >> >> >> > and
> >> >> >> >> > they
> >> >> >> >> > were all wrong - corresponding to normal topol.tpr (including
> >> >> >> >> > intra-pairs)
> >> >> >> >> > and not topol-rdf.tpr (excluding intra-pairs)!
> >> >> >> >> >
> >> >> >> >> > I guess there might have been changes made to locations or
> >> >> >> >> > names
> >> >> >> >> > of
> >> >> >> >> > tags
> >> >> >> >> > in
> >> >> >> >> > settings.xml between the VOTCA versions, but I could not
> >> >> >> >> > identify
> >> >> >> >> > those
> >> >> >> >> > changes by referring to the most recent manual (both v1.4.1
> and
> >> >> >> >> > development
> >> >> >> >> > versions).
> >> >> >> >> >
> >> >> >> >&

Re: [votca] special tpr for RDF calculations

['Andrey Brukhno' via votca]

Christoph,

I think I figured why there is no log msg for critical csg_stat in
calc_rdfgeneric.sh.
The fact is I override the inverse.sh script with the one having this (to
avoid all the frame numbers when reading trajectory files):

   log="${PWD}/${log##*/}"
   export CSGLOG="$log"
   if [[ -f $CSGLOG ]]; then
 exec 3>&1 4>&2 >> "$CSGLOG" 2>&1
 echo -e "\n\n##"
 #echo "# Appending to existing logfile #"
 echo"# Appending to logfile (+errors) #"
 echo -e "##\n\n"
 msg --color blue "Appending to existing logfile (+errors)
${CSGLOG##*/}"
   else
 exec 3>&1 4>&2 >> "$CSGLOG" 2>/dev/null
 echo -e "\n\n##"
 echo"# Creating new logfile (-errors) #"
 echo -e "##\n\n"
 msg "For a more verbose log see: ${CSGLOG##*/} (or csg_inverse.log)"
   fi

This worked before and did not affect the workflow.

Andrey

On Mon, Jul 23, 2018 at 1:50 PM, Christoph Junghans 
wrote:

> On Mon, Jul 23, 2018 at 6:46 AM, 'Andrey Brukhno' via votca
>  wrote:
> > Sorry, I forgot - below is the output of `grep critical inverse.log' for
> one
> > iteration:
> >
> > Running critical command 'gmx grompp -n index.ndx -f grompp.mdp -p
> topol.top
> > -o topol.tpr -c conf.gro'
> > Running critical command 'gmx grompp -n index.ndx -f grompp.mdp -p
> topol.top
> > -o topol.tpr -c conf.gro'
> > Running critical command 'gmx grompp -n index.ndx -f grompp.mdp -p
> topol.top
> > -o topol.tpr -c conf.gro'
> > Running critical command 'gmx grompp -n index.ndx -f grompp.mdp -p
> topol.top
> > -o topol.tpr -c conf.gro'
> > Running critical command 'mpirun -n 4 mdrun_mpi -s topol.tpr -c
> confout.gro
> > -o traj.trr -x traj.xtc -cpi state.cpt -maxh 47.8289 -multidir sim_0
> sim_1
> > sim_2 sim_3 -tablep table.xvg -tableb table_b1.xvg table_b2.xvg
> table_b3.xvg
> > table_b4.xvg table_b5.xvg table_a1.xvg table_a2.xvg table_a3.xvg
> > table_a4.xvg table_a5.xvg table_d1.xvg table_d2.xvg table_d3.xvg
> > table_d4.xvg table_d5.xvg table_d6.xvg'
> > Doing: critical csg_stat --nt 4 --options
> > /home/andrey/Work/Models/DOPC-long-wtip4p-new/ibi-Rc1.65nm-
> freeN-dihs_CG-fits1-151cNT/dopc_cg-int-map11.xml
> > --top topol-rdf.tpr --trj traj.xtc --begin 0 --first-frame 0
> --block-length
> > 100 --ext dist.block --cg
> > /home/andrey/Work/Models/DOPC-long-wtip4p-new/ibi-Rc1.65nm-
> freeN-dihs_CG-fits1-151cNT/dopc_cg-map11.xml;
> >
> > As you can see, the only mention of `critical csg_stat' is due to my
> > addition of echo.
> Well, the other lines with "Running critical command" show that the
> logging actually works.
> Did you overload calc_rdf_generic.sh with your own version?
> Otherwise, I would say your installation is bourked up.
>
> Christoph
> >
> > Andrey
> >
> > On Monday, July 23, 2018 at 1:17:32 PM UTC+1, Christoph Junghans wrote:
> >>
> >> On Mon, Jul 23, 2018 at 2:39 AM, 'Andrey Brukhno' via votca
> >>  wrote:
> >> >
> >> > On Mon, Jul 23, 2018 at 2:22 AM, Christoph Junghans <
> jung...@votca.org>
> >> > wrote:
> >> >>
> >> >> On Sun, Jul 22, 2018 at 1:27 PM, 'Andrey Brukhno' via votca
> >> >>  wrote:
> >> >> > Thanks for your reply Christoph.
> >> >> >
> >> >> > I did check it, but inverse.log does not contain sufficient info,
> see
> >> >> > the
> >> >> > extract below.
> >> >> > I will be investigating it further to make sure I did not do
> anything
> >> >> > stupid
> >> >> > myself, although I haven't changed much for the test iteration
> except
> >> >> > recompiling the tpr files for the newer version of Gromacs).
> >> >> The " rdf calculation is already done" tells me that this is not a
> run
> >> >> from scratch.
> >> >> Try a fresh run, because some chance in the xml don't get populated
> >> >> until the next iteration step.
> >> >>  And grep for "csg_stat" (not rdf), you should see actually command,
> >> >> which got run, e.g.:
> >> >> "Running critical command 'csg_stat --nt 4 --options settings.xml
> >> >> --top topol.tpr --trj traj.xtc --begin 20 --first-frame 0' "
> >> >> From that you can see i

Re: [votca] special tpr for RDF calculations

['Andrey Brukhno' via votca]

On Mon, Jul 23, 2018 at 1:50 PM, Christoph Junghans 
wrote:

> On Mon, Jul 23, 2018 at 6:46 AM, 'Andrey Brukhno' via votca
>  wrote:
> > Sorry, I forgot - below is the output of `grep critical inverse.log' for
> one
> > iteration:
> >
> > Running critical command 'gmx grompp -n index.ndx -f grompp.mdp -p
> topol.top
> > -o topol.tpr -c conf.gro'
> > Running critical command 'gmx grompp -n index.ndx -f grompp.mdp -p
> topol.top
> > -o topol.tpr -c conf.gro'
> > Running critical command 'gmx grompp -n index.ndx -f grompp.mdp -p
> topol.top
> > -o topol.tpr -c conf.gro'
> > Running critical command 'gmx grompp -n index.ndx -f grompp.mdp -p
> topol.top
> > -o topol.tpr -c conf.gro'
> > Running critical command 'mpirun -n 4 mdrun_mpi -s topol.tpr -c
> confout.gro
> > -o traj.trr -x traj.xtc -cpi state.cpt -maxh 47.8289 -multidir sim_0
> sim_1
> > sim_2 sim_3 -tablep table.xvg -tableb table_b1.xvg table_b2.xvg
> table_b3.xvg
> > table_b4.xvg table_b5.xvg table_a1.xvg table_a2.xvg table_a3.xvg
> > table_a4.xvg table_a5.xvg table_d1.xvg table_d2.xvg table_d3.xvg
> > table_d4.xvg table_d5.xvg table_d6.xvg'
> > Doing: critical csg_stat --nt 4 --options
> > /home/andrey/Work/Models/DOPC-long-wtip4p-new/ibi-Rc1.65nm-
> freeN-dihs_CG-fits1-151cNT/dopc_cg-int-map11.xml
> > --top topol-rdf.tpr --trj traj.xtc --begin 0 --first-frame 0
> --block-length
> > 100 --ext dist.block --cg
> > /home/andrey/Work/Models/DOPC-long-wtip4p-new/ibi-Rc1.65nm-
> freeN-dihs_CG-fits1-151cNT/dopc_cg-map11.xml;
> >
> > As you can see, the only mention of `critical csg_stat' is due to my
> > addition of echo.
> Well, the other lines with "Running critical command" show that the
> logging actually works.
> Did you overload calc_rdf_generic.sh with your own version?
>

Nope! It is what spack installed for me, except I recently added that
`echo' for `critical csg_stat ...'
I do use my run_gromacs.sh and run_gromacs_tasks.sh scripts but these do
not affect RDF calculations.



> Otherwise, I would say your installation is bourked up.
>

Spack to blame then?

Andrey

>
> Christoph
> >
> > Andrey
> >
> > On Monday, July 23, 2018 at 1:17:32 PM UTC+1, Christoph Junghans wrote:
> >>
> >> On Mon, Jul 23, 2018 at 2:39 AM, 'Andrey Brukhno' via votca
> >>  wrote:
> >> >
> >> > On Mon, Jul 23, 2018 at 2:22 AM, Christoph Junghans <
> jung...@votca.org>
> >> > wrote:
> >> >>
> >> >> On Sun, Jul 22, 2018 at 1:27 PM, 'Andrey Brukhno' via votca
> >> >>  wrote:
> >> >> > Thanks for your reply Christoph.
> >> >> >
> >> >> > I did check it, but inverse.log does not contain sufficient info,
> see
> >> >> > the
> >> >> > extract below.
> >> >> > I will be investigating it further to make sure I did not do
> anything
> >> >> > stupid
> >> >> > myself, although I haven't changed much for the test iteration
> except
> >> >> > recompiling the tpr files for the newer version of Gromacs).
> >> >> The " rdf calculation is already done" tells me that this is not a
> run
> >> >> from scratch.
> >> >> Try a fresh run, because some chance in the xml don't get populated
> >> >> until the next iteration step.
> >> >>  And grep for "csg_stat" (not rdf), you should see actually command,
> >> >> which got run, e.g.:
> >> >> "Running critical command 'csg_stat --nt 4 --options settings.xml
> >> >> --top topol.tpr --trj traj.xtc --begin 20 --first-frame 0' "
> >> >> From that you can see if all the options are read as excepted.
> >> >>
> >> >
> >> > I knew you were going to say this...
> >> > As a matter of fact, there is no such message from
> calc_rdf_generic.sh,
> >> > but
> >> > instead:
> >> >
> >> >   msg "Calculating rdfs with csg_stat using $tasks tasks"
> >> >   critical csg_stat --nt $tasks --options "$CSGXMLFILE" --top "$topol"
> >> > --trj
> >> > "$traj" --begin $equi_time --first-frame $first_frame ${error_opts}
> >> > ${maps:+--cg ${maps}}
> >> >   mark_done "rdf_calculation${suffix}"
> >> Well the "critical" function includes the print statement:
> >> critical() {
> >>   [[ $quiet = "no" ]] && echo "Running 

Re: [votca] special tpr for RDF calculations

['Andrey Brukhno' via votca]

On Mon, Jul 23, 2018 at 1:46 PM, Christoph Junghans 
wrote:

> On Mon, Jul 23, 2018 at 6:39 AM, 'Andrey Brukhno' via votca
>  wrote:
> > On Mon, Jul 23, 2018 at 1:17 PM, Christoph Junghans 
> > wrote:
> >>
> >> On Mon, Jul 23, 2018 at 2:39 AM, 'Andrey Brukhno' via votca
> >>  wrote:
> >> >
> >> > On Mon, Jul 23, 2018 at 2:22 AM, Christoph Junghans <
> jungh...@votca.org>
> >> > wrote:
> >> >>
> >> >> On Sun, Jul 22, 2018 at 1:27 PM, 'Andrey Brukhno' via votca
> >> >>  wrote:
> >> >> > Thanks for your reply Christoph.
> >> >> >
> >> >> > I did check it, but inverse.log does not contain sufficient info,
> see
> >> >> > the
> >> >> > extract below.
> >> >> > I will be investigating it further to make sure I did not do
> anything
> >> >> > stupid
> >> >> > myself, although I haven't changed much for the test iteration
> except
> >> >> > recompiling the tpr files for the newer version of Gromacs).
> >> >> The " rdf calculation is already done" tells me that this is not a
> run
> >> >> from scratch.
> >> >> Try a fresh run, because some chance in the xml don't get populated
> >> >> until the next iteration step.
> >> >>  And grep for "csg_stat" (not rdf), you should see actually command,
> >> >> which got run, e.g.:
> >> >> "Running critical command 'csg_stat --nt 4 --options settings.xml
> >> >> --top topol.tpr --trj traj.xtc --begin 20 --first-frame 0' "
> >> >> From that you can see if all the options are read as excepted.
> >> >>
> >> >
> >> > I knew you were going to say this...
> >> > As a matter of fact, there is no such message from
> calc_rdf_generic.sh,
> >> > but
> >> > instead:
> >> >
> >> >   msg "Calculating rdfs with csg_stat using $tasks tasks"
> >> >   critical csg_stat --nt $tasks --options "$CSGXMLFILE" --top "$topol"
> >> > --trj
> >> > "$traj" --begin $equi_time --first-frame $first_frame ${error_opts}
> >> > ${maps:+--cg ${maps}}
> >> >   mark_done "rdf_calculation${suffix}"
> >> Well the "critical" function includes the print statement:
> >> critical() {
> >>   [[ $quiet = "no" ]] && echo "Running critical command '$*'" >&2
> >>"$@" || die "${FUNCNAME[0]}: '$*' failed"
> >> }
> >> So I am not sure when that got lost in your case.
> >> >
> >> > so I had to add this after the msg and before the csg_stat call:
> >> >   echo "Doing: critical csg_stat --nt $tasks --options "$CSGXMLFILE"
> >> > --top
> >> > "$topol" --trj "$traj" --begin $equi_time --first-frame $first_frame
> >> > ${error_opts} ${maps:+--cg ${maps}}"
> >> >
> >> > This shows me that topol-rdf.tpr is actually used (extract from
> >> > inverse.log):
> >> >
> >> > Make update for ibi
> >> > Calculating rdfs with csg_stat using 4 tasks
> >> > Doing: critical csg_stat --nt 4 --options
> >> >
> >> > /home/andrey/Work/Models/DOPC-long-wtip4p-new/ibi-Rc1.65nm-
> freeN-dihs_CG-fits1-151cT/dopc_cg-int-map11.xml
> >> > --top topol-rdf.tpr --trj traj.xtc --begin 0 --first-frame 0
> >> > --block-length
> >> > 100 --ext dist.block --cg
> >> >
> >> > /home/andrey/Work/Models/DOPC-long-wtip4p-new/ibi-Rc1.65nm-
> freeN-dihs_CG-fits1-151cT/dopc_cg-map11.xml;
> >> > begin to calculate distribution functions
> >> >
> >> > However, the distributions are still wrong, and I am lost now as to
> >> > which
> >> > program to blame (again all the initial files are the same as in my
> >> > previous
> >> > iteration).
> >> > I compared the outputs of `gmx dump topol-rdf.tpr' and `gmx dump
> >> > topol.tpr'
> >> > generated with the new Gromacs and everything seems alright, the
> >> > relevant
> >> > differences in exclusion lists are there.
> >> > The problem is also that the original calculation was done on a
> cluster
> >> > more
> >> > than a year ago, so I cannot reproduce exactly al

Re: [votca] special tpr for RDF calculations

['Andrey Brukhno' via votca]

Sorry, I forgot - below is the output of `grep critical inverse.log' for 
one iteration:

Running critical command 'gmx grompp -n index.ndx -f grompp.mdp -p 
topol.top -o topol.tpr -c conf.gro'
Running critical command 'gmx grompp -n index.ndx -f grompp.mdp -p 
topol.top -o topol.tpr -c conf.gro'
Running critical command 'gmx grompp -n index.ndx -f grompp.mdp -p 
topol.top -o topol.tpr -c conf.gro'
Running critical command 'gmx grompp -n index.ndx -f grompp.mdp -p 
topol.top -o topol.tpr -c conf.gro'
Running critical command 'mpirun -n 4 mdrun_mpi -s topol.tpr -c confout.gro 
-o traj.trr -x traj.xtc -cpi state.cpt -maxh 47.8289 -multidir sim_0 sim_1 
sim_2 sim_3 -tablep table.xvg -tableb table_b1.xvg table_b2.xvg 
table_b3.xvg table_b4.xvg table_b5.xvg table_a1.xvg table_a2.xvg 
table_a3.xvg table_a4.xvg table_a5.xvg table_d1.xvg table_d2.xvg 
table_d3.xvg table_d4.xvg table_d5.xvg table_d6.xvg'
Doing: critical csg_stat --nt 4 --options 
/home/andrey/Work/Models/DOPC-long-wtip4p-new/ibi-Rc1.65nm-freeN-dihs_CG-fits1-151cNT/dopc_cg-int-map11.xml
 
--top topol-rdf.tpr --trj traj.xtc --begin 0 --first-frame 0 --block-length 
100 --ext dist.block --cg 
/home/andrey/Work/Models/DOPC-long-wtip4p-new/ibi-Rc1.65nm-freeN-dihs_CG-fits1-151cNT/dopc_cg-map11.xml;

As you can see, the only mention of `critical csg_stat' is due to my 
addition of echo.

Andrey

On Monday, July 23, 2018 at 1:17:32 PM UTC+1, Christoph Junghans wrote:
>
> On Mon, Jul 23, 2018 at 2:39 AM, 'Andrey Brukhno' via votca 
> > wrote: 
> > 
> > On Mon, Jul 23, 2018 at 2:22 AM, Christoph Junghans  > 
> > wrote: 
> >> 
> >> On Sun, Jul 22, 2018 at 1:27 PM, 'Andrey Brukhno' via votca 
> >> > wrote: 
> >> > Thanks for your reply Christoph. 
> >> > 
> >> > I did check it, but inverse.log does not contain sufficient info, see 
> >> > the 
> >> > extract below. 
> >> > I will be investigating it further to make sure I did not do anything 
> >> > stupid 
> >> > myself, although I haven't changed much for the test iteration except 
> >> > recompiling the tpr files for the newer version of Gromacs). 
> >> The " rdf calculation is already done" tells me that this is not a run 
> >> from scratch. 
> >> Try a fresh run, because some chance in the xml don't get populated 
> >> until the next iteration step. 
> >>  And grep for "csg_stat" (not rdf), you should see actually command, 
> >> which got run, e.g.: 
> >> "Running critical command 'csg_stat --nt 4 --options settings.xml 
> >> --top topol.tpr --trj traj.xtc --begin 20 --first-frame 0' " 
> >> From that you can see if all the options are read as excepted. 
> >> 
> > 
> > I knew you were going to say this... 
> > As a matter of fact, there is no such message from calc_rdf_generic.sh, 
> but 
> > instead: 
> > 
> >   msg "Calculating rdfs with csg_stat using $tasks tasks" 
> >   critical csg_stat --nt $tasks --options "$CSGXMLFILE" --top "$topol" 
> --trj 
> > "$traj" --begin $equi_time --first-frame $first_frame ${error_opts} 
> > ${maps:+--cg ${maps}} 
> >   mark_done "rdf_calculation${suffix}" 
> Well the "critical" function includes the print statement: 
> critical() { 
>   [[ $quiet = "no" ]] && echo "Running critical command '$*'" >&2 
>"$@" || die "${FUNCNAME[0]}: '$*' failed" 
> } 
> So I am not sure when that got lost in your case. 
> > 
> > so I had to add this after the msg and before the csg_stat call: 
> >   echo "Doing: critical csg_stat --nt $tasks --options "$CSGXMLFILE" 
> --top 
> > "$topol" --trj "$traj" --begin $equi_time --first-frame $first_frame 
> > ${error_opts} ${maps:+--cg ${maps}}" 
> > 
> > This shows me that topol-rdf.tpr is actually used (extract from 
> > inverse.log): 
> > 
> > Make update for ibi 
> > Calculating rdfs with csg_stat using 4 tasks 
> > Doing: critical csg_stat --nt 4 --options 
> > 
> /home/andrey/Work/Models/DOPC-long-wtip4p-new/ibi-Rc1.65nm-freeN-dihs_CG-fits1-151cT/dopc_cg-int-map11.xml
>  
>
> > --top topol-rdf.tpr --trj traj.xtc --begin 0 --first-frame 0 
> --block-length 
> > 100 --ext dist.block --cg 
> > 
> /home/andrey/Work/Models/DOPC-long-wtip4p-new/ibi-Rc1.65nm-freeN-dihs_CG-fits1-151cT/dopc_cg-map11.xml;
>  
>
> > begin to calculate distribution functions 
> > 
> > However, the distributions are still wrong, and I am lost now as to 
> which 
> > program to blame (again al

Re: [votca] special tpr for RDF calculations

['Andrey Brukhno' via votca]

On Mon, Jul 23, 2018 at 1:17 PM, Christoph Junghans 
wrote:

> On Mon, Jul 23, 2018 at 2:39 AM, 'Andrey Brukhno' via votca
>  wrote:
> >
> > On Mon, Jul 23, 2018 at 2:22 AM, Christoph Junghans 
> > wrote:
> >>
> >> On Sun, Jul 22, 2018 at 1:27 PM, 'Andrey Brukhno' via votca
> >>  wrote:
> >> > Thanks for your reply Christoph.
> >> >
> >> > I did check it, but inverse.log does not contain sufficient info, see
> >> > the
> >> > extract below.
> >> > I will be investigating it further to make sure I did not do anything
> >> > stupid
> >> > myself, although I haven't changed much for the test iteration except
> >> > recompiling the tpr files for the newer version of Gromacs).
> >> The " rdf calculation is already done" tells me that this is not a run
> >> from scratch.
> >> Try a fresh run, because some chance in the xml don't get populated
> >> until the next iteration step.
> >>  And grep for "csg_stat" (not rdf), you should see actually command,
> >> which got run, e.g.:
> >> "Running critical command 'csg_stat --nt 4 --options settings.xml
> >> --top topol.tpr --trj traj.xtc --begin 20 --first-frame 0' "
> >> From that you can see if all the options are read as excepted.
> >>
> >
> > I knew you were going to say this...
> > As a matter of fact, there is no such message from calc_rdf_generic.sh,
> but
> > instead:
> >
> >   msg "Calculating rdfs with csg_stat using $tasks tasks"
> >   critical csg_stat --nt $tasks --options "$CSGXMLFILE" --top "$topol"
> --trj
> > "$traj" --begin $equi_time --first-frame $first_frame ${error_opts}
> > ${maps:+--cg ${maps}}
> >   mark_done "rdf_calculation${suffix}"
> Well the "critical" function includes the print statement:
> critical() {
>   [[ $quiet = "no" ]] && echo "Running critical command '$*'" >&2
>"$@" || die "${FUNCNAME[0]}: '$*' failed"
> }
> So I am not sure when that got lost in your case.
> >
> > so I had to add this after the msg and before the csg_stat call:
> >   echo "Doing: critical csg_stat --nt $tasks --options "$CSGXMLFILE"
> --top
> > "$topol" --trj "$traj" --begin $equi_time --first-frame $first_frame
> > ${error_opts} ${maps:+--cg ${maps}}"
> >
> > This shows me that topol-rdf.tpr is actually used (extract from
> > inverse.log):
> >
> > Make update for ibi
> > Calculating rdfs with csg_stat using 4 tasks
> > Doing: critical csg_stat --nt 4 --options
> > /home/andrey/Work/Models/DOPC-long-wtip4p-new/ibi-Rc1.65nm-
> freeN-dihs_CG-fits1-151cT/dopc_cg-int-map11.xml
> > --top topol-rdf.tpr --trj traj.xtc --begin 0 --first-frame 0
> --block-length
> > 100 --ext dist.block --cg
> > /home/andrey/Work/Models/DOPC-long-wtip4p-new/ibi-Rc1.65nm-
> freeN-dihs_CG-fits1-151cT/dopc_cg-map11.xml;
> > begin to calculate distribution functions
> >
> > However, the distributions are still wrong, and I am lost now as to which
> > program to blame (again all the initial files are the same as in my
> previous
> > iteration).
> > I compared the outputs of `gmx dump topol-rdf.tpr' and `gmx dump
> topol.tpr'
> > generated with the new Gromacs and everything seems alright, the relevant
> > differences in exclusion lists are there.
> > The problem is also that the original calculation was done on a cluster
> more
> > than a year ago, so I cannot reproduce exactly all the installation
> setup,
> > not on my desktop anyway. But I know that those calculations were correct
> > and well converged.
> >
> > So something should have changed somewhere within the newly installed
> > Gromacs/VOTCA combination.
> You can see what VOTCA has with:
> csg_dump --top topol-rdf.tpr --cg dopc_cg-map11.xml
>

OK, but its output does not contain any info about the exclusions.


>
> Remember, if you are using a mapping file ("--cg" option) exclusions
> from the topology file are ignored and the ones from the mapping file
> are used instead.
>

Alright, this must be the root of my problem!
Apparently, in v1.3 csg_stat would take the exclusions from tpr, not xml,
because I never provided any exclusion list in any xml file, but it did
work correctly!

I will look into this again.

Andrey


>
> Christoph
> >
> > Andrey
> >
> >> Christoph
> >> >
> >> > Andrey
> >> >

Re: [votca] special tpr for RDF calculations

['Andrey Brukhno' via votca]

On Mon, Jul 23, 2018 at 2:22 AM, Christoph Junghans 
wrote:

> On Sun, Jul 22, 2018 at 1:27 PM, 'Andrey Brukhno' via votca
>  wrote:
> > Thanks for your reply Christoph.
> >
> > I did check it, but inverse.log does not contain sufficient info, see the
> > extract below.
> > I will be investigating it further to make sure I did not do anything
> stupid
> > myself, although I haven't changed much for the test iteration except
> > recompiling the tpr files for the newer version of Gromacs).
> The " rdf calculation is already done" tells me that this is not a run
> from scratch.
> Try a fresh run, because some chance in the xml don't get populated
> until the next iteration step.
>  And grep for "csg_stat" (not rdf), you should see actually command,
> which got run, e.g.:
> "Running critical command 'csg_stat --nt 4 --options settings.xml
> --top topol.tpr --trj traj.xtc --begin 20 --first-frame 0' "
> From that you can see if all the options are read as excepted.
>
>
I knew you were going to say this...
As a matter of fact, there is no such message from calc_rdf_generic.sh, but
instead:

  msg "Calculating rdfs with csg_stat using $tasks tasks"
  critical csg_stat --nt $tasks --options "$CSGXMLFILE" --top "$topol"
--trj "$traj" --begin $equi_time --first-frame $first_frame ${error_opts}
${maps:+--cg ${maps}}
  mark_done "rdf_calculation${suffix}"

so I had to add this after the msg and before the csg_stat call:
  echo "Doing: critical csg_stat --nt $tasks --options "$CSGXMLFILE" --top
"$topol" --trj "$traj" --begin $equi_time --first-frame $first_frame
${error_opts} ${maps:+--cg ${maps}}"

This shows me that topol-rdf.tpr is actually used (extract from
inverse.log):

Make update for ibi
Calculating rdfs with csg_stat using 4 tasks
Doing: critical csg_stat --nt 4 --options
/home/andrey/Work/Models/DOPC-long-wtip4p-new/ibi-Rc1.65nm-freeN-dihs_CG-fits1-151cT/dopc_cg-int-map11.xml
--top topol-rdf.tpr --trj traj.xtc --begin 0 --first-frame 0 --block-length
100 --ext dist.block --cg
/home/andrey/Work/Models/DOPC-long-wtip4p-new/ibi-Rc1.65nm-freeN-dihs_CG-fits1-151cT/dopc_cg-map11.xml;
begin to calculate distribution functions

However, the distributions are still wrong, and I am lost now as to which
program to blame (again all the initial files are the same as in my
previous iteration).
I compared the outputs of `gmx dump topol-rdf.tpr' and `gmx dump topol.tpr'
generated with the new Gromacs and everything seems alright, the relevant
differences in exclusion lists are there.
The problem is also that the original calculation was done on a cluster
more than a year ago, so I cannot reproduce exactly all the installation
setup, not on my desktop anyway. But I know that those calculations were
correct and well converged.

So something should have changed somewhere within the newly installed
Gromacs/VOTCA combination.

Andrey

Christoph
> >
> > Andrey
> > -
> > $ grep rdf inverse.log
> > ...
> > cp_from_main_dir: 'grompp.mdp* topol.top* topol-rdf.tpr table_??.xvg
> > index.ndx* conf.gro*'
> > cp_from_main_dir: 'grompp.mdp* topol.top* topol-rdf.tpr table_??.xvg
> > index.ndx* conf.gro*'
> > cp_from_main_dir: 'grompp.mdp* topol.top* topol-rdf.tpr table_??.xvg
> > index.ndx* conf.gro*'
> > cp_from_main_dir: 'grompp.mdp* topol.top* topol-rdf.tpr table_??.xvg
> > index.ndx* conf.gro*'
> > cp_from_main_dir: 'grompp.mdp* topol.top* topol-rdf.tpr table_??.xvg
> > index.ndx* conf.gro*'
> > ‘sim_0/topol-rdf.tpr’ -> ‘./topol-rdf.tpr’
> > Calculating rdfs with csg_stat using 4 tasks
> > Calculating average rdfs and its errors for interaction TCH-TCH
> > rdf calculation is already done
> > Calculating average rdfs and its errors for interaction TCH-TCO
> > rdf calculation is already done
> > Calculating average rdfs and its errors for interaction TCO-TCO
> > rdf calculation is already done
> > Calculating average rdfs and its errors for interaction TCH-PO
> > rdf calculation is already done
> > Calculating average rdfs and its errors for interaction TCH-NH
> > rdf calculation is already done
> > Calculating average rdfs and its errors for interaction TCO-PO
> > rdf calculation is already done
> > Calculating average rdfs and its errors for interaction TCO-NH
> > rdf calculation is already done
> > Calculating average rdfs and its errors for interaction PO-PO
> > rdf calculation is already done
> > Calculating average rdfs and its errors for interaction PO-NH
> > rdf calculation is already done
> > Calculating average rdfs and its errors for interaction NH-NH
> >
> >
> >
> > On 

Re: [votca] special tpr for RDF calculations

['Andrey Brukhno' via votca]

Thanks for your reply Christoph.

I did check it, but inverse.log does not contain sufficient info, see the
extract below.
I will be investigating it further to make sure I did not do anything
stupid myself, although I haven't changed much for the test iteration
except recompiling the tpr files for the newer version of Gromacs).

Andrey
-
$ grep rdf inverse.log
...
cp_from_main_dir: 'grompp.mdp* topol.top* topol-rdf.tpr table_??.xvg
index.ndx* conf.gro*'
cp_from_main_dir: 'grompp.mdp* topol.top* topol-rdf.tpr table_??.xvg
index.ndx* conf.gro*'
cp_from_main_dir: 'grompp.mdp* topol.top* topol-rdf.tpr table_??.xvg
index.ndx* conf.gro*'
cp_from_main_dir: 'grompp.mdp* topol.top* topol-rdf.tpr table_??.xvg
index.ndx* conf.gro*'
cp_from_main_dir: 'grompp.mdp* topol.top* topol-rdf.tpr table_??.xvg
index.ndx* conf.gro*'
‘sim_0/topol-rdf.tpr’ -> ‘./topol-rdf.tpr’
Calculating rdfs with csg_stat using 4 tasks
Calculating average rdfs and its errors for interaction TCH-TCH
rdf calculation is already done
Calculating average rdfs and its errors for interaction TCH-TCO
rdf calculation is already done
Calculating average rdfs and its errors for interaction TCO-TCO
rdf calculation is already done
Calculating average rdfs and its errors for interaction TCH-PO
rdf calculation is already done
Calculating average rdfs and its errors for interaction TCH-NH
rdf calculation is already done
Calculating average rdfs and its errors for interaction TCO-PO
rdf calculation is already done
Calculating average rdfs and its errors for interaction TCO-NH
rdf calculation is already done
Calculating average rdfs and its errors for interaction PO-PO
rdf calculation is already done
Calculating average rdfs and its errors for interaction PO-NH
rdf calculation is already done
Calculating average rdfs and its errors for interaction NH-NH



On Sun, Jul 22, 2018 at 1:26 PM, Christoph Junghans 
wrote:

> On Sat, Jul 21, 2018 at 9:01 PM, 'Andrey Brukhno' via votca
>  wrote:
> > Hello,
> >
> > I encountered a very strange (looks like legacy) issue with v1.4.1.
> > In my earlier IBI iterations (with v1.3) I normally used special
> > topol-rdf.tpr which was different from normal CG simulation topol.tpr by
> not
> > including the intra-molecular pairs in the RDF stats (done by csg_stat).
> I
> > wanted to make sure my previous results are reproduced by v1.4.1, so
> copied
> > all the initialisation files into a new directory and tried to run once
> > again. After the very first iteration I checked the obtained RDFs and
> they
> > were all wrong - corresponding to normal topol.tpr (including
> intra-pairs)
> > and not topol-rdf.tpr (excluding intra-pairs)!
> >
> > I guess there might have been changes made to locations or names of tags
> in
> > settings.xml between the VOTCA versions, but I could not identify those
> > changes by referring to the most recent manual (both v1.4.1 and
> development
> > versions).
> >
> > Below is the relevant extract from my settings.xml file.
> >
> > Any clue, hint, advice are most welcome!
> We haven't changes any tags in IBI since v1.4.1 and the special
> topology for IBI can be set by cg.inverse..rdf.topol, which
> you did below.
> You could try "grep csg_stat inverse.log" to figure out if the right
> topology got appended to the command line of csg_stat.
>
> Christoph
> >
> > Thanks in advance.
> > Andrey
> >
> > ---
> > 
> >   
> > gmx grompp
> > 
> >   
> >   
> > 
> > 
> > 
> > mpirun -n 4 mdrun_mpi
> > -multidir sim_0 sim_1 sim_2 sim_3 -tablep table.xvg -tableb
> > table_b?.xvg table_a?.xvg table_d?.xvg
> >   
> >   
> >   
> >   0
> >   
> >   0.001
> >   
> >   1
> >   
> >   2.5
> >   maindir
> >   
> > Length of the block for the error
> > analysis
> >   100
> > 
> > Special mapping file for rdf calculations needed for
> > bonded interactions
> >   dopc_cg-map11.xml
> > 
> >  Gromacs binary topol (tpr) file to be used for
> > csg_stat
> >   topol-rdf.tpr
> > 
> > yescalculate error on the rdf: yes/no
> > 
> >   
> > 
> > ---
> >
> > --
> > 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 votca+unsubscr...@googlegroups.com.
> > To post to 

[votca] special tpr for RDF calculations

['Andrey Brukhno' via votca]

Hello,

I encountered a very strange (looks like legacy) issue with v1.4.1.
In my earlier IBI iterations (with v1.3) I normally used special 
topol-rdf.tpr which was different from normal CG simulation topol.tpr by 
not including the intra-molecular pairs in the RDF stats (done by 
csg_stat). I wanted to make sure my previous results are reproduced by 
v1.4.1, so copied all the initialisation files into a new directory and 
tried to run once again. After the very first iteration I checked the 
obtained RDFs and they were all wrong - corresponding to normal topol.tpr 
(including intra-pairs) and not topol-rdf.tpr (excluding intra-pairs)!

I guess there might have been changes made to locations or names of tags in 
settings.xml between the VOTCA versions, but I could not identify those 
changes by referring to the most recent manual (both v1.4.1 and development 
versions).

Below is the relevant extract from my settings.xml file.

Any clue, hint, advice are most welcome!

Thanks in advance.
Andrey

---

  
gmx grompp

  
  



mpirun -n 4 mdrun_mpi
-multidir sim_0 sim_1 sim_2 sim_3 -tablep table.xvg -tableb 
table_b?.xvg table_a?.xvg table_d?.xvg
  
  
  
  0
  
  0.001
  
  1
  
  2.5
  maindir
  
Length of the block for the error 
analysis
  100

Special mapping file for rdf calculations needed for 
bonded interactions
  dopc_cg-map11.xml

 Gromacs binary topol (tpr) file to be used for 
csg_stat
  topol-rdf.tpr

yescalculate error on the rdf: yes/no

  

---

-- 
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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

Re: [votca] Missing, not found Eigen3 during VOTCA installation

['Andrey Brukhno' via votca]

On Sat, Jul 21, 2018 at 7:42 PM, Christoph Junghans 
wrote:

>
>
> On Fri, Jul 20, 2018 at 18:59 'Andrey Brukhno' via votca <
> votca@googlegroups.com> wrote:
>
>> By now I have installed SQLITE3, compiled latest version of Gromacs and
>> currently installing VOTCA.
>>
> I think i found that issue and fixed it in:
> https://github.com/votca/csg/pull/255
> and
> https://github.com/votca/votca/pull/76
>
>
Good to know!

+if(DEFINED WITH_SQLITE3 AND NOT WITH_SQLITE3)

sounds weird - perhaps it's just the computer logic :) just kidding...


>
> BTW, the Gromacs flag  -DWITH_GMX=ON did not work for me either.
>>
> Can you be a bit more specific what the problem was?
>
>
I wanted VOTCA to install Gromacs along with itself as it did before (build
script for v1.3 did),
but the flag -DWITHGMX=ON provided to cmake did not do that (seemed like it
ignored the flag),
so I had to install Gromacs newest version by myself.


>
>> Not sure what was the issue with the flag -DWITH_SQLITE3=OFF, but my
>> cmake version was below 3, so I had to reinstall it too.
>>
> Yeah, due to using C++11 we need CMake-3.1 now, but that should give an
> error immediately.
>
>
Yes, I was installing on my laptop and did not check the cmake version
first.
Then, after checking it, I was surprised it did not complain as it did on
my work desktop.

Andrey


> Christoph
>
>>
>> Thanks
>> Andrey
>>
>>
>>
>> On Sat, Jul 21, 2018 at 1:48 AM, Christoph Junghans 
>> wrote:
>>
>>>
>>>
>>> On Fri, Jul 20, 2018, 16:49 'Andrey Brukhno' via votca <
>>> votca@googlegroups.com> wrote:
>>>
>>>> Well, I tried to follow your instructions in this thread for "stable"
>>>> branch.
>>>>
>>> Just checked, worked for me. Can you open an github issue with all the
>>> details (commands, output etc.)
>>>
>>> Thanks,
>>>
>>> Christoph
>>>
>>>>
>>>> Andrey
>>>>
>>>> On Fri, 20 Jul 2018 22:41 Christoph Junghans, 
>>>> wrote:
>>>>
>>>>> On Fri, Jul 20, 2018 at 3:11 PM, 'Andrey Brukhno' via votca
>>>>>  wrote:
>>>>> > The problem is, I remembered this option for the old build script
>>>>> and tried
>>>>> > to use it with cmake but still got the error "sqlite3 not found".
>>>>> Which version of VOTCA are you using now?
>>>>>
>>>>> >
>>>>> > Andrey
>>>>> >
>>>>> > On Fri, 20 Jul 2018 21:56 Christoph Junghans, 
>>>>> wrote:
>>>>> >>
>>>>> >> On Fri, Jul 20, 2018 at 11:08 AM, 'Andrey Brukhno' via votca
>>>>> >>  wrote:
>>>>> >> > Christoph,
>>>>> >> >
>>>>> >> > What is the flag for cmake not to search for SQLITE3?
>>>>> >> WITH_SQLITE3=OFF, btw you can just look up the options in ccmake.
>>>>> >>
>>>>> >> Christoph
>>>>> >> >
>>>>> >> > Thanks
>>>>> >> > Andrey
>>>>> >> >
>>>>> >> >
>>>>> >> > On Thu, Jul 19, 2018 at 8:18 PM, Christoph Junghans <
>>>>> jungh...@votca.org>
>>>>> >> > wrote:
>>>>> >> >>
>>>>> >> >> On Thu, Jul 19, 2018 at 10:57 AM, 'Andrey Brukhno' via votca
>>>>> >> >>  wrote:
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >> > On Thursday, July 19, 2018 at 4:48:14 PM UTC+1, Christoph
>>>>> Junghans
>>>>> >> >> > wrote:
>>>>> >> >> >>
>>>>> >> >> >> >>
>>>>> >> >> >> >> > We recently fixed an issue in the Eigen3 detection:
>>>>> >> >> >> >> >
>>>>> >> >> >> >> >
>>>>> >> >> >> >> >
>>>>> >> >> >> >> >
>>>>> >> >> >> >> > https://github.com/votca/votca/commit/
>>>>> 8fdcedae9b46e1739fa2ef8589cd5a8f6881d420
>>>>> >> >> >> >> > which includes:
>>>>> >> >> >> &g

Re: [votca] Missing, not found Eigen3 during VOTCA installation

['Andrey Brukhno' via votca]

Ok, good to know! - Not that I could follow the workflow by the link though.

Andrey


On Sat, Jul 21, 2018 at 7:33 PM, Christoph Junghans 
wrote:

>
>
> On Thu, Jul 19, 2018 at 09:47 Christoph Junghans 
> wrote:
>
>> On Thu, Jul 19, 2018 at 9:33 AM, 'Andrey Brukhno' via votca
>>  wrote:
>> >
>> >
>> > On Thursday, July 19, 2018 at 3:27:52 PM UTC+1, Christoph Junghans
>> wrote:
>> >>
>> >> On Wed, Jul 18, 2018 at 12:20 PM, Christoph Junghans <
>> jung...@votca.org>
>> >> wrote:
>> >> > On Wed, Jul 18, 2018 at 12:04 PM, 'Andrey Brukhno' via votca
>> >> >  wrote:
>> >> >> Hello,
>> >> >>
>> >> >> The last time I was installing the CSG package in my Ubuntu
>> (up-to-date
>> >> >> 2014
>> >> >> LTS) I got this error from cmake: eigen3 not found, with a
>> suggestion
>> >> >> to
>> >> >> provide the path to it. I then downloaded the library from their
>> >> >> website,
>> >> >> installed it and added its include directory to both my $PATH and to
>> >> >> the
>> >> >> environment under the suggested name EIGEN3_INCLUDE_DIR. But cmake
>> >> >> still
>> >> >> complained and stopped with the same error, even when I fed it the
>> >> >> flag:
>> >> >> -DEIGEN3_INCLUDE_DIR=.
>> >> > Just a reminder that 2014 was already 4 years ago ;-)
>> >
>> >
>> > Thanks, up to now it did not hurt to stay with that version, but
>> eventually
>> > yes an upgrade is pending. :)
>> >
>> >>
>> >> > We recently fixed an issue in the Eigen3 detection:
>> >> >
>> >> > https://github.com/votca/votca/commit/8fdcedae9b46e1739fa2ef8589cd5a
>> 8f6881d420
>> >> > which includes:
>> >> >
>> >> > https://github.com/votca/tools/commit/3ee8b88e6022772b843f21a04f66a5
>> bd8bfddd09
>> >> >
>> >> > https://github.com/votca/csg/commit/c3f9b3e2841c4b5c0eac20e4d843f6
>> b108750ecf
>> >> > Did you use that version?
>> >
>> >
>> > No, I have not tried any newer version yet. My aim was to get the latest
>> > release installed, which spack did succeed to do (v1.4.1).
>> But then I don't understand your original error because votca-csg
>> 1.4.1 doesn't depend on Eigen3.
>>
>> >
>> > BTW, when I tried to install with apt-get nothing happened: no votca
>> package
>> > found. Perhaps it would only work for 2016(+) Ubuntu?
>> Yes, only 2016.4 and later:
>> https://packages.ubuntu.com/search?keywords=votca-csg;
>> searchon=names=all=all
>> and v1.4.1 only in Ubuntu 18.04!
>>
>> >
>> >>
>> >> >
>> >> >>
>> >> >> Not sure what went wrong, but I had to use alternative way of
>> >> >> installation
>> >> >> via spack, and it worked eventually, although it lloked like spack
>> >> >> installed
>> >> >> ALL the dependencies along with VOTCA in a separate directory,
>> which is
>> >> >> of
>> >> >> course an overkill.
>> >> > That is Spack's design, so don't complain to me! And yes we need to
>> >> > update the dependencies of the VOTCA package in Spack.
>> >> https://github.com/spack/spack/pull/8757
>> >
>> >
>> > I see... Otherwise I also noticed that spack installs csg and tools
>> > separately in two directories beside each other. But then VOTCARC.bash
>> etc
>> > occur in the tools/bin and VOTCASHARE points at votca_tools/share
>> instead of
>> > votca_csg/share, so the scripts/inverse are not found. I had to reset
>> > VOTCASHARE correctly in my .bashrc.
>> Good point I will have to think, how to fix that. I think the VOTCARC
>> file should get installed to start with as csg_inverse will
>> auto-detect the location (using csg_call in your PATH) if VOTCASHARE
>> isn't set.
>
> I dropped the install of the confusing VOTCARC in:
>
>> https://github.com/spack/spack/pull/8771
>
> Christoph
>
>>
>>
>> Christoph
>>
>> >
>> > I mentioned this for other users to be aware.
>> >
>> > Andrey
>> >>
>> >>
>> >> >>
>> >> >> I suppose this post is just to noti

Re: [votca] Missing, not found Eigen3 during VOTCA installation

['Andrey Brukhno' via votca]

By now I have installed SQLITE3, compiled latest version of Gromacs and
currently installing VOTCA.
BTW, the Gromacs flag  -DWITH_GMX=ON did not work for me either.
Not sure what was the issue with the flag -DWITH_SQLITE3=OFF, but my cmake
version was below 3, so I had to reinstall it too.

Thanks
Andrey



On Sat, Jul 21, 2018 at 1:48 AM, Christoph Junghans 
wrote:

>
>
> On Fri, Jul 20, 2018, 16:49 'Andrey Brukhno' via votca <
> votca@googlegroups.com> wrote:
>
>> Well, I tried to follow your instructions in this thread for "stable"
>> branch.
>>
> Just checked, worked for me. Can you open an github issue with all the
> details (commands, output etc.)
>
> Thanks,
>
> Christoph
>
>>
>> Andrey
>>
>> On Fri, 20 Jul 2018 22:41 Christoph Junghans,  wrote:
>>
>>> On Fri, Jul 20, 2018 at 3:11 PM, 'Andrey Brukhno' via votca
>>>  wrote:
>>> > The problem is, I remembered this option for the old build script and
>>> tried
>>> > to use it with cmake but still got the error "sqlite3 not found".
>>> Which version of VOTCA are you using now?
>>>
>>> >
>>> > Andrey
>>> >
>>> > On Fri, 20 Jul 2018 21:56 Christoph Junghans, 
>>> wrote:
>>> >>
>>> >> On Fri, Jul 20, 2018 at 11:08 AM, 'Andrey Brukhno' via votca
>>> >>  wrote:
>>> >> > Christoph,
>>> >> >
>>> >> > What is the flag for cmake not to search for SQLITE3?
>>> >> WITH_SQLITE3=OFF, btw you can just look up the options in ccmake.
>>> >>
>>> >> Christoph
>>> >> >
>>> >> > Thanks
>>> >> > Andrey
>>> >> >
>>> >> >
>>> >> > On Thu, Jul 19, 2018 at 8:18 PM, Christoph Junghans <
>>> jungh...@votca.org>
>>> >> > wrote:
>>> >> >>
>>> >> >> On Thu, Jul 19, 2018 at 10:57 AM, 'Andrey Brukhno' via votca
>>> >> >>  wrote:
>>> >> >> >
>>> >> >> >
>>> >> >> > On Thursday, July 19, 2018 at 4:48:14 PM UTC+1, Christoph
>>> Junghans
>>> >> >> > wrote:
>>> >> >> >>
>>> >> >> >> >>
>>> >> >> >> >> > We recently fixed an issue in the Eigen3 detection:
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> > https://github.com/votca/votca
>>> /commit/8fdcedae9b46e1739fa2ef8589cd5a8f6881d420
>>> >> >> >> >> > which includes:
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> > https://github.com/votca/tools
>>> /commit/3ee8b88e6022772b843f21a04f66a5bd8bfddd09
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> > https://github.com/votca/csg/c
>>> ommit/c3f9b3e2841c4b5c0eac20e4d843f6b108750ecf
>>> >> >> >> >> > Did you use that version?
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > No, I have not tried any newer version yet. My aim was to get
>>> the
>>> >> >> >> > latest
>>> >> >> >> > release installed, which spack did succeed to do (v1.4.1).
>>> >> >> >> But then I don't understand your original error because
>>> votca-csg
>>> >> >> >> 1.4.1 doesn't depend on Eigen3.
>>> >> >> >
>>> >> >> >
>>> >> >> > I guess I meant (implicitly) that I tried to follow the
>>> instructions
>>> >> >> > for
>>> >> >> > installation using cmake found on one of the VOTCA's webpages,
>>> and
>>> >> >> > that's
>>> >> >> > when I encountered the error message about eigen3 (not sure now
>>> what

Re: [votca] Missing, not found Eigen3 during VOTCA installation

['Andrey Brukhno' via votca]

Well, I tried to follow your instructions in this thread for "stable"
branch.

Andrey

On Fri, 20 Jul 2018 22:41 Christoph Junghans,  wrote:

> On Fri, Jul 20, 2018 at 3:11 PM, 'Andrey Brukhno' via votca
>  wrote:
> > The problem is, I remembered this option for the old build script and
> tried
> > to use it with cmake but still got the error "sqlite3 not found".
> Which version of VOTCA are you using now?
>
> >
> > Andrey
> >
> > On Fri, 20 Jul 2018 21:56 Christoph Junghans, 
> wrote:
> >>
> >> On Fri, Jul 20, 2018 at 11:08 AM, 'Andrey Brukhno' via votca
> >>  wrote:
> >> > Christoph,
> >> >
> >> > What is the flag for cmake not to search for SQLITE3?
> >> WITH_SQLITE3=OFF, btw you can just look up the options in ccmake.
> >>
> >> Christoph
> >> >
> >> > Thanks
> >> > Andrey
> >> >
> >> >
> >> > On Thu, Jul 19, 2018 at 8:18 PM, Christoph Junghans <
> jungh...@votca.org>
> >> > wrote:
> >> >>
> >> >> On Thu, Jul 19, 2018 at 10:57 AM, 'Andrey Brukhno' via votca
> >> >>  wrote:
> >> >> >
> >> >> >
> >> >> > On Thursday, July 19, 2018 at 4:48:14 PM UTC+1, Christoph Junghans
> >> >> > wrote:
> >> >> >>
> >> >> >> >>
> >> >> >> >> > We recently fixed an issue in the Eigen3 detection:
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> https://github.com/votca/votca/commit/8fdcedae9b46e1739fa2ef8589cd5a8f6881d420
> >> >> >> >> > which includes:
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> https://github.com/votca/tools/commit/3ee8b88e6022772b843f21a04f66a5bd8bfddd09
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> https://github.com/votca/csg/commit/c3f9b3e2841c4b5c0eac20e4d843f6b108750ecf
> >> >> >> >> > Did you use that version?
> >> >> >> >
> >> >> >> >
> >> >> >> > No, I have not tried any newer version yet. My aim was to get
> the
> >> >> >> > latest
> >> >> >> > release installed, which spack did succeed to do (v1.4.1).
> >> >> >> But then I don't understand your original error because votca-csg
> >> >> >> 1.4.1 doesn't depend on Eigen3.
> >> >> >
> >> >> >
> >> >> > I guess I meant (implicitly) that I tried to follow the
> instructions
> >> >> > for
> >> >> > installation using cmake found on one of the VOTCA's webpages, and
> >> >> > that's
> >> >> > when I encountered the error message about eigen3 (not sure now
> what
> >> >> > version
> >> >> > it was, but I think 1.5.1). But then I went the spack way and was
> >> >> > satisfied.
> >> >> > Since then I have not tried cmake for any other version. But I may
> >> >> > try
> >> >> > on my
> >> >> > home PC soon.
> >> >> I see, it is a bit confusing in the README of the new buildsystem,
> >> >> hopefully that makes it more clear:
> >> >>
> >> >>
> >> >>
> https://github.com/votca/votca/commit/40cbeb2daf4b4647292cf423e9755125cb7c3380
> >> >>
> >> >> Christoph
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> >
> >> >> >> > BTW, when I tried to install with apt-get nothing happened: no
> >> >> >> > votca
> >> >> >> > package
> >> >> >> > found. Perhaps it would only work for 2016(+) Ubuntu?
> >> >> >> Yes, only 2016.4 and later:
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> https://packages.ubuntu.com/search?k

Re: [votca] Hessian NOT a positive definite!

['Andrey Brukhno' via votca]

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
> 
> ...
> lj
> 
> 
>  LJ C6 Value 
>  LJ C12 Value 
> 
> 
> ...
> 
>
> I hope this helps.
>
> Best,
> Sikandar
>
> On Thu, Jul 19, 2018 at 6:13 PM Christoph Junghans  > wrote:
>
>>
>>
>> On Thu, Jul 19, 2018 at 18:15 'Andrey Brukhno' via votca <
>> vo...@googlegroups.com > 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 votca+un...@googlegroups.com .
>>> To post to this group, send email to vo...@googlegroups.com 
>>> .
>>> 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 votca+un...@googlegroups.com .
>> To post to this group, send email to vo...@googlegroups.com 
>> .
>> 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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

[votca] Hessian NOT a positive definite!

['Andrey Brukhno' via votca]

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.

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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

Re: [votca] Re: csg_reupdate error: property not found: re.function

['Andrey Brukhno' via votca]

On Thursday, July 19, 2018 at 7:57:57 PM UTC+1, Christoph Junghans wrote:
>
> On Thu, Jul 19, 2018 at 10:44 AM, 'Andrey Brukhno' via votca 
> > wrote: 
> > I get: 
> > 
> > ...  ... 
> > Total number of parameters to optimize: 333 
> > an error occurred: 
> > property not found: scale 
> See here: 
> https://github.com/votca/csg-tutorials/blob/master/spce/re/settings.xml#L69 
>
> Christoph 
>
>
Actually, I am a bit confused not seeing re.traj tag for atomistic 
trajectory. I thought RE iteration requires recalculating CG averages in 
over atomistic ensemble (trajectory) for every new set of CG potentials? 

Also, what about the corresponding re.topology tag - specifying what? 

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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

Re: [votca] Missing, not found Eigen3 during VOTCA installation

['Andrey Brukhno' via votca]

Ok, I will give it a try on my home PC.

Andrey

On Thursday, July 19, 2018 at 8:19:03 PM UTC+1, Christoph Junghans wrote:
>
> On Thu, Jul 19, 2018 at 10:57 AM, 'Andrey Brukhno' via votca 
> > wrote: 
> > 
> > 
> > On Thursday, July 19, 2018 at 4:48:14 PM UTC+1, Christoph Junghans 
> wrote: 
> >> 
> >> >> 
> >> >> > We recently fixed an issue in the Eigen3 detection: 
> >> >> > 
> >> >> > 
> >> >> > 
> https://github.com/votca/votca/commit/8fdcedae9b46e1739fa2ef8589cd5a8f6881d420
>  
> >> >> > which includes: 
> >> >> > 
> >> >> > 
> >> >> > 
> https://github.com/votca/tools/commit/3ee8b88e6022772b843f21a04f66a5bd8bfddd09
>  
> >> >> > 
> >> >> > 
> >> >> > 
> https://github.com/votca/csg/commit/c3f9b3e2841c4b5c0eac20e4d843f6b108750ecf 
> >> >> > Did you use that version? 
> >> > 
> >> > 
> >> > No, I have not tried any newer version yet. My aim was to get the 
> latest 
> >> > release installed, which spack did succeed to do (v1.4.1). 
> >> But then I don't understand your original error because votca-csg 
> >> 1.4.1 doesn't depend on Eigen3. 
> > 
> > 
> > I guess I meant (implicitly) that I tried to follow the instructions for 
> > installation using cmake found on one of the VOTCA's webpages, and 
> that's 
> > when I encountered the error message about eigen3 (not sure now what 
> version 
> > it was, but I think 1.5.1). But then I went the spack way and was 
> satisfied. 
> > Since then I have not tried cmake for any other version. But I may try 
> on my 
> > home PC soon. 
> I see, it is a bit confusing in the README of the new buildsystem, 
> hopefully that makes it more clear: 
>
> https://github.com/votca/votca/commit/40cbeb2daf4b4647292cf423e9755125cb7c3380
>  
>
> Christoph 
> > 
> >> 
> >> 
> >> > 
> >> > BTW, when I tried to install with apt-get nothing happened: no votca 
> >> > package 
> >> > found. Perhaps it would only work for 2016(+) Ubuntu? 
> >> Yes, only 2016.4 and later: 
> >> 
> >> 
> https://packages.ubuntu.com/search?keywords=votca-csg=names=all=all
>  
> >> and v1.4.1 only in Ubuntu 18.04! 
> >> 
> >> > 
> >> >> 
> >> >> > 
> >> >> >> 
> >> >> >> Not sure what went wrong, but I had to use alternative way of 
> >> >> >> installation 
> >> >> >> via spack, and it worked eventually, although it lloked like 
> spack 
> >> >> >> installed 
> >> >> >> ALL the dependencies along with VOTCA in a separate directory, 
> which 
> >> >> >> is 
> >> >> >> of 
> >> >> >> course an overkill. 
> >> >> > That is Spack's design, so don't complain to me! And yes we need 
> to 
> >> >> > update the dependencies of the VOTCA package in Spack. 
> >> >> https://github.com/spack/spack/pull/8757 
> >> > 
> >> > 
> >> > I see... Otherwise I also noticed that spack installs csg and tools 
> >> > separately in two directories beside each other. But then 
> VOTCARC.bash 
> >> > etc 
> >> > occur in the tools/bin and VOTCASHARE points at votca_tools/share 
> >> > instead of 
> >> > votca_csg/share, so the scripts/inverse are not found. I had to reset 
> >> > VOTCASHARE correctly in my .bashrc. 
> >> Good point I will have to think, how to fix that. I think the VOTCARC 
> >> file should get installed to start with as csg_inverse will 
> >> auto-detect the location (using csg_call in your PATH) if VOTCASHARE 
> >> isn't set. 
> >> 
> >> Christoph 
> >> 
> >> > 
> >> > I mentioned this for other users to be aware. 
> >> > 
> >> > Andrey 
> >> >> 
> >> >> 
> >> >> >> 
> >> >> >> I suppose this post is just to notify the current developers that 
> >> >> >> there 
> >> >> >> might be some issue with finding an exiasting Eigen3 dir. 
> >> >> > Thanks for letting us know, can you try if above versions fix the 
> >> >> > issue 
> >> >> > for you? 
> >> >> > 
>

Re: [votca] Re: csg_reupdate error: property not found: re.function

['Andrey Brukhno' via votca]

Thanks Christoph! 
That was helpful - I restarted iteration now.

On Thursday, July 19, 2018 at 7:57:57 PM UTC+1, Christoph Junghans wrote:
>
> On Thu, Jul 19, 2018 at 10:44 AM, 'Andrey Brukhno' via votca 
> > wrote: 
> > Hello again, 
> > 
> > By now, that the simulation for one iteration has finished 
> (successfully), I 
> > got a similar error during the analysis: 
> > 
> > # ERROR: 
> > # 
> > # critical: 'csg_reupdate --nt 8 --top topol.tpr --trj traj.xtc 
> --options 
> > settings.xml --begin 0 --first-frame 0' failed 
> > # 
> > # For details see the logfile 
> > 
> /home/andrey/Work/Models/DOPC-long-wtip4p-new/ire-Rc1.65nm-freeN-dihs_CG-fits1-151c/inverse.log
>  
>
> > 
> > Interestingly the error is not mirrored in inverse.log (which reports no 
> > error at all), but when I try to run: 
> > 
> > $ csg_reupdate --nt 8 --top topol.tpr --trj traj.xtc --options 
> settings.xml 
> > --begin 0 --first-frame 0 
> > 
> > I get: 
> > 
> > ...  ... 
> > Total number of parameters to optimize: 333 
> > an error occurred: 
> > property not found: scale 
> See here: 
> https://github.com/votca/csg-tutorials/blob/master/spce/re/settings.xml#L69 
>
> Christoph 
>
> > 
> > I am lost here, because my settings.xml file works with ibi and imc and 
> here 
> > is the output of `grep scale` for it: 
> > 
> >   scale smooth 
> > 0.10 
> >   scale smooth 
> > 0.10 
> >   scale smooth 
> > 0.10 
> >   scale smooth 
> > 0.10 
> >   scale smooth 
> > 0.10 
> >   scale smooth 
> > 0.10 
> >   scale smooth 
> > 0.10 
> >   scale smooth 
> > 0.10 
> >   scale smooth 
> > 0.10 
> >   scale smooth 
> > 0.10 
> > 
> > Did the location of scale tag change? Or is it some other scale tag that 
> is 
> > missing? 
> > 
> > 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 votca+un...@googlegroups.com . 
> > To post to this group, send email to vo...@googlegroups.com 
> . 
> > 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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

Re: [votca] Missing, not found Eigen3 during VOTCA installation

['Andrey Brukhno' via votca]

On Thursday, July 19, 2018 at 4:48:14 PM UTC+1, Christoph Junghans wrote:
>
> >> 
> >> > We recently fixed an issue in the Eigen3 detection: 
> >> > 
> >> > 
> https://github.com/votca/votca/commit/8fdcedae9b46e1739fa2ef8589cd5a8f6881d420
>  
> >> > which includes: 
> >> > 
> >> > 
> https://github.com/votca/tools/commit/3ee8b88e6022772b843f21a04f66a5bd8bfddd09
>  
> >> > 
> >> > 
> https://github.com/votca/csg/commit/c3f9b3e2841c4b5c0eac20e4d843f6b108750ecf 
> >> > Did you use that version? 
> > 
> > 
> > No, I have not tried any newer version yet. My aim was to get the latest 
> > release installed, which spack did succeed to do (v1.4.1). 
> But then I don't understand your original error because votca-csg 
> 1.4.1 doesn't depend on Eigen3. 
>

I guess I meant (implicitly) that I tried to follow the instructions for 
installation using cmake found on one of the VOTCA's webpages, and that's 
when I encountered the error message about eigen3 (not sure now what 
version it was, but I think 1.5.1). But then I went the spack way and was 
satisfied. Since then I have not tried cmake for any other version. But I 
may try on my home PC soon.
 

>
> > 
> > BTW, when I tried to install with apt-get nothing happened: no votca 
> package 
> > found. Perhaps it would only work for 2016(+) Ubuntu? 
> Yes, only 2016.4 and later: 
>
> https://packages.ubuntu.com/search?keywords=votca-csg=names=all=all
>  
> and v1.4.1 only in Ubuntu 18.04! 
>
> > 
> >> 
> >> > 
> >> >> 
> >> >> Not sure what went wrong, but I had to use alternative way of 
> >> >> installation 
> >> >> via spack, and it worked eventually, although it lloked like spack 
> >> >> installed 
> >> >> ALL the dependencies along with VOTCA in a separate directory, which 
> is 
> >> >> of 
> >> >> course an overkill. 
> >> > That is Spack's design, so don't complain to me! And yes we need to 
> >> > update the dependencies of the VOTCA package in Spack. 
> >> https://github.com/spack/spack/pull/8757 
> > 
> > 
> > I see... Otherwise I also noticed that spack installs csg and tools 
> > separately in two directories beside each other. But then VOTCARC.bash 
> etc 
> > occur in the tools/bin and VOTCASHARE points at votca_tools/share 
> instead of 
> > votca_csg/share, so the scripts/inverse are not found. I had to reset 
> > VOTCASHARE correctly in my .bashrc. 
> Good point I will have to think, how to fix that. I think the VOTCARC 
> file should get installed to start with as csg_inverse will 
> auto-detect the location (using csg_call in your PATH) if VOTCASHARE 
> isn't set. 
>
> Christoph 
>
> > 
> > I mentioned this for other users to be aware. 
> > 
> > Andrey 
> >> 
> >> 
> >> >> 
> >> >> I suppose this post is just to notify the current developers that 
> there 
> >> >> might be some issue with finding an exiasting Eigen3 dir. 
> >> > Thanks for letting us know, can you try if above versions fix the 
> issue 
> >> > for you? 
> >> > 
> >> > 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 votca+un...@googlegroups.com. 
> >> >> To post to this group, send email to vo...@googlegroups.com. 
> >> >> 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 
> >> 
> >> 
> >> 
> >> -- 
> >> 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 votca+un...@googlegroups.com . 
> > To post to this group, send email to vo...@googlegroups.com 
> . 
> > 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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

[votca] Re: csg_reupdate error: property not found: re.function

['Andrey Brukhno' via votca]

Hello again,

By now, that the simulation for one iteration has finished (successfully), 
I got a similar error during the analysis:

# ERROR:

#
# critical: 'csg_reupdate --nt 8 --top topol.tpr --trj traj.xtc --options 
settings.xml --begin 0 --first-frame 0' failed 
#
# For details see the logfile 
/home/andrey/Work/Models/DOPC-long-wtip4p-new/ire-Rc1.65nm-freeN-dihs_CG-fits1-151c/inverse.log
  
 

Interestingly the error is not mirrored in inverse.log (which reports no 
error at all), but when I try to run:

$ csg_reupdate --nt 8 --top topol.tpr --trj traj.xtc --options settings.xml 
--begin 0 --first-frame 0

I get:

...  ...
Total number of parameters to optimize: 333
an error occurred:
property not found: scale

I am lost here, because my settings.xml file works with ibi and imc and 
here is the output of `grep scale` for it:

  scale smooth
0.10
  scale smooth
0.10
  scale smooth
0.10
  scale smooth
0.10
  scale smooth
0.10
  scale smooth
0.10
  scale smooth
0.10
  scale smooth
0.10
  scale smooth
0.10
  scale smooth
0.10

Did the location of scale tag change? Or is it some other scale tag that is 
missing?

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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

Re: [votca] Missing, not found Eigen3 during VOTCA installation

['Andrey Brukhno' via votca]

On Thursday, July 19, 2018 at 3:27:52 PM UTC+1, Christoph Junghans wrote:
>
> On Wed, Jul 18, 2018 at 12:20 PM, Christoph Junghans  > wrote: 
> > On Wed, Jul 18, 2018 at 12:04 PM, 'Andrey Brukhno' via votca 
> > > wrote: 
> >> Hello, 
> >> 
> >> The last time I was installing the CSG package in my Ubuntu (up-to-date 
> 2014 
> >> LTS) I got this error from cmake: eigen3 not found, with a suggestion 
> to 
> >> provide the path to it. I then downloaded the library from their 
> website, 
> >> installed it and added its include directory to both my $PATH and to 
> the 
> >> environment under the suggested name EIGEN3_INCLUDE_DIR. But cmake 
> still 
> >> complained and stopped with the same error, even when I fed it the 
> flag: 
> >> -DEIGEN3_INCLUDE_DIR=. 
> > Just a reminder that 2014 was already 4 years ago ;-) 
>

Thanks, up to now it did not hurt to stay with that version, but eventually 
yes an upgrade is pending. :)
 

> > We recently fixed an issue in the Eigen3 detection: 
> > 
> https://github.com/votca/votca/commit/8fdcedae9b46e1739fa2ef8589cd5a8f6881d420
>  
> > which includes: 
> > 
> https://github.com/votca/tools/commit/3ee8b88e6022772b843f21a04f66a5bd8bfddd09
>  
> > 
> https://github.com/votca/csg/commit/c3f9b3e2841c4b5c0eac20e4d843f6b108750ecf 
> > Did you use that version? 
>

No, I have not tried any newer version yet. My aim was to get the latest 
release installed, which spack did succeed to do (v1.4.1).

BTW, when I tried to install with apt-get nothing happened: no votca 
package found. Perhaps it would only work for 2016(+) Ubuntu?
 

> > 
> >> 
> >> Not sure what went wrong, but I had to use alternative way of 
> installation 
> >> via spack, and it worked eventually, although it lloked like spack 
> installed 
> >> ALL the dependencies along with VOTCA in a separate directory, which is 
> of 
> >> course an overkill. 
> > That is Spack's design, so don't complain to me! And yes we need to 
> > update the dependencies of the VOTCA package in Spack. 
> https://github.com/spack/spack/pull/8757 
>

I see... Otherwise I also noticed that spack installs csg and tools 
separately in two directories beside each other. But then VOTCARC.bash etc 
occur in the tools/bin and VOTCASHARE points at votca_tools/share instead 
of votca_csg/share, so the scripts/inverse are not found. I had to 
reset VOTCASHARE correctly in my .bashrc. 

I mentioned this for other users to be aware.
 
Andrey

>
> >> 
> >> I suppose this post is just to notify the current developers that there 
> >> might be some issue with finding an exiasting Eigen3 dir. 
> > Thanks for letting us know, can you try if above versions fix the issue 
> for you? 
> > 
> > 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 votca+un...@googlegroups.com . 
> >> To post to this group, send email to vo...@googlegroups.com 
> . 
> >> 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 
>
>
>
> -- 
> 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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

Re: [votca] csg_reupdate error: property not found: re.function

['Andrey Brukhno' via votca]

Hi Christoph,

On Thursday, July 19, 2018 at 4:01:48 PM UTC+1, Christoph Junghans wrote:
>
> On Thu, Jul 19, 2018 at 8:56 AM, 'Andrey Brukhno' via votca 
> > wrote: 
> > Hello, 
> > 
> > Anyone encountered this error? 
> > 
> > $ csg_reupdate --gentable true --param-in-ext param.new --options 
> > ./settings.xml -v 
> > an error occurred: 
> > property not found: re.function 
> > 
> > while the settings.xml file does contain the correctly formatted 
> subsection 
> > for each potential, like below 
> > 
> >
> >   cbspl 
> >
> > 
> > I would appreciate any clues. 
> Here is an working example: 
>
> https://github.com/votca/csg/blob/master/src/tools/references/spce/settings_re.xml
>  
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fvotca%2Fcsg%2Fblob%2Fmaster%2Fsrc%2Ftools%2Freferences%2Fspce%2Fsettings_re.xml=D=1=AFQjCNHOcrHK4oOQ4FSse4xaF9iEoZ2m2g>
>  
> Maybe you put the block in the wrong location. 
>

This is from where I actually copy-pasted the re tag into my settings.xml 
file.
However, indeed, upon checking it again now it appeared that the re tag in 
the spce/re example is outside the inverse tag, unlike the tags for imc, 
for example. It is a bit confusing but alright I relocated it by now - and 
it works!

Thanks for the hint!

Andrey
 

>
> Christoph 
> > 
> > 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 votca+un...@googlegroups.com . 
> > To post to this group, send email to vo...@googlegroups.com 
> . 
> > 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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

[votca] csg_reupdate error: property not found: re.function

['Andrey Brukhno' via votca]

Hello,

Anyone encountered this error?

$ csg_reupdate --gentable true --param-in-ext param.new --options 
./settings.xml -v
an error occurred:
property not found: re.function

while the settings.xml file does contain the correctly formatted subsection 
for each potential, like below

  
  cbspl
  

I would appreciate any clues.

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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

Re: [votca] Re: Initial parameters for RE iteration with 10 potentials

['Andrey Brukhno' via votca]

Hi Sikandar,

Thanks for confirming my conclusion about the CG-CG.param.init file.

Would you be able to comment on my question regarding the Sci-Py class 
BSplines?

Best regards
Andrey

On Thursday, July 19, 2018 at 3:51:53 AM UTC+1, sikandar wrote:
>
> Hi Andrey,
>
> The initial parameter file *.param.init for the B-spline potential 
> function contains break-points in the first column and knot values in the 
> second column. 
>
> As you observed in csg-tutorial/spce/re/ example, the initial values for 
> the knot values can be set to the PMF obtained by inverting the target 
> RDFs, i.e., c_i = -kTlog(g(r_i)). I have found this approach of 
> initializing knot values work well in my RE coarse-graining experiments.
>
> Best,
> Sikandar
>
> On Wed, Jul 18, 2018 at 4:42 PM 'Andrey Brukhno' via votca <
> vo...@googlegroups.com > wrote:
>
>> Well, to reduce the burden on the developers' answering (probably obvious 
>> for them) questions, here is what I discovered by simply plotting the 
>> CG-CG.param.init file from the tutorial in csg-tutorials/spce/re/
>>
>> The CG-CG.param.init file appears to contain the -RT\ln(g_{target}(r)) 
>> data sampled at the spline knots, i.e. the first column is for the knot 
>> values (r) and the second column is the corresponding PMF in kJ/mol - see 
>> the attached plot. I am not sure what is the origin for the slight 
>> discrepancies that are seen in the graph (resampling artefacts?), but it 
>> seems that the mystery about this file has been cleared up.
>>
>> Andrey
>>
>> On Wednesday, July 18, 2018 at 10:23:27 PM UTC+1, Andrey Brukhno wrote:
>>>
>>> Wow, nobody can answer this straightaway? - I wonder: does this mean 
>>> that no non-associate of the VOTCA team ever used RE method for their 
>>> actual problem (i.e. not a tutorial case)?
>>>
>>> Anyway, may I ask those on the team now: in what relation VOTCA's 
>>> B-spline definition is with the corresponding Sci-Py class 
>>> (scipy.interpolate.BSpline)?
>>>
>>>
>>> https://docs.scipy.org/doc/scipy/reference/generated/scipy.interpolate.BSpline.html
>>>
>>> I also have another question: what is the actual format of the 
>>> .param.init file? - it is far from being clear in the manual, as the file 
>>> itself is never described.
>>>
>>> Thanks again.
>>>
>>> Andrey
>>>
>>> On Wednesday, July 18, 2018 at 6:51:44 PM UTC+1, Andrey Brukhno wrote:
>>>>
>>>> Hello,
>>>>
>>>> In an attempt to compare some data obtained with IBI to RE, I am trying 
>>>> to start a relative entropy iteration for the same system. However, I do 
>>>> not know how to generate the initial parameters (aka CG-CG.param.init 
>>>> file) 
>>>> for my system (which would comprise 10 different interaction types).
>>>>
>>>> Initially I thought VOTCA would be able to generate the necessary 
>>>> *.param.init files based on my initial potentials provided as *.pot.in 
>>>> (the IBI results) and/or distributions (*.dist.tgt). But it seems not to 
>>>> be 
>>>> the case, as it complaints in the inverse.log about missing *.param.init 
>>>> files.
>>>>
>>>> Can anyone suggest a workaround? - I googled and searched here but did 
>>>> not find anything regrading a practical way of creating those files (nor 
>>>> in 
>>>> the manual).
>>>>
>>>> Please note: my question is very practical - I know how fit numerical 
>>>> data with regular cubic splines, say in Grace, but VOTCA is using 
>>>> B-splines 
>>>> which are more general (which is good!) but also more involved, so I guess 
>>>> the coefficients of cubic splines cannot be used as initial "guess" for 
>>>> the 
>>>> RE iteration. 
>>>>
>>>> I essentially need to know what software could do that - ?
>>>>
>>>> Thanks in advance!
>>>>
>>>> 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 votca+un...@googlegroups.com .
>> To post to this group, send email to vo...@googlegroups.com 
>> .
>> 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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

[votca] Re: Initial parameters for RE iteration with 10 potentials

['Andrey Brukhno' via votca]

Well, to reduce the burden on the developers' answering (probably obvious 
for them) questions, here is what I discovered by simply plotting the 
CG-CG.param.init file from the tutorial in csg-tutorials/spce/re/

The CG-CG.param.init file appears to contain the -RT\ln(g_{target}(r)) data 
sampled at the spline knots, i.e. the first column is for the knot values 
(r) and the second column is the corresponding PMF in kJ/mol - see the 
attached plot. I am not sure what is the origin for the slight 
discrepancies that are seen in the graph (resampling artefacts?), but it 
seems that the mystery about this file has been cleared up.

Andrey

On Wednesday, July 18, 2018 at 10:23:27 PM UTC+1, Andrey Brukhno wrote:
>
> Wow, nobody can answer this straightaway? - I wonder: does this mean that 
> no non-associate of the VOTCA team ever used RE method for their actual 
> problem (i.e. not a tutorial case)?
>
> Anyway, may I ask those on the team now: in what relation VOTCA's B-spline 
> definition is with the corresponding Sci-Py class 
> (scipy.interpolate.BSpline)?
>
>
> https://docs.scipy.org/doc/scipy/reference/generated/scipy.interpolate.BSpline.html
>
> I also have another question: what is the actual format of the .param.init 
> file? - it is far from being clear in the manual, as the file itself is 
> never described.
>
> Thanks again.
>
> Andrey
>
> On Wednesday, July 18, 2018 at 6:51:44 PM UTC+1, Andrey Brukhno wrote:
>>
>> Hello,
>>
>> In an attempt to compare some data obtained with IBI to RE, I am trying 
>> to start a relative entropy iteration for the same system. However, I do 
>> not know how to generate the initial parameters (aka CG-CG.param.init file) 
>> for my system (which would comprise 10 different interaction types).
>>
>> Initially I thought VOTCA would be able to generate the necessary 
>> *.param.init files based on my initial potentials provided as *.pot.in 
>> (the IBI results) and/or distributions (*.dist.tgt). But it seems not to be 
>> the case, as it complaints in the inverse.log about missing *.param.init 
>> files.
>>
>> Can anyone suggest a workaround? - I googled and searched here but did 
>> not find anything regrading a practical way of creating those files (nor in 
>> the manual).
>>
>> Please note: my question is very practical - I know how fit numerical 
>> data with regular cubic splines, say in Grace, but VOTCA is using B-splines 
>> which are more general (which is good!) but also more involved, so I guess 
>> the coefficients of cubic splines cannot be used as initial "guess" for the 
>> RE iteration. 
>>
>> I essentially need to know what software could do that - ?
>>
>> Thanks in advance!
>>
>> 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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

[votca] Re: Initial parameters for RE iteration with 10 potentials

['Andrey Brukhno' via votca]

Wow, nobody can answer this straightaway? - I wonder: does this mean that 
no non-associate of the VOTCA team ever used RE method for their actual 
problem (i.e. not a tutorial case)?

Anyway, may I ask those on the team now: in what relation VOTCA's B-spline 
definition is with the corresponding Sci-Py class 
(scipy.interpolate.BSpline)?

https://docs.scipy.org/doc/scipy/reference/generated/scipy.interpolate.BSpline.html

I also have another question: what is the actual format of the .param.init 
file? - it is far from being clear in the manual, as the file itself is 
never described.

Thanks again.

Andrey

On Wednesday, July 18, 2018 at 6:51:44 PM UTC+1, Andrey Brukhno wrote:
>
> Hello,
>
> In an attempt to compare some data obtained with IBI to RE, I am trying to 
> start a relative entropy iteration for the same system. However, I do not 
> know how to generate the initial parameters (aka CG-CG.param.init file) for 
> my system (which would comprise 10 different interaction types).
>
> Initially I thought VOTCA would be able to generate the necessary 
> *.param.init files based on my initial potentials provided as *.pot.in 
> (the IBI results) and/or distributions (*.dist.tgt). But it seems not to be 
> the case, as it complaints in the inverse.log about missing *.param.init 
> files.
>
> Can anyone suggest a workaround? - I googled and searched here but did not 
> find anything regrading a practical way of creating those files (nor in the 
> manual).
>
> Please note: my question is very practical - I know how fit numerical data 
> with regular cubic splines, say in Grace, but VOTCA is using B-splines 
> which are more general (which is good!) but also more involved, so I guess 
> the coefficients of cubic splines cannot be used as initial "guess" for the 
> RE iteration. 
>
> I essentially need to know what software could do that - ?
>
> Thanks in advance!
>
> 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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

[votca] Missing, not found Eigen3 during VOTCA installation

['Andrey Brukhno' via votca]

Hello,

The last time I was installing the CSG package in my Ubuntu (up-to-date 
2014 LTS) I got this error from cmake: eigen3 not found, with a suggestion 
to provide the path to it. I then downloaded the library from their 
website, installed it and added its include directory to both my $PATH and 
to the environment under the suggested name EIGEN3_INCLUDE_DIR. But cmake 
still complained and stopped with the same error, even when I fed it the 
flag: -DEIGEN3_INCLUDE_DIR=.

Not sure what went wrong, but I had to use alternative way of installation 
via spack, and it worked eventually, although it lloked like spack 
installed ALL the dependencies along with VOTCA in a separate directory, 
which is of course an overkill.

I suppose this post is just to notify the current developers that there 
might be some issue with finding an exiasting Eigen3 dir.

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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

[votca] Initial parameters for RE iteration with 10 potentials

['Andrey Brukhno' via votca]

Hello,

In an attempt to compare some data obtained with IBI to RE, I am trying to 
start a relative entropy iteration for the same system. However, I do not 
know how to generate the initial parameters (aka CG-CG.param.init file) for 
my system (which would comprise 10 different interaction types).

Initially I thought VOTCA would be able to generate the necessary 
*.param.init files based on my initial potentials provided as *.pot.in (the 
IBI results) and/or distributions (*.dist.tgt). But it seems not to be the 
case, as it complaints in the inverse.log about missing *.param.init files.

Can anyone suggest a workaround? - I googled and searched here but did not 
find anything regrading a practical way of creating those files (nor in the 
manual).

Please note: my question is very practical - I know how fit numerical data 
with regular cubic splines, say in Grace, but VOTCA is using B-splines 
which are more general (which is good!) but also more involved, so I guess 
the coefficients of cubic splines cannot be used as initial "guess" for the 
RE iteration. 

I essentially need to know what software could do that - ?

Thanks in advance!

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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

[votca] Re: Error in `csg_stat': double free or corruption ...

['Andrey Brukhno' via votca]

Hi again,

Sorry, it was my bad input... hard to spot.
The error was caused by a missing bead name in one of the  
subsections in the mapping file
(so there were only three instead of four beads specified).

At least, we know now that this sort of omission in the mapping xml-file 
results in such a spurious error,
when trying to use ANY of the VOTCA tools (csg_map, csg_*topol, csg_stat 
etc).

Cheers / Andrey

On Friday, April 22, 2016 at 5:19:57 PM UTC+1, Andrey Brukhno wrote:
>
> Hi Christoph (or other VOTCA developers),
>
> I tired to ask my question on the forum :
> https://groups.google.com/forum/#!forum/votca
>
> But after pressing the "Post" button my message failed to appear amongst 
> the topics.
> I have to retype it now because the text has been lost.
>
> Well, I have been using VOTCA for a a few years now, 
> with both Gromcas and DL_POLY. Have it installed both locally 
> and on a couple of Beowulf clusters. Everything worked fine until recently.
>
> I have reinstalled/updated VOTCA on my desktop following the instructions:
>
> http://www.votca.org/tutorials/coarse-graining
>
> (had to switch off the GMX option, not to reinstall Gromacs)
>
> Now, csg_stat gives me an error:
>
> csg_stat --top .dlpf --trj .dlph --options cg-int-map11.xml --cg 
> cg-map11.xml
> begin to calculate distribution functions
> # of bonded interactions: 6
> # of non-bonded interactions: 5
> I have 10 beads in 2 molecules
> *** Error in `csg_stat': double free or corruption (out): 
> 0x7ffc6f9555f0 ***
> Aborted (core dumped)
>
> The problem is I get the same error with the older installations too.
>
> Would appreciate any clues. Thanks!
>
> Andrey
>
> ---
> Dr Andrey V Brukhno,  >
> Computational Scientist, CCP5 project developer, 
> Computational Chemistry, SCD/STFC, Daresbury
> http://people.scd.rl.ac.uk/Computational%20Chemistry/Brukhno/
> ---
> Cheshire Cat is my friend as I live in Wonderland.
>
>

-- 
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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

[votca] Error in `csg_stat': double free or corruption ...

['Andrey Brukhno' via votca]

Hi Christoph (or other VOTCA developers),

I tired to ask my question on the forum :
https://groups.google.com/forum/#!forum/votca

But after pressing the "Post" button my message failed to appear amongst
the topics.
I have to retype it now because the text has been lost.

Well, I have been using VOTCA for a a few years now,
with both Gromcas and DL_POLY. Have it installed both locally
and on a couple of Beowulf clusters. Everything worked fine until recently.

I have reinstalled/updated VOTCA on my desktop following the instructions:

http://www.votca.org/tutorials/coarse-graining

(had to switch off the GMX option, not to reinstall Gromacs)

Now, csg_stat gives me an error:

csg_stat --top .dlpf --trj .dlph --options cg-int-map11.xml --cg
cg-map11.xml
begin to calculate distribution functions
# of bonded interactions: 6
# of non-bonded interactions: 5
I have 10 beads in 2 molecules
*** Error in `csg_stat': double free or corruption (out):
0x7ffc6f9555f0 ***
Aborted (core dumped)

The problem is I get the same error with the older installations too.

Would appreciate any clues. Thanks!

Andrey

---
Dr Andrey V Brukhno, http://A.Brukhno_at_stfc.ac.uk>>
Computational Scientist, CCP5 project developer,
Computational Chemistry, SCD/STFC, Daresbury
http://people.scd.rl.ac.uk/Computational%20Chemistry/Brukhno/
---
Cheshire Cat is my friend as I live in Wonderland.

-- 
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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.

[votca] Error in `csg_stat': double free or corruption (out)

['Andrey Brukhno' via votca]

Dear VOTCA developers,

I have had VOTCA installed for a couple of years, both locally (on a 
desktop) and on a Beowulf cluster.
I am using it with both Gromacs and DL_POLY. Everything worked nicely until 
recently. 

Now when I am trying to use csg_stat like this:

csg_stat --top .dlpf --trj .dlph --options cg-int-map11.xml --cg 
cg-map11.xml

I am getting the following output with an error that have not occurred 
before:

begin to calculate distribution functions
# of bonded interactions: 6
# of non-bonded interactions: 5
I have 10 beads in 2 molecules
*** Error in `csg_stat': double free or corruption (out): 
0x7ffc6f9555f0 ***
Aborted (core dumped)

Note that I have tried to reinstall VOTCA locally by following the 
instructions here: 

http://www.votca.org/tutorials/coarse-graining

(Not to reinstall Gromacs, I had to switch it off with the option 
 -DWITH_GMX=OFF)

Would appreciate any clues. 

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 votca+unsubscr...@googlegroups.com.
To post to this group, send email to votca@googlegroups.com.
Visit this group at https://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.