Re: [SIESTA-L] constr.f problems

[Roberto Pasianot]

Hi Nick,

On 23/05/21 16:43, Nick Papior wrote:

Hi all,

Please do not complicate things... :)

Geometry.Constraints is quite sufficient for the things you mention here 
(constraining all forces on a set of atoms).


Secondly, @Roberto the constr is called by all nodes, so it need not be MPI 
aware.



 Thanks, good to know.
 In my case however I was applying specialized constraints that need to read 
stuff
 from an external file. I thought it safer doing that with the IONode and then 
broadcast.

 Best,
 Roberto



Bottom line, if you can use the Geometry.Constraints, please stick with it.
Do _NOT_ use constr unless you are dealing with specialized constraints.

Den fre. 21. maj 2021 kl. 22.04 skrev Oscar >:


Hi,

I think that the coordinates "xa" can only be used as an input. In this
constr.f routine you can only change the values of the forces and stresses
of the system, as they are the only outputs coming from this routine. I
guess that you are also including the section:

%block GeometryConstraints

routine constr

%endblock GeometryConstraints

In your input "*.fdf" file. To constrain for example the movement of the
"5" first atoms of the system I suggest to use this kind of code:

n=5

do i = 1, n

fa ( 1 , i ) = 0.d0

fa ( 2 , i ) = 0.d0

fa ( 3 , i ) = 0.d0

end do

I hope this helps

Óscar


El 20/5/21 a las 10:40, Pablo Álvarez Rodríguez escribió:

Dear SIESTA users.
I am currently struggling to make constraints to certain atom blocks in
SIESTA. For so, I use *constr.f* modified by nullifying the atomic forces
by including the code line :

*fa(1:3,1:i)=0*
*
*
where *i* is the number of atoms I want to constrain. Afterwards I
compile the new siesta file with the modified constr.f in order to use
it, but it seems it doesn't work properly, as atoms still suffer
movements even after constraining them with constr.f.
I don't really understand how *constr.f* works as I may forget something.
Do I need to include anything more in order to make a working constraint,
like for example, rewrite the coordinates with xa?

-- 


Yours Sincerely

*Pablo Álvarez Rodríguez.*
.



*AVISO LEGAL*. Este mensaje puede contener información reservada y
confidencial. Si usted no es el destinatario no está autorizado a copiar,
reproducir o distribuir este mensaje ni su contenido. Si ha recibido este
mensaje por error, le rogamos que lo notifique al remitente.
Le informamos de que sus datos personales, que puedan constar en este
mensaje, serán tratados en calidad de responsable de tratamiento por la
UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA (UNED) c/ Bravo Murillo, 38,
28015-MADRID-, con la finalidad de mantener el contacto con usted. La base
jurídica que legitima este tratamiento, será su consentimiento, el interés
legítimo o la necesidad para gestionar una relación contractual o similar.
En cualquier momento podrá ejercer sus derechos de acceso, rectificación,
supresión, oposición, limitación al tratamiento o portabilidad de los
datos, ante la UNED, Departamento de Política Jurídica de Seguridad de la
Información , o a través de la Sede electrónica
 de la Universidad.
Para más información visite nuestra Política de Privacidad
.

-- 
SIESTA is supported by the Spanish Research Agency (AEI) and by the

European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)



--
Kind regards Nick





