Print Page - detect no convergence and kill

QuantumATK => General Questions and Answers => Topic started by: esp on January 30, 2012, 10:08

Title: detect no convergence and kill
Post by: esp on January 30, 2012, 10:08

It seems when ATK does not converge, it just continues running ... is there a way to detect this and kill the program, maybe given some criteria? How can we test whether the program is converging while it is running?

Title: Re: detect no convergence and kill
Post by: Anders Blom on January 30, 2012, 11:24

Once you have reached the maximum number of iterations (200 by default), the program will quit even if it didn't converge. The only sensible way to modify this behavior is to lower the number of maximum iterations you are patient enough to wait for :)

As a general tip, if you increase the number of "history steps", you should see radically improved convergence. Set it to 20, if you can afford it memory-wise. Also the default tolerance of 4e-5 is very strict, using 1e-4 will not really compromise the accuracy of the results, but may lead to reaching the criterion much sooner.

Title: Re: detect no convergence and kill
Post by: esp on January 30, 2012, 11:30

Thank you I will try these.

Title: Re: detect no convergence and kill
Post by: Anders Blom on January 30, 2012, 13:38

Of course, even if the calculation doesn't converge, the script itself will continue to run... There is currently no simple way to detect within the script if a calculation didn't converge. We had this before, it would throw an exception which you could catch. However, it meant you always had to do try: except: on a calculation to avoid it terminating on no-convergence, so some people thought this was a bit inconvenient. Perhaps we should implement a flag on the configuration "calculator.isConverged" or something.

Title: Re: detect no convergence and kill
Post by: esp on February 1, 2012, 06:00

I am wondering ... the problem seems to be during the "equivelent bulk" calculation ... there are lines that say something like:

8 E = -513.02 dE = 1.526373e-05 dM = 8.447881e-05 dH = 1.391400e-04

I am guessing these dE values are deltas as the calculations try to reach convergence, since i notice that the values get smaller and smaller when eventually (hopefully) they stop and it says converged in <> iterations ...

What if I monitor these values as they come somehow, and then kill it after some criteria, ... would this work in principle?

Title: Re: detect no convergence and kill
Post by: Anders Blom on February 1, 2012, 07:47

If we can have a look at your system, we may be able to suggest some settings that will make it converge better. In general ATK convergence is very stable, but it can be a matter of choosing the right parameters sometimes.

If you would monitor anything it would be the warning message about non-convergence, otherwise you just end up reimplementing the self-consistent convergence check which is already in ATK. What you want to avoid is the program continuing even if it didn't converge. So, perhaps lower the number of max steps, and look for the warning in the log file.

But again, the real solution is to make it converge, and we can help with that.

Title: Re: detect no convergence and kill
Post by: esp on February 1, 2012, 08:32

Definitely I understand, and I Am still very much a beginner here ... currently it seems it is running at about 1 hour per calculation, but it is converging .. just slowly ... I do have a general question about self-consistent versus non-SC though: I saw in a post earlier (and have been running self-consistent calcs since then), that the effect of the gate voltage on a device would have a better chance of showing up when you use SC calcs ... I too like the other author, saw that non-SC calcs showed no effect, whereas SC did ... the question is, is there a general way to make non-SC calcs show this effect while still running faster....maybe that question is too general, but maybe you can speak to why that situation seems to produce that particular result .. my understanding was that non-SC calcs may be less accurate, but should still show the effect .. but they do not ... maybe this is specific to my device? it is strange though that he I versus Vgs was totally flat for every Vds value with non-SC calcs ...

I should mention too the computer I am using has dual-6-core processors

thank you

Title: Re: detect no convergence and kill
Post by: Nordland on February 1, 2012, 21:45

If we are talking about the semi-empirical models, then the SCF introduces electrostatics into the problem. It displaces charges to minimize the energy. Therefore an these charges will the be affect by a potential gate or similar, or a gate might introduce a change in charge. Therefore it can not have any effect if the calculation does not included these effect, and therefore it must be self-consistent.

There is in many ways to make the calculation faster, but device calculation can be expensive in terms of time.

Title: Re: detect no convergence and kill
Post by: esp on February 7, 2012, 23:28

