QuantumATK Forum

QuantumATK => General Questions and Answers => Topic started by: esp on February 27, 2012, 03:34

Title: IV curves from analyzer
Post by: esp on February 27, 2012, 03:34
when i plot IV curves from a transmission spectrum, i see a lot of bumps in the curve, corresponding to a bumpy trans spectrum .. but when i plot using the analyzer, it smoothes them out somehow .. the question is, is it physically correct to smooth it out .. or not?
Title: Re: IV curves from analyzer
Post by: Anders Blom on February 27, 2012, 15:34
No smoothing is done. I don't recognize the effect you mention.
Title: Re: IV curves from analyzer
Post by: esp on February 27, 2012, 20:03
attached are the curves as seen in ATK analyzer, and also from the standard plotting script from the tutorials
Title: Re: IV curves from analyzer
Post by: Anders Blom on February 27, 2012, 20:37
Something is wrong. My best guess is that the plotting script making the jumpy curve does not sort the bias points - the values are correct by come in the wrong order, they are assigned to the wrong bias values.

Can you send me the details, since you have them at hand (and where you found them, exactly) then I don't have to go look for them, then I can fix them for you.
Title: Re: IV curves from analyzer
Post by: esp on February 27, 2012, 21:12
ok let me piece this together ..

To do this simulation i start here:

Code

gate_voltage_list = numpy.linspace(0.0, 1.5,16)*Volt
bias_voltage_list = [0.8]*Volt

doTransmission()


do transmission looks like this:

Code


def doTransmission():
global logs
global nc_files
global plots
global dopingLvl
global dopingOn
global dopingType
global rowSelect
global colSelect
global dopeL
global dopeC
global dopeR
global rip
global outFileName
global outFileName2
global gate_voltage_list
global bias_voltage_list
global N_vals
global lengthVals
global transSpecEnergies
global kPntsX
global kPntsY
global kPntsZ
global ldos_energies
global iteration_control_parameters
global numerical_accuracy_parameters
global pps
global bafl
global SCF
global ldosBiasVoltage
global ldosGateVoltage
global vac
global doubleGate
global gateOverlap
global dist_1
global dist_2
global dist_3
global simType
global host

global length
global dopeType
global validDopingCfgs

# 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]
metallic_region1 = None
if doubleGate:
metallic_region1 = device_configuration.metallicRegions()[1]
device_configuration.setCalculator(calculator)
device_configuration.update()

# Define gate_voltages
for bias in bias_voltage_list:
for gate_voltage in gate_voltage_list:

if doubleGate:
device_configuration.setMetallicRegions([metallic_region0(value = gate_voltage), metallic_region1(value = gate_voltage)] )
else:
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")))



the plotting function looks like this:

Code

gate_voltage_list = numpy.linspace(0.0, 1.5,16)*Volt
bias_voltage_list = [0.8]*Volt
makeIVPlot_vsVgs()


and

Code

def makeIVPlot_vsVgs():
global logs
global nc_files
global plots
global dopingLvl
global dopingOn
global dopingType
global rowSelect
global colSelect
global dopeL
global dopeC
global dopeR
global rip
global outFileName
global outFileName2
global gate_voltage_list
global bias_voltage_list
global N_vals
global lengthVals
global transSpecEnergies
global kPntsX
global kPntsY
global kPntsZ
global ldos_energies
global iteration_control_parameters
global numerical_accuracy_parameters
global pps
global bafl
global SCF
global ldosBiasVoltage
global ldosGateVoltage
global vac
global doubleGate
global gateOverlap
global dist_1
global dist_2
global dist_3
global simType
global host

global length
global dopeType
global validDopingCfgs

#make list of relevant temperatures
temperature=300*Kelvin

#make list to hold the current calculations
current_list = numpy.zeros( (len(bias_voltage_list), len(gate_voltage_list)) )

print str(current_list)

#plot the current as function of gatevoltage
import pylab
pylab.figure()

for m in range(len(bias_voltage_list)):
bias  = bias_voltage_list[m]

for n in range(len(gate_voltage_list)):
gate_voltage = gate_voltage_list[n]

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 + "]"

if processIsMaster():
print voltageStr

