[DFTB-Plus-User] dftb+.mpi as spawned process

Jacek Jakowski jjakowski at gmail.com
Mon Dec 29 22:02:58 CET 2014


Alex,

 ....I think,  you want to be careful about your  temporary IO files,
especially when your spawned dftb+ processes  reside in the IO directory.
This may be a problem when your  different  dftb+  instances read  and
write to/from the same files.  You can avoid it by  letting each  process
to run in its own "private" subdirectory.

jacek

On Mon, Dec 29, 2014 at 3:10 PM, Alex A. Schmidt <aas at ufsm.br> wrote:

> Dear Bálint,
>
> Thanks for your reply.
>
> 2014-12-29 13:09 GMT-02:00 Bálint Aradi <aradi at uni-bremen.de>:
>
>>
>> I've added that to the code in our MPI-branch.
>> >
>> >     if (mympi%master.and.mpi_comm_parent.eq.mpi_comm_null) then
>> >       stdout = output_unit
>> >     else
>> >       stdout = 1
>> >       open(stdout, file="/dev/null", action="write")
>> >     end if
>>
>> This solution, I do no like as a general solution, as for me it is not
>> trivial at all, that all IO to stdout should be suppressed when DFTB+ is
>> spawned by other process via mpi_comm_spawn(). One could eventually
>> think about a flag in the input file (or a command line argument for
>> DFTB+), which would do that.
>>
>
> I certainly agree with you regarding the above solution to suppress
> stdout.
> Its advantage is to be quick and easy to implement and would do the trick
> in my case...
>
> I think a command line argument like "-o outfile" is indeed a much better
> choice to manage stdout as options like this can be easily passed to spawn
> processes. It is also aesthetically similar to the regular i/o redirection
> "> outfile"
> option and you would not have to alter the current input standard of
> dftb+, even
> though I have a feeling that adding a flag to the input file would be much
> easier
> to implement.
>
> Best regards and a great 2015,
>
> Alex
>
> 2014-12-29 13:09 GMT-02:00 Bálint Aradi <aradi at uni-bremen.de>:
>
>> Dear Alex,
>>
>> thank you for your suggestions.
>>
>> > As far as I know, all that is necessary for dftb+.mpi to become "spawn
>> > ready" would be to
>> > add something like
>> >
>> >    integer :: mpi_comm_parent
>> >
>> >    call mpi_comm_get_parent(mpi_comm_parent,error0)
>> >
>> >    if (mpi_comm_parent.ne.mpi_comm_null) then
>> >        call mpi_comm_disconnect(mpi_comm_parent,error0)
>> >    endif
>> >
>> > right before "call mpi_finalize(error0)". Please, note that testing the
>> > value of mpi_comm_parent
>> > as above make the call to mpi_comm_disconnect safe in case dftb+.mpi is
>> > called from "mpirun".
>>
>> I've added that to the code in our MPI-branch.
>> >
>> >     if (mympi%master.and.mpi_comm_parent.eq.mpi_comm_null) then
>> >       stdout = output_unit
>> >     else
>> >       stdout = 1
>> >       open(stdout, file="/dev/null", action="write")
>> >     end if
>>
>> This solution, I do no like as a general solution, as for me it is not
>> trivial at all, that all IO to stdout should be suppressed when DFTB+ is
>> spawned by other process via mpi_comm_spawn(). One could eventually
>> think about a flag in the input file (or a command line argument for
>> DFTB+), which would do that.
>>
>>   Best regards and a happy new year,
>>
>>   Bálint
>>
>> --
>> Dr. Bálint Aradi
>> Bremen Center for Computational Materials Science, University of Bremen
>> http://www.bccms.uni-bremen.de/cms/people/b_aradi/
>>
>>
>>
>> _______________________________________________
>> DFTB-Plus-User mailing list
>> DFTB-Plus-User at mailman.zfn.uni-bremen.de
>> https://mailman.zfn.uni-bremen.de/cgi-bin/mailman/listinfo/dftb-plus-user
>>
>>
>
> _______________________________________________
> DFTB-Plus-User mailing list
> DFTB-Plus-User at mailman.zfn.uni-bremen.de
> https://mailman.zfn.uni-bremen.de/cgi-bin/mailman/listinfo/dftb-plus-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.zfn.uni-bremen.de/pipermail/dftb-plus-user/attachments/20141229/f763877f/attachment-0001.html>


More information about the DFTB-Plus-User mailing list