-- 
SIESTA is supported by the Spanish Research Agency (AEI) and by the European 
H2020 MaX Centre of Excellence (http://www.max-centre.eu/)

Re: [SIESTA-L] constr.f problems

[Roberto Pasianot]

Hi Pablo,

That should work, but notice that if you wnat to run in parallel then constr.f 
must
be MPI-aware, ¿is it?. Let me doubt because in that case it would be called 
constr.F90

and contain stuff such as,
#ifdef MPI
bla, bla,
#endif

Cheers,

Roberto

On 20/05/21 05:40, Pablo Álvarez Rodríguez wrote:

Dear SIESTA users.
I am currently struggling to make constraints to certain atom blocks in 
SIESTA. For so, I use *constr.f* modified by nullifying the atomic forces by 
including the code line :


*fa(1:3,1:i)=0*
*
*
where *i* is the number of atoms I want to constrain. Afterwards I compile the 
new siesta file with the modified constr.f in order to use it, but it seems it 
doesn't work properly, as atoms still suffer movements even after constraining 
them with constr.f.

I don't really understand how *constr.f* works as I may forget something.
Do I need to include anything more in order to make a working constraint, like 
for example, rewrite the coordinates with xa?


--

Yours Sincerely

*Pablo Álvarez Rodríguez.*
.



-- 
SIESTA is supported by the Spanish Research Agency (AEI) and by the European 
H2020 MaX Centre of Excellence (http://www.max-centre.eu/)

Re: [SIESTA-L] Fe Basis set

[Roberto Pasianot]

Hi Alejandra,

--
Fe   4
 n=4   0   2   S.5777879 P
 5.9259701  5.7574625
 1.0  1.0
 n=4   1   2   S1.1090337 P
 .4664841  4.6741910   <-- missing integer part in 1st r_c, looks like a 
typo
 1.0001.000
 n=3   2   2   S.9751562 P
 5.3236035  3.4324072
 1.0  1.0
 n=4   3   2   S5.5821671 P
 8.9228022  9.000
 1.01.0
---

Happy new year,

Roberto P.



On 03/01/21 20:35, Alejandra Chavarría wrote:

Hello everyone,

I've been having trouble converging some calculations using Fe because I get 
an/*Inconsistency in polarization orbital error*. /One fellow researcher I'm 
working with shared with me a Fe basis set he'd used before, but now it isn't 
working either. I don't know if it's a bug but//I've tried everything for 
weeks and still I really have no idea as to why it isn't working, so I don't 
know if this is something usual but is there a possibility that someone that 
has a working Fe basis set that can share it with me to use it as a starting 
point for my calculations? Or maybe someone that can help me understand what's 
wrong with my basis set? I'll attach my .fdf file if needed.


Happy new year and thanks in advance!

--
Alejandra Chavarría Jiménez
Estudiante de Ingeniería Química
Universidad de Costa Rica





-- 
SIESTA is supported by the Spanish Research Agency (AEI) and by the European 
H2020 MaX Centre of Excellence (http://www.max-centre.eu/)

Re: [SIESTA-L] Silver ion

[Roberto Pasianot]

Hi,

I've never worked with charged systems but, as far as I understand, the
fact that the charge remains localizaed or not depends on Quantum
Mechanics (DFT, KS equations), it's not something you can choose.

Regards,

Roberto

On 05/27/2015 05:10 AM, Younas Khan wrote:

Yes. But the output file still shows that the outermost shell contains 11
electrons as in the case of neutral atoms. Moreover I am calculating the
adsorption of silver ion on silica; the line NetCharge line does not specify
which specie should hold the net charge..

RegardsÂ

On Wed, May 27, 2015 at 12:56 PM, Jingxian Yu jingxian...@adelaide.edu.au
mailto:jingxian...@adelaide.edu.au wrote:

HI Younas,

Have you tried the line NetCharge? Cheers!

Jin



On 27-May-15 5:17 PM, Younas Khan wrote:

Hi all I want to use Silver ion in my calculations i.e. a silver atom with
+1 charge. Does anybody know how I can do this?Â

Regards
Younas Khan

Re: [SIESTA-L] compiling plrho utility

[Roberto Pasianot]

Hi Nadia,

You must tell the linker (/usr/bin/ld) where to find
libpgplot.a .One quick solution is compiling plrho.f
using the -L/* option,

 gfortran plrho.f -lX11  -L/home/Nadia/PGPLOT_DIR  -lpgplot -o plrho

Get the idea ?

Regards,

Roberto

PS: there is nothing you can do about the Warnings (new compiler, too
old code), anyway I bet they are harmless.


On 04/29/2015 04:01 PM, Nadia Salami wrote:

I want to compile plrho utility. So, at first, according to the following link,
I have installed the pgplot library in ubuntu using gfortran compiler.

http://pendientedemigracion.ucm.es/info/Astrof/software/howto/howto-pgplot.html

1. Download the distribution file pgplot5.2.tar.gz
ftp://ftp.astro.caltech.edu/pub/pgplot/pgplot5.2.tar.gz
2. 
.
.
.

 After that, when I want to compile the plrho with

gfortran plrho.f -lX11 -lpgplot -o plrho

I have faced to the following error:



icolor.f:179.72:
    Included at plrho.f:223:

    Â
IF(J.GT.97.OR.J.LT.1)PAUSEÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
           Â

                                        
                              Â
1
Warning: Deleted feature: PAUSE statement at (1)
pltr3d.f:169.45:
    Included at plrho.f:227:

              pixmap(ix,iy) = icolor( b, nc, c
)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
                                        
   Â
1
Warning: Rank mismatch in argument 'color' at (1) (scalar and rank-1)
plrho.f:206.24:

     .              nt, colmin, colavg, colmax
)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
                        1
Warning: Rank mismatch in argument 'colmin' at (1) (rank-1 and scalar)
/usr/bin/ld: cannot find -lpgplot
collect2: error: ld returned 1 exit status



How can I solve the problem?
Best regards.
Nadia Salami

Re: [SIESTA-L] how to compile constr.f file for my system

[Roberto Pasianot]

Hi,

1) Look for constr.f into */Src/include
2) change/edit according to your needs, and copy it to */Src
3) recompile Siesta