transmission_spectrum = nlread(nc_files + outFileName2, object_id="trans"+voltageStr)[0]
(current_list[m])[n] = transmission_spectrum.current(electrode_temperatures=(temperature,temperature))

#print "vg(" + str(gate_voltage) + ")", current_list[n]
# for each gate voltage plot the IV curve versus bias voltage
pylab.plot(gate_voltage_list,current_list[m],label="vds(" + str(bias) + ")")

print str(current_list)

pylab.xlabel("Vgs (V)")
pylab.ylabel("Current (A)")

pylab.legend(loc="lower right")
pylab.grid(True)
pylab.savefig(plots + outFileName2 + "IVplot2.png",dpi=150)
#pylab.show()


Title: Re: IV curves from analyzer
Post by: Anders Blom on February 28, 2012, 11:23
Hmm, your Python code is a bit ... "non-pythonish" :) In general, don't use "global" unless you absolutely really 100% must have to! Instead, pass variables as arguments to functions.

Also, you can avoid the processIsMaster check by using nlprint(string), it's MPI safe.

Moreover, a general tip for the Forum is to embed Python code using the tag "code=python" (instead of just "code"), it gives nice formatting!

Now, I can't spot the error in your code, but I see one thing that may be an error or oversight. You attempt to plot the current as function of source-drain bias, for a fixed gate voltage. But actually you obtain the current as function of gate voltage, for a given source-drain bias.
Title: Re: IV curves from analyzer
Post by: esp on February 28, 2012, 18:47
The points are obtained, as points, and unless I am missing something, it should not matter what order they are obtained ... (?)  i have two plotting functions, one for I vs Vds at each Vgs and one for I vs Vgs at each Vds ... the points themselves are identified with the voltageStr string variable .. when i plot, i simply read back (whether over Vgs or Vds it shouldn't matter), and plot them ... the points themselves each have thier own objid ... and each trans calc is independent isnt it?  no oversight there ... but i suppose i could run vs Vgs seperately from vs Vds, although that will double the time ... ?  I will try for simplicity but i don't understand why it would work ..

thank you
Title: Re: IV curves from analyzer
Post by: Anders Blom on February 28, 2012, 22:39
It is confusing, so let's simplify :)

First of all, you have to compare the same things. The IV tool only plots current against bias, it doesn't know anything about gate voltage. So if all those points are in the same file, it can probably get confused.

Moreover, you are looking at I against Vg for fixed , and comparing a curve of I against Vs (your two attached plots), so we really can't expect these to be equal.

I still think your jumpy curves from the fact that you have the right values of I, but they come in the wrong order. I can't see, in the Python, however, how that is possible, as you also say.

So, sure, we can ignore the IV tool and focus on getting your plot correct. I'm still stumped there, however... Is the NC file huge? Maybe you can http://letscrate.com it to me.

The point about the wrong plot I made was caused by the comment on one of the last lines in makeIVPlot_vsVgs which says "# for each gate voltage plot the IV curve versus bias voltage" - probably just a copy/pasted comment you forgot to change.

Btw, you can do

Code: python
bias_str = str(bias).replace("_", "").replace(" ", "")

Saves lines ;)
Title: Re: IV curves from analyzer
Post by: esp on February 28, 2012, 22:53
I see, i did not realize the plot was against bias from the analyzer ...

attached is the nc file, it is not large at all ..

thank you for the comments
Title: Re: IV curves from analyzer
Post by: Anders Blom on February 28, 2012, 23:15
I extracted the currents without using your script and got the same jumpy behavior. So, it must be inherent in the saved transmission. Can't say more at this point; either it's an effect that is supposed to be there, for some reason, or something is not done right in the computation.
Title: Re: IV curves from analyzer
Post by: esp on February 28, 2012, 23:18
ok yes and to give some more insight i have opened each trans spectrum manually and i see the "area under the curve" seems to increase and decrease .. so i figured it was correct ... when i plotted in the GUI i got confused, but that is because as i know now, the GUI does not plot versus gate voltage ... so now i know .. interesting effect though and I suppose it is a real effect due to the selective doping at different energies .. most papers use electrostatic doping, or some other method which is not atomically precise .. so maybe this effect is real and no one has shown it (cool for me) .. i have tons of data on this so i will investigate further ...
Title: Re: IV curves from analyzer
Post by: Anders Blom on February 28, 2012, 23:31
One thing I would suggest you to try, is to do lower, more realistic doping levels. This cannot be done by replacing individual atoms, because then you get into the n++ regime immediately, as you have now with "metallic semiconductors". While this can certainly be interesting and relevant sometimes, you may want to have a more traditional situation as well, with n/p doping instead (i.e. with the Fermi level in the gap).