ok, I am having a real problem here .. i have been spending the entire week waiting for results, tuning then trying again, .... ok, so as a last resort i though i would make the simplest structure possible, to see how long it takes ...

I made a graphene type FET device with two electrodes, and a gate ... i just want some IV curves, so i am doing a transmission spectrum calc .. attached is the nc file .. "cfg" is the device configuration ... there are other objects in there but ignore those i am not using those now ...

here are my parameters:

Code


gate_voltage_list = numpy.linspace(-0.2,0.2,11)*Volt
bias_voltage_list = [0.1]*Volt
transSpecEnergies = numpy.linspace(-3,3,31)*eV
kPntsX = 1
kPntsY = 1 # don't need unless periodic here
kPntsZ = 101 # always use odd so gamma point is included
iteration_control_parameters = IterationControlParameters(number_of_history_steps=18, tolerance=1e-4)
numerical_accuracy_parameters = NumericalAccuracyParameters(k_point_sampling=(kPntsX, kPntsY, kPntsZ))
SCF = 1

These two functions perform the task:

Code


def my_DeviceHuckelCalculator():

	# -------------------------------------------------------------
	# Calculator
	# -------------------------------------------------------------
	#----------------------------------------
	# Basis Set
	#----------------------------------------
	basis_set = [
		CerdaHuckelParameters.Carbon_graphite_Basis,
		HoffmannHuckelParameters.Boron_Basis,
		HoffmannHuckelParameters.Hydrogen_Basis,
		HoffmannHuckelParameters.Nitrogen_Basis,
	]

	if SCF == 1:

		#----------------------------------------
		# Electrode Calculators
		#----------------------------------------
		left_electrode_calculator = HuckelCalculator(
			basis_set=basis_set,
			numerical_accuracy_parameters=numerical_accuracy_parameters,
			# set these for SCF
			iteration_control_parameters=iteration_control_parameters,
		)

		right_electrode_calculator = HuckelCalculator(
			basis_set=basis_set,
			numerical_accuracy_parameters=numerical_accuracy_parameters,
			# set these for SCF
			iteration_control_parameters=iteration_control_parameters,
		)

		#----------------------------------------
		# Device Calculator
		#----------------------------------------
		calculator = DeviceHuckelCalculator(
			basis_set=basis_set,
			# set these for SCF
			numerical_accuracy_parameters=numerical_accuracy_parameters,
			iteration_control_parameters=iteration_control_parameters,
			electrode_calculators=[left_electrode_calculator, right_electrode_calculator],
		)

	return calculator

def doTransmission():

	# http://www.quantumwise.com/documents/tutorials/latest/GrapheneDevice/index.html/chap.further.html#chap.further.sect1.both

	nlprint(str(gate_voltage_list));
	nlprint(str(bias_voltage_list));

	#read in the old configuration
	device_configuration = nlread(nc_files + outFileName, object_id="cfg")[0]
	calculator = my_DeviceHuckelCalculator()
	metallic_region0 = device_configuration.metallicRegions()[0]
	device_configuration.setCalculator(calculator)			
	device_configuration.update()

	# Define gate_voltages 	
	for gate_voltage in gate_voltage_list:
	
		for bias in bias_voltage_list:
				
			device_configuration.setMetallicRegions(
					 [metallic_region0(value = gate_voltage)] )

			# Set calculator with applied bias on the configuration
			# use the old selfconsistent state as starting input.
			device_configuration.setCalculator(
				calculator(electrode_voltages=(bias,0.0*Volt)), 
				initial_state=device_configuration)

			gate_voltage_str = str(gate_voltage)
			gate_voltage_str = gate_voltage_str.replace("_", "")
			gate_voltage_str = gate_voltage_str.replace(" ", "")
			
			bias_str = str(bias)
			bias_str = bias_str.replace("_", "")
			bias_str = bias_str.replace(" ", "")
			
			voltageStr = "[vg" + gate_voltage_str + "][vds" + bias_str + "]"
						
			#Analysis
			#electron_density = ElectronDifferenceDensity(device_configuration)
			#nlsave(nc_files + outFileName2, electron_density,object_id='dens'+voltageStr)

			#electrostatic_potential = ElectrostaticDifferencePotential(device_configuration)
			#nlsave(nc_files + outFileName2, electrostatic_potential, object_id='pot'+voltageStr)

			# -------------------------------------------------------------
			# Transmission spectrum
			# -------------------------------------------------------------
			transmission_spectrum = TransmissionSpectrum(
				configuration = device_configuration,
				energies = transSpecEnergies,
				kpoints = MonkhorstPackGrid(1,1),
				energy_zero_parameter = AverageFermiLevel,
				infinitesimal = 1e-06*eV,
				self_energy_calculator = KrylovSelfEnergy(),
			)

			nlsave(nc_files + outFileName2, transmission_spectrum,object_id='trans'+voltageStr)
			now = date.today()
			nlprint("doTransmission " + voltageStr + " " + str(now.strftime("%m-%d-%y %I:%M %p")))

