[CP2K-user] [CP2K:11011] ASE CP2K interface

[Ole Schütt]

Hi Geng,

are you using MPI? Then this is probably where the buffering happens. 
Depending on which MPI implementation you are using there might be a way 
to tweak its stdin/out forwarding.

Out of curiosity, how many atoms does your system have? Maybe the 
Fortran side simple tries to read too many values?

-Ole


On 2018-12-04 21:27, Geng Sun wrote:
> Hello Ole,
> 
> Thank you very much for your reply:
> I changed the code as you suggested (below), but the problem is still
> present in the test.
> 
> Best
> 
> Geng
> 
>     def send(self, line):
>         """Send a line to the cp2k_shell"""
>         assert self._child.poll() is None  # child process still
> alive?
>         if self._debug:
>             #print('Sending: ' + line)
>             sys.stderr.write("Sending: {}\n".format(line))
>             sys.stderr.flush()
> 
>         if self.version < 2.1 and len(line) >= 80:
>             raise Exception('Buffer overflow, upgrade CP2K to r16779
> or later')
>         assert(len(line) < 800)  # new input buffer size
>         self.isready = False
>         self._child.stdin.write(line + '\n')
>         self._child.stdin.flush()
> 
> 在 2018年12月4日星期二 UTC-8上午11:05:43，Ole
> Schütt写道：
> 
>> Hi Geng,
>> 
>> this sounds indeed like a buffering issue. Could you once try to add
>> a
>> flush() on the python side.
>> 
>> Basically add the following line after cp2k.py:498.
>> 
>> self._child.stdin.write(line + '\n')
>> +       self._child.stdin.flush()
>> 
>> This is probably quite inefficient. So, if it works I'll add some
>> logic
>> to flush only when recv() follows a send().
>> 
>> -Ole
>> 
>> On 2018-12-04 18:08, Geng Sun wrote:
>>> Dear CP2K users,
>>> 
>>> In the past several weeks, I frequently faced a problem when I
>> use
>>> the CP2K -ASE interface.
>>> 
>>> The calculations frequently got stuck during the calculations.
>>> 
>>> 1) Firstly I switched on the debug=True option in the ASE-CP2K
>>> calculator and I found that the calculation always gets stuck at a
>> 
>>> line with *END after sending the positions to the subroutine
>>> cp2k_shell.popt  (I printed the information to the standard error,
>> so
>>> they are not buffered)
>>> 
>>> 2) Then, I modified the cp2k_shell.F to print a lot of "labels".
>> Then
>>> I found that the code may get stuck at the line of "READ
>>> (*,*,iostat=iostat) pos" like below. I can always get "begin to
>> read
>>> pos" in the standard error, but I can not reach "LABEL-1".
>>> 
>>> WRITE(0,*) "begin to read pos"
>>> CALL m_flush(0)
>>> READ (*,*,iostat=iostat) pos
>>> WRITE(0,*) "LABEL-1"
>>> CALL m_flush(0)
>>> 
>>> I attached the modified cp2k_shell.F and the standard out/error
>>> generated by the slurm batch system with this post. You can see
>> that
>>> the program get stuck at the second optimization step just after
>>> sending the positions.
>>> 
>>> I greatly appreciate your suggestions for fixing this confusing
>> bugs.
>>> 
>>> Thanks in advance.
>>> 
>>> Geng
>>> 
>>> --
>>> You received this message because you are subscribed to the Google
>> 
>>> Groups "cp2k" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>> send
>>> an email to cp2k+... at googlegroups.com.
>>> To post to this group, send email to cp... at googlegroups.com.
>>> Visit this group at https://groups.google.com/group/cp2k [1].
>>> For more options, visit https://groups.google.com/d/optout [2].
> 
>  --
> You received this message because you are subscribed to the Google
> Groups "cp2k" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to cp2k+uns... at googlegroups.com.
> To post to this group, send email to cp... at googlegroups.com.
> Visit this group at https://groups.google.com/group/cp2k.
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> Links:
> ------
> [1] https://groups.google.com/group/cp2k
> [2] https://groups.google.com/d/optout