To do this, you can manually add a certain amount of charge to the electrodes. In the script, at some point you will set the calculator on each electrode. Here, you can insert an additional keyword charge=0.001 or -0.001. You can convert this charge to a real doping density by considering the electrode cell size. The doping level needs to be calibrated, so check the electrode band structure again the charge (just for the bulk system), and you can see how nicely you can tune the Fermi level to any position you want in the gap.

In this case you should of course not have any dopant atoms as well, and don't forget to dope both electrodes, if needed. You can even do a gated p-i-n in this scheme. This approach also gets rid of having dopants in the central region, disturbing the transport properties in the part that nominally should be i-type.

Keep in mind you must do the gates simulations self-consistent, and you must set this explicitly since the default for Huckel is (unfortunately, I say) non-self-consistent for now.
Title: Re: IV curves from analyzer
Post by: esp on February 28, 2012, 23:40
thank you very much ... i always do self-consistent, and i do not dope the center region .. i am not interested in Ef in the gap because i am looking at TFETs, but I will try the charge keyword for doping .. i wanted to try atomic level doping because I was thinking that is more realistic than specifiying a doping level that comes from some unknown source .. maybe I am wrong there, but certainly what you are suggesting would be much simpler .. i will try it.  thank you
Title: Re: IV curves from analyzer
Post by: esp on February 29, 2012, 01:59
actually again i am curious about how this works .. if you specify a charge level in something like silicon, where you assume random doping locations .. this makes sense, but from what i have seen in Graphene, the specific location of the dopant atoms make a large difference .. so then, if you specify what seems to be a ficticious charge level, how does it take into account real interactions between the dopant atoms? ... or does it assume electrostatic doping?
Title: Re: IV curves from analyzer
Post by: Anders Blom on February 29, 2012, 09:37
You are right, it really depends on which physical situation you want to model. And for graphene, maybe explicit doping is more relevant.
Title: Re: IV curves from analyzer
Post by: esp on March 1, 2012, 22:05
ok thank you i just want to make sure i understand correctly ..

i have another question . my understanding is that when making changes to atoms, such as i am doing with selective doping locations, .. you need to optimize the geometry in order to get a realistic structure .. my understanding is that although you can specify atoms in any position, that that is not realistic unless you let the optimizer relax the forces, etc .. in order to make a "Stable" configuration, for lack of a better word ... is this a correct understanding, and is it safe to say optimization has to be done always when making precise atomic level changes to structures like nanoribbons?  


--------

i found this statement in the tutorial here: http://quantumwise.com/documents/tutorials/latest/ATKTutorialDevice/index.html/chap.relax.html

"Applying a finite bias will cause the position of atoms to shift slightly, so the geometry should in principle also be optimized under bias. However, the optimization under bias can be very time consuming and usually only has little effect on the transmission and is thus often omitted."

Now, i am concerned about the "usually" statement ... do you think it is possible the results i am seeing for current versus Vgs that i posted earlier could be beacause i am not optimizing after doping the electrodes?

-----

and one more question ...

what i am doing is creating p-i-n tfet GNR structures, doped with N and B in the electrodes ... i am running bandstructure and transmission calcs ... now:
(1) should i optimize geometry after replaceing carbon atoms with N and B? 
(2) when should I optimize? (before bandstructure calc? before trans calc?  before any calc? ) I want to reduce time but be accurate
(3) as noted above, i see that it seems i would need to re-optimize under each bias ... does this include different gate voltages, or just Vds bias?

ed

thank you
Title: Re: IV curves from analyzer
Post by: Anders Blom on March 2, 2012, 16:02
ok thank you i just want to make sure i understand correctly ..