And the result is .... it is taking many hours and sometimes giving non convergence errors ... why? I removed doping and other more complex things to make the simplest GNR FET type device but i still see more than 60 steps and continuing .. i think it is not converging ... why can it not converge and why does it take sometimes 2 hours for each IV point .. is this normal ? please help...i must be doing something wrong ... if it is nomal then fine, but i just dont want to wait another 24 hours to find out it did not converge .. sorry frustrated here

Title: Re: detect no convergence and kill
Post by: esp on February 7, 2012, 23:32

when i was selectively doping atoms i saw one transmission energy point took 6 hours and gave a warning that it did not converge to the accuracy specified . fyi this is why i tried a simpler structure with no doping

Title: Re: detect no convergence and kill
Post by: esp on February 7, 2012, 23:45

I noticed that the space around the electrodes is larger in the VNL produced devices .. on a previous post I was told to add the vacuum parameter to surround my gate as below, but I see that my electrode passivation atoms ar just slightly not inside the box (i do have a custom script) ...

NanoSheet(N,0, vacuum=12.0*Ang)

The vacuum parameter above seems to only add space in 1 dimension ... can i increase the "box" area around the electrodes in more than 1 dimension? do I need to?

Title: Re: detect no convergence and kill
Post by: esp on February 7, 2012, 23:49

ok well this is interesting, when i use NanoRibbon instead of NanoSheet in my script, then i get more of a space around the device ... ok i will try again with this maybe this will help

Title: Re: detect no convergence and kill
Post by: esp on February 8, 2012, 02:58

Ahh yes, each point is taking 20 minutes now ... great ... must have been the problem .. awesome cant wait now!

lesson: custom scripts are dangerous .. atk is still great ! haha

Title: Re: detect no convergence and kill
Post by: Anders Blom on February 8, 2012, 07:43

:)

Custom scripting can be a bit dangerous, yes. Of course it offers great flexibility, but it also puts responsibility on the user to double-check that everything is consistent, and here the GUI helps a lot. So, always make sure to visualize the structure before running.

Title: Re: detect no convergence and kill
Post by: Anders Blom on February 8, 2012, 07:46

Btw, both Nanoribbon and Nanosheet have an optional keyword "vacuum" which you can use for more control.

Title: Re: detect no convergence and kill
Post by: esp on February 8, 2012, 07:52

YEs but the problem was that only nanoribbon adds vacuum in more than 1 dimension, and in the case of my script where i am putting together different ribbons and then passivating, the nanosheet still only had vacuum on top and bottom, and my hydrogen atoms were sticking outside the box .... i had the same vacuum parameter on both but only with nanoribbon did it add vacuum in 3d ... which i needed

Title: Re: detect no convergence and kill
Post by: Anders Blom on February 8, 2012, 10:03

This is actually related to our previous discussions about "periodicity". The nanosheet is relevant if you want a whole graphene sheet, but if you indeed want the 1D system, it is a ribbon.

Thus, the primary reason for your bad convergence was probably a mismatch between k-points and geometry - the structure was periodic but you had only 1 k-point. Esp. for graphene this is a very bad choice.

Title: Re: detect no convergence and kill
Post by: esp on February 8, 2012, 10:05

I see thank you

QuantumATK Forum

QuantumATK => General Questions and Answers => Topic started by: esp on January 30, 2012, 10:08