part of MPSH orbital outside the unit cell

[zhangguangping]

Dear all,

When I plot the MPSH orbital of a junction, I found the MPSH orbital is split into two part because some part are outside the unit cell as seen in the attachment. How to solve this by no construct a new junction and rerun the job?

And how to show the configuration of the two probe in the MPSH orbital? I did not find the option. I have used nlsave to save the configuration into the nc file before the MPSH orbitals are save into this nc file.

With best regards,

/Guangping

[Umberto Martinez]

In the Viewer you can repeat the isosurface in the three directions (under properties).
This should solve your issue

[zhangguangping]

Dear Umberto,

Thanks very much.

I should try the repetition function. I though it was not for this.

And how to show the configuration of the structure along with the MPSH wavefunction?

With best.

Guangping

[Umberto Martinez]

Drag and drop the configuration on top of the isosurface window. You have the repetition option for the configuration as well.

[zhangguangping]

Dear Umberto,

Thanks very much for your kind reply. It is of great help.

Have a nice weekend.


/Guangping

[zhangguangping]

Drag and drop the configuration on top of the isosurface window. You have the repetition option for the configuration as well.

Dear Umberto,

Alough the repetition option can make the split MPSH orbital into a whole one, it is not convenient to output the MPSH orbitals in only one unit cell.
To solve this, I have written a FORTRAN code that can manipulate the grid data to make the split MPSH orbital into a whole one, see the attached.

Also, I have found something uncomfortable in the format of numbers at the head of cube files, the width of numbers should be increased to make numbers separate.

CUBE FILE. DATA VALUES IN UNITS OF 1/Bohr**1.5, LENGTHS IN BOHR
OUTER LOOP: X, MIDDLE LOOP: Y, INNER LOOP: Z
  248 0.000000e+00 0.000000e+00 0.000000e+00
   99 2.205845e-01 0.000000e+00 0.000000e+00
   99-1.102922e-01 1.910322e-01 0.000000e+00
  444 0.000000e+00 0.000000e+00 2.220775e-01
   47 0.000000e+00 2.729734e+00 1.576013e+00 2.228819e+00
   47 0.000000e+00 8.189202e+00 1.576013e+00 2.228819e+00
   47 0.000000e+00 1.364867e+01 1.576013e+00 2.228819e+00
   47 0.000000e+00 1.910814e+01 1.576013e+00 2.228819e+00
   47 0.000000e+00-0.000000e+00 6.304051e+00 2.228819e+00
   47 0.000000e+00 5.459468e+00 6.304051e+00 2.228819e+00
   47 0.000000e+00 1.091894e+01 6.304051e+00 2.228819e+00
   47 0.000000e+00 1.637840e+01 6.304051e+00 2.228819e+00
   47 0.000000e+00-2.729734e+00 1.103209e+01 2.228819e+00
   47 0.000000e+00 2.729734e+00 1.103209e+01 2.228819e+00

[Anders Blom]

It is not a good idea to increase the width of the number field, at least if you want to strictly abide to the specification of the CUBE file format:
http://paulbourke.net/dataformats/cube/ (although this page is from 2003, but I don't know of a more standard
As you see, the numbers are ("originally") supposed to take up a certain amount of characters ("12 characters wide with 6 decimal places") and it's not a problem for a computer to read the file even if the numbers are "melted" together. Harder for the eye yes, but if one increases it to say 15 characters wide or even just space-separated, it's not certain that all codes can read the file anymore, if they are written according to the standard. But on the other hand, the page says "most parsing programs can read any white space separated format" which is probably true. Still, one is not really supposed to look at this kind of data manually, so formatting for the eye isn't really an issue.

[zhangguangping]

It is not a good idea to increase the width of the number field, at least if you want to strictly abide to the specification of the CUBE file format: http://paulbourke.net/dataformats/cube/ (although this page is from 2003, but I don't know of a more standard As you see, the numbers are ("originally") supposed to take up a certain amount of characters ("12 characters wide with 6 decimal places") and it's not a problem for a computer to read the file even if the numbers are "melted" together. Harder for the eye yes, but if one increases it to say 15 characters wide or even just space-separated, it's not certain that all codes can read the file anymore, if they are written according to the standard. But on the other hand, the page says "most parsing programs can read any white space separated format" which is probably true. Still, one is not really supposed to look at this kind of data manually, so formatting for the eye isn't really an issue.

Dear Anders Blom, Thanks for your kind reply. This suggestion is not only for the eye, but for the read in code. I now use a fortran code of the following to read the cube data

Code

	  open(unit=11,file=inputcube)
	  read(11,*) head1
	  read(11,*) head2
	
	  read(11,*), N_atom,Orig(1),Orig(2),Orig(3)
	  read(11,*), nX,dV1(1),dV1(2),dV1(3)
	  read(11,*), nY,dV2(1),dV2(2),dV2(3)
	  read(11,*), nZ,dV3(1),dV3(2),dV3(3)
	
	  allocate(cube_a(nX,nY,nZ))
	  allocate(cube_b(nX,nY,nZ))
	  allocate(xuhao(N_atom),zb_0(N_atom))
	  allocate(zb_x(N_atom),zb_y(N_atom),zb_z(N_atom))
	
	  do i=1, N_atom
	    read(11,*) xuhao(i),zb_0(i),zb_x(i),zb_y(i),zb_z(i)
	  enddo
	
	  read(11,*)
     &  (((cube_a(i,j,k),k=1,nZ),j=1,nY),i=1,nX)
	
	  close(11)

this kind of read directives need white for seperate the numbers apart. I am glad to know how to read a fixed width number even though it may melt with the neighbours? With best regards, /Guangping Zhang

[Anders Blom]

I have very little knowledge of Fortran, but I know enough to tell you that in fact this kind of text format with a fixed number of characters per field is designed specifically for Fortran (at least old-style Fortran code). So it must be easy to read in that language, probably using the 12.6 floating point format somehow, I don't know maybe read(11,"(D12.6)") or similar does the trick?

[zhangguangping]

I have very little knowledge of Fortran, but I know enough to tell you that in fact this kind of text format with a fixed number of characters per field is designed specifically for Fortran (at least old-style Fortran code). So it must be easy to read in that language, probably using the 12.6 floating point format somehow, I don't know maybe read(11,"(D12.6)") or similar does the trick?

Dear Anders,

Thanks for your reply.

I will search it on the web.

Maybe, the fix formatting reading are just for fix formatting, and not for the free formatting.

With best regards,

/Guangping Zhang