Add Solution Variables: Difference between revisions

From Flooxs
Jump to navigation Jump to search
(discussion of different variable types in floods)
 
No edit summary
 
Line 58: Line 58:
   pdbSetString contact.ni $ni
   pdbSetString contact.ni $ni
  }
  }
= "sel z=" - the Alligator command =
= "set" - the tcl command =

Latest revision as of 14:16, 11 June 2020

"solution"

PDE vs CONST

solution add name=Elec pde solve !negative
solution add name=Elec const solve val=(expression)

MATERIAL DEPENDENT SOLUTIONS

solution add name=Elec Silicon
solution add name=Elec Oxide

VIEWING YOUR SOLUTIONS To view a "const" expression:

solution print Silicon name=Elec

To view a "pde" expression (assuming you have set it in the pdb):

pdbGetString Silicon DevPsi

To view the values currently stored in a pde or const, use print.?d or plot.?d:

sel z=var
print.1d
plot.1d

But beware - solutions are only updated during solves (for example, when you call the "device" command). You cannot sel z=Elec; print.1d; if you haven't solved for your solution yet - you will get "Elec does not simulator resolve". Alternately, you can give unsolved-for solutions a 1-time value using "sel z=val name=var" (see below), and then you will be able to "sel z= " other variables that depend on the one you have selected. For example:

set Chi 4.1
solution add name=Ec Silicon const solve val=(-(DevPsi)-$Chi)

#check if Ec is calculated correctly (check math)
sel z=Ec
Ec does not simulator resolve

#DevPsi hasn't been solved for yet. Need to give DevPsi a value to test math
sel z=0.0 name=DevPsi
sel z=Ec
Ec does simulator resolve

Other useful commands: list all solution variables, list all materials.

solution list
mater list

Suggestion: It's a good idea to enclose your val=(expressions) in parenthesis, in case subtract this solution variable from something in an expression or solution later.

Known Bugs 1. DO NOT ENCLOSE YOUR VAL=(EXPRESSIONS) IN QUOTES. The parser is buggy in this case. 2. Contact equations cannot parse "const" type solutions. Therefore, when you declare a solution variables that could be used in a contact equation, it is a good idea to also define a double or string (with no const variables) that can be used instead for the contact equations. For example, the procedure below implements the Slotboom band-gap narrowing model by modifying "ni" according to the doping (previously defined NA and ND values or expressions). In addition to defining the "ni" solution, the procedure also defines a string, "contact.ni" and stores it in the parameter database so it can be accessed later when contact equations are set.

proc BandGapNarrowing { } {
	set Vt300 0.02558
	set ni300 1.1e10
	set Eg300 1.1082
 	set Ebgn 9.0e-3;# eV
 	set Nref 1.0e17;# /cm3

 	solution add name=Eg solve const val=($Eg300+deltaEg)
 	solution add name=ni solve const val=($ni300*exp(deltaEg/(2.0*$Vt300)))
	solution add name=deltaEg  solve const val=($Ebgn*(log((NA+ND)/$Nref)+sqrt((log((NA+ND)/$Nref))^2+0.5)))
	
	#spell it out for the contacts
	set doping 	[pdbGetString ohmic.contact.doping]
	set deltaEg	[expr {$Ebgn*(log($doping/$Nref)+pow((pow((log($doping/$Nref)),2)+0.5),0.5))}]
	puts "deltaEg is $deltaEg"
 	set ni [expr {$ni300*exp($deltaEg/(2.0*$Vt300))}]
 	pdbSetString contact.ni $ni
}