Regards,

Roberto

On 04/27/2015 01:40 PM, Nadia Salami wrote:

Dear users

I want to relax part of my system using constr.f file.

At first step, I don’t know how to compile constr.f file for my system.

At next step, is the compiled constr.f file included in my work directory?

Could you help me please?

Thanks in advance,

Regards.

Nadia Salami

Re: [SIESTA-L] question related to total energy band structure energy

[Roberto Pasianot]

Hello,

Your formula from E_band misses two terms related to exch-corr :
+Exch-corr -(exch  corr potential). The latter stems from the
functional derivative of the former and is not specified in the
list.

Best

Roberto


On 03/31/2015 09:47 AM, BingHuang wrote:

Dear siesta users,

I've got one question related to total energy  band structure energy. Let me
take H2 molecule as an example to illustrate the problem in my mind.

a typical output energetics for H2 molecules is:

=
siesta: Final energy (eV):
siesta:  Band Struct. = -20.590981
siesta:   Kinetic =  26.985495
siesta:   Hartree =  28.063408
siesta:Ext. field =   0.00
siesta:   Exch.-corr. = -17.988802
siesta:  Ion-electron = -80.572181
siesta:   Ion-ion =  12.072663
siesta:   Ekinion =   0.00
siesta: Total = -31.439416
=

