Internal Error Message: viewing Transmission Eigenstates in VNL Nanoscope

[cwolowiec]

Hello,

I'm consistently getting the following error messages when trying to view an isosurface plot of the Transmission Eigenstates for a two-probe system in VNL Nanoscope:


An internal error occured

exceptions. MemoryError:
can't allocate memory for array

....

I should mention that I do not get the same error message for other isosurface plots such as LDOS.
Is there anything I can do to avoid the error...I'm running VNL on a new PC with lots of memory so I don't think it's due to any limitation of the PC.

Thanks,

chris

[Nordland]

How large is the data file in mb you are trying to to load?

[cwolowiec]

Hi,

The VNL file is about 20 MB. It contains  both the atoms of the two-probe configuration as well as the transmission eigenstates output. I guess I could eliminate the atoms from the VNL file to make it smaller, but then I wouldn't be able to see the superposition of the eigenstates on the atoms which is sort of the point.

thanks again,

chris

[cwolowiec]

this is an addition to the previous post:

I should note that nanoscope opens the file and displays the configuration of the atoms with no problem...the trouble is when i try to insert a plot of the transmission eigenstates...

[Nordland]

This is stranged - I have a VNL file of size 80 mb and I can show it with our any issues.

What version of VNL are you using and how much memory do you have on your machine? Are you running alot of other applications in the background?

[cwolowiec]

Hi Nordland,

I'm using version VNL 2008.07.
My machine is only a week old and has 2.0 GB of RAM which should be plenty considering I also made sure to close all other applications before retrying.

I should note that I was getting the same error message on my old machine. I transferred the same version of VNL from the old machine to the new machine but I doubt there would be a problem with both PCs. There could be something wrong with my version of VNL?

chris

[cwolowiec]

as an addition to my last post...I should mention that the scattering region and both electrodes of my two probe system contain 177 atoms in all... this is a large system which could pose a memory problem for visualizing both the atoms and transmission eigenstates together...I forgot to mention that I am able to visualize in nanoscope both transmission eigenstates and atoms together for smaller systems of 150 atoms...any comments are appreciated.

chris

[Nordland]

Visualizing the atoms shold require nothing at all and I have never experienced anything with the atoms, hence I dont think the problem is related to the atomic configuration being in the same file - if you are on windows, I think you should consider reinstalling Virtual NanoLab.

Edit: Sorry it was not windows you should reinstall, but VNL.

[Anders Blom]

It seems that there is a problem in VNL regarding large 3D grids using too much memory.

For lack of a better solution at the moment, I generally suggest putting only one large grid per VNL file. That is, use separate VNL files for each transmission eigenstate. Not a pretty solution, but as long as you can visualize it, it's just a minor inconvenience. Of course you will want a copy of the geometry in each file as well. So, make a separate VNL file with only the geometry, then extract the geometry from this file and copy it to each VNL file with the transmission eigenstate.

Let me know if you need help with the NanoLanguage code to do that.

[cwolowiec]

Hi Anders,

It's a little reassuring to know that I've approached this problem as you've stated. In a single VNL file I have included only the two probe configuration and only the first transmission eigenstate. As mentioned before, this file is about 20 MB and I'm still having the same problem. I also tried reinstalling VNL but to no avail, the error still exists.

thanks again,

chris

[tigeryzz]

Which operating system do you use? I suggest you  use linux rather than Windows. My experience is that whether 32 or 64 bit, VNL can only use 1GB RAM under windows, so if you use Windows, try Linux again and then see if the problem still exists.

[Anders Blom]

We have designed a workaround for this problem, that hopefully works in most cases. The issue is memory, so the way to resolve it is to reduce the size of the grids. Transmission eigenstates are particularly difficult since they are complex, and so consume double the amount of memory compared to potentials and densities. ATK uses the mesh cut-off on the SCF object to determine the grid spacing. It is often sufficient to have a 50-100 Ry mesh cut-off for plotting the grids. However, it is certainly not always possible to converge the calculation at such small values - and if you do, maybe the results are not accurate enough! Therefore, we need to overwrite the value of the mesh cut-off on the SCF object after the calculation is finished to fool ATK into using different (larger) grid spacing for the evaluation of the grids to be plotted. To do this, insert the following line of code somewhere between the point where the SCF object is created and where you use the SCF object for evaluating the grids:

Code

scf._attributeContainer().getAttributeContainer('SetupAttributes').setDouble(100.,'MeshCutoff')

Here we used the value 100 Rydberg (the unit is implicit); if the grid is still too big for VNL, reduce to 80 and try again, etc. This works both if the SCF object was generated in the same script (by executeSelfConsistentCalculation()) or restored from a checkpoint/NetCDF file (by restoreSelfConsistentCalculation()). In future editions of ATK, I imagine it will be possible to specify a custom mesh cut-off directly to the routines that evaluate grids. Plus, that the memory usage will be lower in VNL!

[Anders Blom]

By the way, you may have forgotten which mesh cut-off you used for a particular calculation/checkpoint file. You can print this using the following code:

Code

from ATK.KohnSham import *
import PyATK

scf = restoreSelfConsistentCalculation("mycheckpointfile.nc")

meshcutoff = PyATK.doublep_value(scf._attributeContainer().getAttributeContainer('SetupAttributes').getDouble('MeshCutoff'))
print meshcutoff*Rydberg