Error about runtime_parameters

[phylyh]

I generate the input file using VNL(NanoLanguage Script) and My calculation stop abnormally as follows:

# Equivalent Bulk Calculation (Initial Density for TwoProbe)
# ----------------------------------------------------------------
Traceback (most recent call last):
  File "c:/docume~1/rhine/locals~1/temp/tmp6piqeg.nl", line 421, in ?
    runtime_parameters = runtime_parameters
ATKError: bad allocation
Terminated Abnormally




I have no idea about this error after checking my input file several times. How to resolve it???

The original input.py and output files are enclosed.

Thanks for all

[Nordland]

It is not a runtime parameter issues, the reason why it appers so, is because it is the command, that makes the calculation crash

# Perform self-consistent field calculation
scf = executeSelfConsistentCalculation(
    twoprobe_configuration,
    two_probe_method,
    runtime_parameters = runtime_parameters
)

The problem in your calculation, is that you run of free memory once the two-probe starts to calculate the starting guess density, called the Equivalent Bulk Calculation.
There are three ways to help solve this problem:

• Make sure you are not running alot of programs on the machine that takes up the memory.
• You can disable the equivalent bulk calculation as descriped in the manual by using the neutral atomic density
• In your specific case, you should lower the number of kpoints in the z-axis of the electrodes, as this will also reduce the memory usage.

How much memory do you have on your machine?

[Nordland]

A second note should be that the electrode cell should be repeated once or twice more in the z-axis, if you are to calculate the transmission spectrum of this system, as too short cell will create artifical scattering at the boundaries of the electrode.

[phylyh]

Thanks, I will try it again.    My physical memery is 4GB, and the free memery is at least 3GB

[phylyh]

I have resolved the problem after reducing the K points.  However, I meet another wired error.  The same script, which can be well done by windows version VNL,  can not generate any result in Unix using ATK.  I have used dos2unix to transform the script.  The input and output files are enclosed.


Thanks

[Nordland]

The output looks very strange - I have never seen anything like that before.

Could you post the command that you enter in your shell to start this calculation?

[Anders Blom]

I don't think there is anything strange going on here. What looks like jibberish is really just Esc-sequences to generate syntax highlighting / coloring in the terminal window. The last "# sc" line indicates that the calculation has converged nicely. So, the main question is only: what do you mean when you say that it does not generate any result? You should have a file called 'CAP55_1.vnl' in the same directory where you ran ATK, and dropping this file on the Result Browser in VNL you should see the results. If you do this, and there are no results (as I suspect, based on the output file!), it may because you ran out of memory just at the very end. In that case, restore the calculation and run the analysis (calculation of the DOS and transmission) separately. To do this, copy the input script to a new file and replace everything (except the first lines of "import" statements) until the line

Code

# Calculate physical properties

by

Code

scf = restoreSelfConsistentCalculation('CAP55_1.nc')

and run the new script.

[phylyh]

I run ATK simply as follows:

atk<CAP55_1.py>CAP55_1.out

No any *.vnl file generate after ATK running, only CAP55_1.nc exists. 

[Anders Blom]

You should run ATK as

Code

atk CAP55_1.py > CAP55_1.out

otherwise you launch an interactive session, or actually by the looks of it many (you run in parallel?) ... It is a bit weird that there is no VNL file, there should at least be one with the geometry, but maybe things got messed up with respect to "master process" when you run interactively this way. That could explain why there is no analysis output as well. Either that, or you ran out of memory. Either way, try the recipe described above to restore and recalculate the analysis part.

[phylyh]

Oh, my god.

It's well done now.

Thanks a lot

[Anders Blom]

The ability to run ATK interactively can be really useful during analysis or when testing scripts out. The proper way, however, to launch a script interactively (that is, the script will be run but then you are left at the ATK/NanoLanguage prompt and can start typing commands) is

Code

atk -i script.py

Obviously you should not pipe the output anywhere in this case This will not work well in parallel.

[phylyh]

When  I run spin-polarized transmission calculation ,  the error about runtime_parameters  appear again as follows:

Traceback (most recent call last):
  File "CNT55_Fe1_1.py", line 482, in ?
    runtime_parameters = runtime_parameters
ATKError: inverse(DZMatrix const &) : Could not LU factorize!


Does this mean the memery is up ?


The input and output files are enclosed.

Thanks

[Nordland]

This errors is not a memory error, but it most often seen when two atoms are placed ontop of one another, when the two-probe alignment is incorrect...

So try to check if two atoms are placed on top of one another in the twoprobe configuration.

[phylyh]

What's your meaning of "two atoms are placed ontop of one another"?  I generate the py script by VNL and I am sure the structure is what I want.  In my opinion, the alignment is always correct when the script is generated by VNL. Is it right?

Thanks for all

[nori]

Dear phylyh,

I might be able to help you because I'd studied almost the same system as you with ATK.
(please see "fig.pdf", I feel it's miracle!)

When I tried the calculation for such a system, I encounterd the same trouble as you.
Judging from a conclusion, the solution is not to use "DobuleZeta" or "DobuleZetaPolarized" basis.
I don't know why, but when I used DZ or DZP in this system, SCF convergence got suddenly worse.
On the other hand, when I used SZP for both "C" and "Fe", the calculation was normally completed
(Parhaps SZ for both "C" and "Fe" is also good).

In addition, "Initial scaled spin" you designate is not good because (5,5)CNT is not spin-polarized.
("Initial scaled spin" is relevant to SCF convegence in some cases)
It seems natural that "Initial scaled spin" for Fe is 1 and "Initial scaled spin" for C is 0.

I attach the modified version of script(input2.py).
I only changed the "Initial scaled spin" for both central region and electrode in "input2.py".
I recommend the further modifications as follows:
1. k-point sampling for C-direction: from 500 to 100,
2. basis set for Fe: from DZP to SZP or SZ,
3. initial_density_type: from InitialDensityType.NeutralAtom to InitialDensityType.EquivalentBulk,
and if you're interested in finite-bias calculation,
4. electrode_constraint: from electrodeConstraints.Off to electrodeConstraints.RealSpaceDensity or electrodeConstraints.DensityMatrix.

I hope your calculations are done well!