Neglecting E_kinion and E_ext.field, it's easy to understand that E_tot =
E_kinetic + E_Hartree + E_xc + E_ion-electron + E_ion-ion, but there is another
route to sum up the total energy by means of band structure energy (E_band),
i.e., E_tot' = E_band - E_Hartree + E_ion-ion. However, this equation seems not
to be true (E_tot' - E_tot = -5.14 eV) using the above data. Have I wrote the
formula wrong?

Best regards,
Bing

Re: [SIESTA-L] one question

[Roberto Pasianot]

Hi,

Just mpirun -np something  and do not set ParallelOverK. By default
Siesta does parallelization over orbitals, so that each node gets a
piece of the problem. Thus you might be able to fit the big cell case
by distributing the run over several computers.

Regards,

Roberto


On 11/27/2014 09:54 AM, Nadia Salami wrote:

I want to relax my system including 504 atoms by Siesta code. Since the
simulated supercell is enough big, so I have used Γ point in the calculation
and I don’t need to do parallel calculation over k points (Is it correct?).
But after the running in the serial mode, I have faced to the error:



 Initializing Density Matrix...


InitMesh: MESH =   360 x   324 x   180 =   20995200
InitMesh: Mesh cutoff (required, used) =Â Â  190.000Â Â  192.560 Ry

=
=Â Â  BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=Â Â  EXIT CODE: 139
=Â Â  CLEANING UP REMAINING PROCESSES
=Â Â  YOU CAN IGNORE THE BELOW CLEANUP MESSAGES
=
APPLICATION TERMINATED WITH THE EXIT STRING: Segmentation fault (signal11)




I think I don't have enough memory. Because, when I repeat the relaxation
calculation for a smaller supercell including 396 atoms, it works without any
problem. In this direction, I have some questions.

1.    --- How can I do the relaxation calculation for the bigger 
supercell?

2.     --- In my knowledge, it is efficient to set order N for the
solution method option for semiconductors with big supercells. Since mysystem
is shown metallic behavior in some cases, can I use order N calculation?

3.     Can I use swap memory for the bigger system?

Could you help me for solving my problem, please?

It will be highly appreciated any comment and help.

Thanks in advance.

Kind regards.

Nadia Salami

PHD student

Â

Re: [SIESTA-L] bader compling problem

[Roberto Pasianot]

Hi again,

I know nothing about the Siesta2cube tool, but the message is prety clear:
gfortran is being too strict and doesn't like that sentence.
Editing wraxsf1.f and just deleting the status specifier, won't do
any harm while allowing compilation.
Cheers,

Roberto

On 10/08/2014 04:53 PM, Ting Zheng wrote:

Hi all,
 I worked with Siesta-3.1 and I have got the *.TOCH file. Then I want to get
the *.cube file using Siesta2cube
(voznyy.elinity.com/blog/2008/01/bader-analysis-with-siesta/
http://voznyy.elinity.com/blog/2008/01/bader-analysis-with-siesta/). But when
I tried to compile it using /make /under the siesta2cube folder, it mentioned
me that:
/gfortran -O3 Â -c -o wraxsf1.o wraxsf1.f/
/wraxsf1.f:30.72:/
/
/
/Â  Â  Â  open (is1, file='tmpfil',form='formatted',status='scratch') Â  Â  Â Â 
/
/Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â
                    1/
/Error: The STATUS specified in OPEN statement at (1) cannot have the value
SCRATCH if a FILE specifier is present/
Could anyone else help with this problem?

Thanks
Ting

Re: [SIESTA-L] PAO.basis and Pao.BasisSizes

[Roberto Pasianot]

Hi, how are you doing ?.

I seem to recall that for semicore states you must use PAO.Basis block
exclusively.
See, the basis effectively being used is written in the output, so that you
could always paste the output from  a PAO.BasisSizes (dummy) run into a
PAO.Basis block and manage all basis stuff from there.

Regards,

Roberto

On 10/07/2014 03:39 PM, Ting Zheng wrote:

Dear users,

I am trying to run the geometry optimism work of rutile surface. The program can
be convergent when I set all the atoms in Pao.BasisSizes as DZ. But the question
is that I only want to set the semicore state in Ti atoms, that is 3s and 3p,
using the single zeta basis, while setting other states as doube zeta basis.
Therefore, could the command PAO.Basis and PAO.BasisSizes be used together? How?

The parameters I am trying was listed below:

%block PAO.BasisSizes
Ti DZ
O DZ
%endblock PAO.basisSizes
%block PAO.Basis
 n=3    0    1
   5.7
   1.0
 n=3    1    1
   5.7
   1.0
%endblock PAO.Basis


But it failed when I tried this and it warming me below:

New_DM. Step:     1
Initializing Density Matrix...
propor:Â ERROR:Â Â IMAXÂ =Â 0
ERROR STOP from Node:    0
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 5
propor:Â ERROR:Â Â IMAXÂ =Â 0
ERROR STOP from Node:    5
propor:Â ERROR:Â Â IMAXÂ =Â 0
ERROR STOP from Node:    5
rank 6 in job 24  whitby_49161   caused collective abort of all 
ranks
  exit status of rank 6: killed by signal 9Â

What should I do with this mixed parameters? Thanks.

Ting

Re: [SIESTA-L] self confinement

[Roberto Pasianot]

Hi,

SIESTA includes some automatic ways to choose the basis functions, check
the manual carefully.
If for any case you need something better, then check the homepage to see
if someone else already contributed a basis set.
Last, if you need to build the basis by yourself, SIESTA comes with some
utilities for that purpose, that, among other goodies, use the simplex
optimization algorithm. It is at this point where you optimize the
parameters for the basis ... and do not touch them any more ! ;)
The procedure is rather involved but well documented.

Good luck,

Roberto


On 09/30/2014 04:59 PM, Ting Zheng wrote:

Hi,
I'm am calculating the surface properties of rutile slab using SIESTA. I am
quite confusing with the parameters in PAO.basis.
Firstly, how the parameters of V0 (Prefactor of the soft-confinement potential)
and ri (Inner radius where the shoft-confinement potential starts off) were
initialized in the input file. Is there any experience we can refer to?
Secondly, in classical molecular dynamics simulation, the initial charge for O
and Ti (in rutile slabls) is -1.098 and 2.196 seperately, so could I set the
ionic charge as -1.098 and 2.196 in PAO.basis?

Thanks
Ting

Re: [SIESTA-L] vibrational frequencies

[Roberto Pasianot]

Hi,

fcbuild just sets up the crystallography for latter use by vibra.
What are the correct parameters for running siesta, such as to
get the force constants matrix, is still your responsibily.
Thus,
a) add the slabdipolecorrection and the k-point grid you already
used.

b) not sure you can do that easily; you might try to perform the
siesta run with constraints, namely, fix every coordinate but those
of the acid. This will produce a reduced force constants matrix
(*.FC file) to feed vibra ... and hopefuly ...

Regards,

Roberto

On 08/22/2014 06:47 AM, Geldof Davy wrote:

Dear Siesta users,

