<div dir="ltr"><div>Dear Laurent, plugin_ext_forces is a routine that is meant for easy patching of third-party plugins that read their own input. As such it has to be kept empty in the QE trunk. In addition it allows users to implement their own "exotic" constraint in their local copy. For your add-on you can always construct it as a pathchable plugin reading its own input. For that you only need to encapsulate your routines in a lib and construct a patch that patches plugin_ext_forces and make.inc (to add the path to your lib). To turn on the use of your plugin you can look at the other *_plugin_*.f90 routines.</div><div><br></div><div>If you and the coordinators and maintainers of QE consider that your add-on might be of broad interest, then you can always follow the path of full integration with QE. In this case, I strongly recommend you to add your routine that modifies forces BEFORE the call to the empty routine plugin_ext_forces. Like this your add-on will be fully compatible with PLUMED plugin and other third-party plugins that patch plugin_ext_forces.</div><div><br></div><div>Cheers</div><div><br></div><div>Layla<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 28 mai 2021 à 07:06, laurent pizzagalli <<a href="mailto:laurent.pizzagalli@univ-poitiers.fr">laurent.pizzagalli@univ-poitiers.fr</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Paolo,<br>
<br>
thanks for your help. I didn't think of the external file, which is <br>
probably the most flexible option. The ATOMIC_FORCES card seems a well <br>
defined container, and I am not sure it would be a good idea to <br>
introduce keywords in that place. Therefore the best way IMO would be to <br>
define a keyword in the &SYSTEM namelist, allowing for the activation of <br>
an external force field. The required parameters would then be read from <br>
an external file.<br>
<br>
Best regards<br>
<br>
Laurent<br>
<br>
On 27/05/2021 22:04, Paolo Giannozzi wrote:<br>
> Dear Laurent<br>
><br>
> the proliferation of input variables in QE is an old and known <br>
> problem. I am not sure what the best solution should be, though. One <br>
> possibility I would consider is to read the needed variables from a <br>
> separate file.<br>
> If I remember correctly this is what the "Environ" library does.<br>
> Another one is to extend the existing ATOMIC_FORCES card, that <br>
> currently supports only a list of forces, to cover your case as well.<br>
><br>
> Paolo<br>
><br>
> On 27/05/2021 10:00, Laurent Pizzagalli wrote:<br>
>> Dear Dr. Giannozzi,<br>
>><br>
>><br>
>> I write to you concerning the implementation of an external force <br>
>> field in quantum espresso. The motivation is the investigation of the <br>
>> mechanical properties of nanoparticles, especially in the plastic <br>
>> regime, obtained by uniaxial compression. The implementation is not <br>
>> complicated, since you (the developers) had already planned this <br>
>> potentiality in the file 'plugin_ext_forces.f90'.<br>
>> Actually, i already made the implementation in cp.x, but in a quick <br>
>> way, in a local copy of the code. Since it is successful, I would <br>
>> like to do it properly, merging it with the development version using <br>
>> git. I got almost all the information I need in the developer manual. <br>
>> But I still have one question, concerning the general organization of <br>
>> the input. Right now, I implemented only one kind of force field, <br>
>> fully repulsive. It allows for compressing the nanoparticle between <br>
>> two planes. Six keywords are needed, one for the activation of the <br>
>> force field, four to define the position of the planes and the <br>
>> increment for their displacements at each timestep, and a last one to <br>
>> define the strength of the repulsion. My question is: what would be <br>
>> the best way to organize these keywords? Originally, I put all of <br>
>> these into the &IONS namelist. Another option would be in the &SYSTEM <br>
>> namelist. And finally, maybe it would be better to create a specific <br>
>> NAMELIST to include these keywords (something like &EXTFF)? I also <br>
>> plan to implement another force field (including an attractive <br>
>> interaction), which would require other keywords. So the creation of <br>
>> a specific NAMELIST seems the best option in my opinion. But I would <br>
>> like to have yours before proceeding.<br>
>><br>
>> Best regards<br>
>><br>
>> Laurent<br>
>><br>
><br>
<br>
-- <br>
,,, __,<br>
/'^'\ |__|<br>
( o o ) |<br>
--------------------------------------------------oOOO--(_)--OO|o------<br>
<<a href="mailto:Laurent.Pizzagalli@univ-poitiers.fr" target="_blank">Laurent.Pizzagalli@univ-poitiers.fr</a>><br>
<a href="http://laurent.pizzagalli.free.fr/" rel="noreferrer" target="_blank">http://laurent.pizzagalli.free.fr/</a> Tel +33 549 49 74 99<br>
------------------------------------------ Fax +33 549 49 66 92<br>
Institut P'<br>
Departement de Physique et de Mécanique des Matériaux<br>
CNRS UPR 3346<br>
Université de Poitiers<br>
SP2MI<br>
TSA 41123 .oooO<br>
86073 Poitiers Cedex 9, FRANCE ( ) Oooo.<br>
----------------------------------------------------\ (----( )-------<br>
\_) ) /<br>
(_/<br>
<br>
_______________________________________________<br>
developers mailing list<br>
<a href="mailto:developers@lists.quantum-espresso.org" target="_blank">developers@lists.quantum-espresso.org</a><br>
<a href="https://lists.quantum-espresso.org/mailman/listinfo/developers" rel="noreferrer" target="_blank">https://lists.quantum-espresso.org/mailman/listinfo/developers</a><br>
</blockquote></div>