i have another question . my understanding is that when making changes to atoms, such as i am doing with selective doping locations, .. you need to optimize the geometry in order to get a realistic structure .. my understanding is that although you can specify atoms in any position, that that is not realistic unless you let the optimizer relax the forces, etc .. in order to make a "Stable" configuration, for lack of a better word ... is this a correct understanding, and is it safe to say optimization has to be done always when making precise atomic level changes to structures like nanoribbons?  

Usually, yes (with a wink to your question below).

i found this statement in the tutorial here: http://quantumwise.com/documents/tutorials/latest/ATKTutorialDevice/index.html/chap.relax.html

"Applying a finite bias will cause the position of atoms to shift slightly, so the geometry should in principle also be optimized under bias. However, the optimization under bias can be very time consuming and usually only has little effect on the transmission and is thus often omitted."

Now, i am concerned about the "usually" statement ... do you think it is possible the results i am seeing for current versus Vgs that i posted earlier could be beacause i am not optimizing after doping the electrodes?

No, I don't, because you are looking at an effect which is a function of Vgs, not as a function of the inserted doping. Optimizing might change the overall curve, slope/offset etc, but not its internal properties. At least I wouldn't expect that in such a system as yours.

and one more question ...

what i am doing is creating p-i-n tfet GNR structures, doped with N and B in the electrodes ... i am running bandstructure and transmission calcs ... now:
(1) should i optimize geometry after replaceing carbon atoms with N and B? 
(2) when should I optimize? (before bandstructure calc? before trans calc?  before any calc? ) I want to reduce time but be accurate
(3) as noted above, i see that it seems i would need to re-optimize under each bias ... does this include different gate voltages, or just Vds bias?

1. I think that would be wise, but you can probably do this "locally", i.e. check how the B-N bond compares to a C-C bond when embedded in a graphene matrix; probably the difference is small, and the primary effect on the current will be the fact that you now have a dopant present, rather than the small structural details.
2. The optimization is sort of step #1 always, after creating the starting guess geometry. Once you have it you don't need to reoptimize unless you change atoms (as for bias, see 3).
3. This is rarely necessary, the effects of this are usually very small, and typically only relevant if that's the specific effect you are investigating.

The burden of evidence is however always on you :)
Title: Re: IV curves from analyzer
Post by: esp on March 2, 2012, 19:13
thank you very much
Title: Re: IV curves from analyzer
Post by: esp on March 3, 2012, 06:31
what about running self consistently?  is it needed for optimization calculations or can i turn it off when running the optimization (and still get accurate results)? 
Title: Re: IV curves from analyzer
Post by: esp on March 3, 2012, 22:03
How do I know if the optimization did anything that is useful?  in other words, for example, I ran optimization on a structure, it took 6 hours on a $12k computer with 24 cores, ... then i look at it and it looks exactly the same ... should i compare the coordinates?  What else does optimization do?
Title: Re: IV curves from analyzer
Post by: Nordland on March 3, 2012, 22:58
Optimization only does one thing. Move atoms (and possible changes the cells if you enabled it).
When the atoms move the Hamiltonian of the system changes, and hence almost everything derived from the Hamiltonian might change.
So in very short - optimization can change everything.

You can compare coordinates but small displacement might seem insignificant, but they can also be significant.

So the way I usually go about it for devices, is like this:
Title: Re: IV curves from analyzer
Post by: esp on March 3, 2012, 22:59
ok thank you very much
Title: Re: IV curves from analyzer
Post by: Anders Blom on March 5, 2012, 15:19
Regarding your question of self-consistency, it's not just a simple choice you can make. Rather, there are some semi-empirical methods where the parameters themselves are derived to fit in a self-consistent or non-self-consistent calculation scheme, and using them inversely can give unpredictable results. So one must actually know which is the case for the method you plan to use.

DFT is inherently self-consistent only, so the non-self-consistent results are dangerous. They can be used for quick-and-dirty calculations, or (at least with some care) to check for convergence in e.g. k-points. In ATK, non-self-consistent calculations for devices has a special meaning of running only the equivalent bulk (the central region) self-consistently and using this as the result for the device. This is a crude approximation, but again it can be used for some early checks - or, to run an optimization of the device geometry (i.e. by optimizing the central region, which typically is a good approximation).

We should make some of these things clearer in the future, so it doesn't appear a completely free choice.