I am calculating vibrational frequencies with the vibrator package.
The system consists of a titanium oxide surface adsorbing an acid.
I first did geometry optimization with slabdipolecorrection and a certain 
k-grid.
Then I want to calculate the vibrational frequencies of the acid:

a) When applying the fcbuilld, I noticed that both slabdipolecorrection and
k-grid is not taken into account.
Is it necessary to add both parameters to calculate the vibrational frequencies
or is a calculation considering only the gamma point sufficient?

b) I am mostly interested in the vibrational frequencies of the acid on the 
surface.
Is it possible to calculate only the vibrational frequencies of the acid?

Kind regards,


Davy Geldof
Structural Chemistry Group, Department of Chemistry
University of Antwerp, Universiteitsplein 1, 2610 Antwerp, Belgium
davy.gel...@uantwerpen.be

Re: [SIESTA-L] can not constrain atom using constr.f (with attched constr.f)

[Roberto Pasianot]

Hi,

On 08/14/2014 04:26 AM, zgp121 wrote:

Dear Nick,
Thanks for your suggestion.
I have tried it, and it succeeded. If I want to fix atom 1 to 3 the x and y
coordinates, I should write two lines,
position from 1 to 3  1.0  0.0  0.0  # no movement in x-direction
position from 1 to 3  0.0  1.0  0.0  # no movement in y-direction
which can not be written in one line,
position from 1 to 3  1.0  1.0  0.0


Thus, this probably means that displacements must be perpendicular to
vector (1,1,0) ...


Dear Roberto,
Also, the method I mentioned first can achive the same thing. When I run again
for the same job, it succeeded.


... and this that you had the *.XV file from the previous run, so that
coordinates and velocities where effectively read from it.

Best,

Roberto

Re: [SIESTA-L] can not constrain atom using constr.f (with attched constr.f)

[Roberto Pasianot]

Hi Guangpin,

I might be mistaken but, if it is real MD (as opposed to purely
structural, 0 K, optimization) ...¿ how about the velocities ?.
Atoms are given random velocities from a Maxwell-Boltzmann
distribution according to the specified initial T. Thus, killing
the forces wouldn't be enough to stop them moving.

Regards,

Roberto

On 08/13/2014 05:19 AM, zgp121 wrote:

Dear all,
I wan to do molecular dynamics for part of my system. So I use constr.f to
constrain some of the atoms. As attached my constr.f, during the molecular
dynamics, I want only my first 10 and last 10 atoms rigidly move along z axis.
So, there only two dimensions unstricted for the 20 atoms.
But the results show that the x, y coodinates of the 20 atoms also move.
So, can anyone give some suggestions?
Guangping Zhang
[snipped]

Re: [SIESTA-L] Help with phonon calculations...!!!

[Roberto Pasianot]

Hi,
Check the docs, you are missing the atomic masses.
R.

On 12/20/2013 05:16 AM, acharya k.l.n. wrote:

Dear Siesta Users,

   I have been trying to calculate the phonon band structure of NbS2 system.
While running fcbuild I get the following error.

recoor: Atomic-coordinates input format  = Cartesian coordinates
recoor:(in Angstroms)
vibrator: not enough values in Coords line
vibrator: not enough values in Coords line

how do I rectifying this error. I attach my fdf file for fcbuild below

--
With Regards,
K L N Acharya,
Pre-Doctoral Student,

Re: [SIESTA-L] * ProcessorY, Blocksize: 16 24

[Roberto Pasianot]

Hi,

So, where is the error ?. ProcessorY (= 16) must be a factor of
the total number of processors used; is such your case or not ?.
Regards,
Roberto

On 12/05/2013 09:32 AM, Gregorio García Moreno wrote:

Dear siesta users
I'm working with a big systems  (unit cell with around 600 atoms), and always i
try to run my job, i obtain the same error at the end of my ouput file:
* ProcessorY, Blocksize:   16  24
And the jobs stops

I have trid to adding these options to the input, and changing their quantities.
Unfortunately i obtain the same error.
How could i fix this?
Thanks in advance
Gregorio

Re: [SIESTA-L] * ProcessorY, Blocksize: 16 24

[Roberto Pasianot]

Congratulations !. Just to contribute to the knowledge base, would you
please dare to comment what was it ?. Thanks.
R.

On 12/05/2013 02:58 PM, Gregorio García Moreno wrote:

Finally i was able to solve my problems
Thanks

El 05/12/2013 15:08, Gregorio García Moreno escribió:

Thanks Roberto, but my problem is that the job stops after this
Im working with 128 processors (128/16 =8) or 256.
I'm no able to find my error..


El 05/12/2013 14:35, Roberto Pasianot escribió:

Hi,

So, where is the error ?. ProcessorY (= 16) must be a factor of
the total number of processors used; is such your case or not ?.
Regards,
Roberto

On 12/05/2013 09:32 AM, Gregorio García Moreno wrote:

Dear siesta users
I'm working with a big systems  (unit cell with around 600 atoms), and always i
try to run my job, i obtain the same error at the end of my ouput file:
* ProcessorY, Blocksize:   16  24
And the jobs stops

I have trid to adding these options to the input, and changing their
quantities.
Unfortunately i obtain the same error.
How could i fix this?
Thanks in advance
Gregorio

Re: [SIESTA-L] DirectPhi

[Roberto Pasianot]

Hi,

I normally use DirectPhi T without any problem. To be specific,
the user guide says that when set to T, the elements of certain
array are being computed as needed, instead of storing the whole
array to RAM and then usinf it. Thus it must be using less memory.

Are you really sure the memory was exhausted ?. Segmentation
faults just means troubles with memory, it may be due to a number
of causes.
Have you ever tried running a small case using DirectPhi T ?

Regards

Roberto

On 10/21/2013 12:17 PM, Hela Ouali wrote:

Hi Siesta users,

I am encountering problems with the use of DirectPhi True.
I am performing a calculation with 99 atoms, which works perfectly with
DirectPhi false. But when I set it to True, the terminal responds with Signal:
Segmentation fault (11): which means that the memory permitted is exceeded.
That seems awkward to me, because in the siesta doc, it is said that this
parameter permit to use less memory.
Has anybody already encountered this problem ?

Thank you

Re: [SIESTA-L] Electronic temperature in Anneal MD

[Roberto Pasianot]

Hi Pedram,

MD temperature is reaĺ, thermodynamic temperature.
Electronic temperature is just a smearing parameter for the
Fermi surface, that easies the computation of integrals in
reciprocal space involving occupied states. You could use
the MP scheme instead of the FD one, thus loosing connection
with any statistical distribution. Or even choose zero, with
possible horrible effects on SCF convergence.

Bye, bye,

Roberto


On 09/05/2013 11:41 AM, pedram heidari wrote:

Hi,

I have problem with temperatures in MD Anneal in Si.fdf that is present in
tests directory in siesta code. (I have enclosed the .fdf)

There, I can see the electronic temperature is 300K and two other parameters as:

MD.InitialTemperature 100 K
MD.TargetTemperature 600 K

To my understanding, the electronic temperature comes from the fermi-dirac
distribution and deals with the valence electrons but MD temperatures come
from Maxwell-Boltzmann distribution for atoms and should consider the role of
the nuclei as well, if I am not mistaken.

What is exactly the point of mentioning the temperature in two different
distributions in one MD simulation?

Thanks,
Pedram

Re: [SIESTA-L] serial SIESTA stopped without any error message

[Roberto Pasianot]

Hi Camps,

See, I know nothing about your system and never done calculations
with VdW pseudos. However I noticed that the cut off radius of your
f basis function for Co is about twice the shortest edge of your
box ... this calling for troubles I think.

Best,

Roberto

On 08/27/2013 03:49 PM, I. Camps wrote:

Hello SIETers,

I am running a SIESTA calculation for a CoO2 using van der Waals 
(siesta-trunk-433)
The input, pseudopotentials and log (for serial run) are attached.

When running in parallel, I got the following error message at the end of the 
log:

siesta APPLICATION TERMINATED WITH THE EXIT STRING: Segmentation fault (signal 
11)

Googling, I read abut this been a MPI problem, so I run in serial.

When running in serial, SIESTA stopped without any message.

I appreciate any help with this issue.

[]'s,

@mps

Re: [SIESTA-L] Constraint routine: question about forces

[Roberto Pasianot]

Hi Frank,

What do you want to do ?. A net force applied to an isolated
body causes the latter to never stop moving, it doesn't matter
how the force is distributed. This is surely not what you
mean.
Regards,

Roberto


On 08/13/2013 05:49 AM, Frank Maier wrote:

Hello,

I try to add a constraint to my system using the constraint routine in Fortran
using the latest SIESTA Trunk 433.
Sadly I encountered an issue which I was able to break down to a simple test
system:

I want to apply a force of 1eV/Ang along the z-axis homogeneously to the DNA
base Thymine which consists of 15 atoms in total. In order to do this, I first
calculate the sum of the mass of all atoms and then apply a weighted force along
the z-axis to each atom depending on their mass relative to the whole mass of
the molecule (the code is attached at the end of the mail).

If I do this, the hydrogen atoms barely move, oxygen atoms move the most,
followed by nitrogen and carbon. So depending on their mass, they move 
differently.

If I apply 1/15 eV/Ang to each atom however, they move equivalently, which
shouldn't happen in my opinion. If I apply a force of 1N to a mass of 1kg it
should have a different impact compared to a force of 1N to a mass of 16kg.


In principle, for my real simulation, i want to preserve the relative height of
atoms in a molecule, identical to how it gets done in the Siesta manual example:
fz = fa(3,1) + fa(3,2)
fa(3,1) = fz * amass(1)/(amass(1)+amass(2))
fa(3,2) = fz * amass(2)/(amass(1)+amass(2))
But this suffers the same problem, the atoms just move differently, depending on
their mass. So exactly the opposite to how it should happen.

Can someone help me.

Below is the constraint routine I use attached and also the simulation file so
you can understand what I've done.

Thank you for your help,
Frank Maier



### CONSTRAINT ROUTINE ###
   implicit none
   integer  na, isa(na), ntcon
   double precision amass(na), cell(3,3), fa(3,na),
   . stress(3,3), xa(3,na)
   double precision force_z
   double precision mass_sum
   integer  counter

c Write here your problem-specific code

   ! sum all masses
   mass_sum = 0
   counter = 1
   do while (counter = 15)
 mass_sum = mass_sum + amass(counter)
 counter = counter + 1
   end do

   ! drag it along the z axis by setting an average force to all atoms
   force_z = 0.038895
   counter = 1
   do while (counter = 15)
 fa(3, counter) = force_z * amass(counter)/mass_sum
 counter = counter + 1
   end do


   ! number of constraints
   ntcon = 1

   end



### SIESTA INPUT FILE ###
SystemName simulation

SystemLabelsimulation

NumberOfAtoms  15
NumberOfSpecies4

%block Chemical_Species_label
1  6   C
2  1   H
3  7   N
4  8   O
%endblock Chemical_Species_label

LatticeConstant1 Ang

%block LatticeVectors
   20.0 0.0 0.0
   0.0 20.0 0.0
   0.0 0.0 20.0
%endblock LatticeVectors

AtomicCoordinatesFormat NotScaledCartesianAng

%block AtomicCoordinatesAndAtomicSpecies
   -0.055415 4.678721 0.04650541O
0.056186 0.053516 0.04475442O
   -2.040067 3.505861-0.18511033N
   -0.021091 2.357257 0.01669334N
   -0.646655 3.608724-0.03244015C
   -0.631420 1.071320-0.03420916C
   -2.096698 1.092563-0.18356517C
   -2.817098-0.233357-0.25039518C
   -2.727280 2.298413-0.25313819C
0.990177 2.373717 0.118928210H
   -2.534782 4.389011-0.226380211H
   -3.804217 2.386022-0.365223212H
   -3.898566-0.088334-0.347702213H
   -2.456966-0.824419-1.102264214H
   -2.614350-0.824912 0.651503215H
%endblock AtomicCoordinatesAndAtomicSpecies

%block GeometryConstraints
   routine constr
%endblock GeometryConstraints

PAO.BasisSizeTZP
PAO.BasisTypesplit

PAO.EnergyShift10.0 meV

PAO.SplitNorm0.20
PAO.SplitNormH0.50

PAO.SoftDefault true
PAO.SoftInnerRadius0.9
PAO. SoftPotential40.0 Ry

XC.functional  GGA
XC.authors PBE
SpinPolarizedfalse

SolutionMethoddiagon

ElectronicTemperature300 K

NeglNonOverlapIntfalse

DM.MixingWeight0.1

DM.Tolerance1.d-4
DM.NumberPulay4

MeshCutoff250. Ry

MD.TypeOfRun   CG
MD.NumCGsteps  500
MD.MaxCGDispl  0.2 Bohr
MD.MaxForceTol 0.02 eV/Ang

Re: [SIESTA-L] Constraint routine: question about forces

[Roberto Pasianot]

Hi Frank,

I've used the constraint routine many times and it ever worked fine for me.
Your molecule is isolated, it should not rotate anyway becuase internal
forces possess no mechanical torque. I mean, such a constraint would be
superfluous.
I any case, if you still want to apply such a constraint, you should
find out how the atoms would move in such a virtual rotation, namely,
build up the rotation mode, then project the forces onto that mode, and
finally subtract the projection from the force vector.
Cheers,

Roberto

PS: Note that your're doing a static energy minimization, the masses play
no physical role here.

On 08/13/2013 09:20 AM, Frank Maier wrote:

Hi Roberto,

you're right, the setup is idiotic :-) but it's indeed what I want. It's just a
test setup to validate the constraint routine and it nicely shows that it
doesn't work.

For my proper simulation I want to block the rotation of the molecule along one
axis with the constraint routine but still allow a translation. For this I
calculated the sum of all forces acting on the molecule along the z-axis and
distributed this force over all atoms, identical to how it gets done in the
example in the SIESTA manual. But then I noticed, that the hydrogen atoms in the
molecule barely move at all while the heavier atoms move away.

Thus I constructed this artificial system to find the failure. But now I'm 
stuck.
Including the mass makes sense to me, but it doesn't work.
Neglecting the mass works, but doesn't make sense to me.

Best wishes,
Frank

On 08/13/2013 02:11 PM, Roberto Pasianot wrote:

Hi Frank,

What do you want to do ?. A net force applied to an isolated
body causes the latter to never stop moving, it doesn't matter
how the force is distributed. This is surely not what you
mean.
Regards,

Roberto


On 08/13/2013 05:49 AM, Frank Maier wrote:

Hello,

I try to add a constraint to my system using the constraint routine in Fortran
using the latest SIESTA Trunk 433.
Sadly I encountered an issue which I was able to break down to a simple test
system:

I want to apply a force of 1eV/Ang along the z-axis homogeneously to the DNA
base Thymine which consists of 15 atoms in total. In order to do this, I first
calculate the sum of the mass of all atoms and then apply a weighted force along
the z-axis to each atom depending on their mass relative to the whole mass of
the molecule (the code is attached at the end of the mail).

If I do this, the hydrogen atoms barely move, oxygen atoms move the most,
followed by nitrogen and carbon. So depending on their mass, they move
differently.

If I apply 1/15 eV/Ang to each atom however, they move equivalently, which
shouldn't happen in my opinion. If I apply a force of 1N to a mass of 1kg it
should have a different impact compared to a force of 1N to a mass of 16kg.


In principle, for my real simulation, i want to preserve the relative height of
atoms in a molecule, identical to how it gets done in the Siesta manual example:
fz = fa(3,1) + fa(3,2)
fa(3,1) = fz * amass(1)/(amass(1)+amass(2))
fa(3,2) = fz * amass(2)/(amass(1)+amass(2))
But this suffers the same problem, the atoms just move differently, depending on
their mass. So exactly the opposite to how it should happen.

Can someone help me.

Below is the constraint routine I use attached and also the simulation file so
you can understand what I've done.

Thank you for your help,
Frank Maier



### CONSTRAINT ROUTINE ###
   implicit none
   integer  na, isa(na), ntcon
   double precision amass(na), cell(3,3), fa(3,na),
   . stress(3,3), xa(3,na)
   double precision force_z
   double precision mass_sum
   integer  counter

c Write here your problem-specific code

   ! sum all masses
   mass_sum = 0
   counter = 1
   do while (counter = 15)
 mass_sum = mass_sum + amass(counter)
 counter = counter + 1
   end do

   ! drag it along the z axis by setting an average force to all atoms
   force_z = 0.038895
   counter = 1
   do while (counter = 15)
 fa(3, counter) = force_z * amass(counter)/mass_sum
 counter = counter + 1
   end do


   ! number of constraints
   ntcon = 1

   end



### SIESTA INPUT FILE ###
SystemName simulation

SystemLabelsimulation

NumberOfAtoms  15
NumberOfSpecies4

%block Chemical_Species_label
1  6   C
2  1   H
3  7   N
4  8   O
%endblock Chemical_Species_label

LatticeConstant1 Ang

%block LatticeVectors
   20.0 0.0 0.0
   0.0 20.0 0.0
   0.0 0.0 20.0
%endblock LatticeVectors

AtomicCoordinatesFormat NotScaledCartesianAng

%block AtomicCoordinatesAndAtomicSpecies
   -0.055415 4.678721 0.04650541O
0.056186 0.053516 0.04475442O
   -2.040067 3.505861-0.18511033N
   -0.021091 2.357257 0.01669334N
   -0.646655 3.608724-0.03244015C
   -0.631420 1.071320-0.0342091