normal & umklapp processes

[matukumilli]

Dear developers,

A feature to output N and U processes separately can be added, for which I tried to locate the momentum conservation checks in the code. At first attempt it is difficult to me to follow the code, can I get some help on this?

Regards,
Prasad

[jcoulter12]

Hi Prasad,

I think it should not be too hard for me to add this.

To first make sure I understand exactly what you want -- I presume you're interested in this option for phonon processes? Are you looking for the lifetimes/linewidths broken down into U and N processes (the diagonal of the scattering matrix, or what is used in the RTA), and perhaps the RTA transport properties?

Development-wise, the easiest thing for me to do would be to add an input file flag for outputting N and U process contributions for the linewidth calculation and RTA transport properties. This would have a relatively small memory footprint, because the linewidth object is just a vector of length nStates.

If you want to instead do something like calculate transport properties with the full scattering matrix, having restricted to either U or N processes, it's slightly more complicated, but still probably doable.

Thanks for the feature request, let me know the answer to this question.
Jenny

[matukumilli]

Hi Jenny,

I want to establish the dominance of N phonon processes over U processes (by plotting tau_U and tau_N vs T) at the temperature region where k_variational deviates significantly from k_RTA. I thought separation of U and N processes is only possible at RTA level. As in exact solution the physical picture of phonon scattering involves the coexistence of both the N & U processes, it is difficult to me to understand what such separated processes in exact solution would physically represent.

Any further thoughts on this from you would be helpful.

Regards,
Prasad

[jcoulter12]

Hi Prasad,

Ok, that works -- doing this in RTA is not too hard to do, and hopefully I'll have something for you to use in the next couple days.

I think your confusion is coming from the idea of the definition of lifetimes/linewidths vs scattering processes.

Any scattering processes used to construct the full scattering matrix is defined by 3 q vectors and could be considered Umklapp or Normal. The definition of U vs N depends solely on the q vectors used for the scattering process.
https://phoebe.readthedocs.io/en/develop/theory/phononBTE.html#phonon-scattering-rates

There's no reason the set of scattering rates used to construct the full scattering matrix cannot be categorized this way as well. The full scattering matrix could be separated into Omega_full = Omega_N + Omega_U.

The relaxation times/lifetimes are a construct of the RTA. The RTA pretends that only the diagonal of the scattering matrix is meaningful, and calls 1/the diagonal of the scattering matrix "lifetimes". They represent an incomplete picture of scattering rates in a system, which is why exact BTE solvers are needed.

Best,
Jenny

[matukumilli]

Hi Jenny,

Thanks. It would be nice to have N/U contributions from full solution and to have a comparison between tau_N-proc_RTA and tau_N-proc_full. I look forward for any feature development for this purpose.

Regards,
Prasad

[jcoulter12]

Hi Prasad,

Sorry for a little wait -- I did finally get around to adding this for phonon transport.
If in your Phoebe directory, you run:

git pull
git checkout outputUN
cd build
make phoebe

This will pull down a new branch and rebuild the code. You should then be able to run the phononTransport app with an additional variable outputUNTimes = true.

This will output the Umklapp and Normal relaxation times to rta_ph_relaxation_times.json. From there, they can be read into python with:

with open("rta_ph_relaxation_times.json") as jfile:
        data = json.load(jfile)
tau = np.array(data['umklappRelaxationTimes'])

On the outputUN branch, there is also a python script called compare_UN_times.py under phoebe/scripts/plotScripts/ that will plot the U and N proceses vs. phonon energy.

Additional notes on this feature:

• This will only happen if you run a RTA calculation.
• Additionally, if you leave isotope scattering turned on (the default) that scattering will also be included in the U vs. N categorization.
• You should think carefully about if you want to use a filtering window when calculating these states. This will discard states which are not relevant to transport at a given temperature. Removing states which don't participate in scattering may be more interesting, but it depends on your application.

---

Other notes regarding the earlier messages:

It would be nice to have N/U contributions from full solution and to have a comparison between tau_N-proc_RTA and tau_N-proc_full.

I think you might have missed my meaning in the last message, sorry for not realizing this earlier. I think you might want to do a bit more background reading on BTE calculations with the full scattering matrix -- I can send you a reference to read beyond the Phoebe manuscript, if it's helpful.

tau_N-proc_RTA and tau_N-proc_full

This wouldn't be possible because tau is a relaxation time, which has only 1 state index (q,mode) -- it tells you about scattering "out" of a given state. These are the matrix elements along the diagonal of the scattering matrix.

In the above message, I mention that the off-diagonal processes can also be U or N processes. However, you can't plot these in the same straightforward way, as they tell you about scattering from one state (q,mode) to some other state, (q',mode'). You can see the definitions of the scattering rates, which are used to fill in all states in the scattering matrix, here. Note, that these rates P are summed over one index when they are used here to fill in the scattering matrix.

I've only implemented this for the RTA contribution to the scattering matrix for now, because it would would require bigger changes to Phoebe. I'd have to keep three copies of the scattering matrix in memory (which would be computationally terrible), or would have to allow U, N or U+N to be chosen in the input file, then Phoebe would have to be run three times to get the three separate results. If there's a very good reason for this, let me know and I will evaluate and let you know if I can do this.

Thanks for using Phoebe, let me know if something doesn't work with this or you have another question!
Jenny

[matukumilli]

Dear Jenny,
Thank you very much for this feature addition.

I have tried using it, but to me it just outputs null values, attached here are the relevant files. I request you to have a look.
outputUNtimes.zip

Regards,
Prasad

[jcoulter12]

Hi Prasad,

Do you mean the scattering matrix calculation is slower that it used to be somehow?

Overall, the calculation of the scattering matrix is a very heavy computation. This is not related to the way Phoebe does things, it's just the nature of the problem, as the calculation of that matrix scales as nstates^2 rather than RTA's nstates.
To my knowledge, we're as fast as or faster than existing codes that do this calculation.

Jenny

[jcoulter12]

A second note to speed things up, based on your last input file:

windowType = nothing --> when running a scattering matrix calculation for transport, as you're at a low temperature, I would set this to "population"
useSymmetries = false --> true can be a big speedup
dimensionality = 3 --> 2, looks like you have a 2d material here?

[matukumilli]

I mean with scatteringMatrixInMemory = false scattering matrix calculation is clearly slower at qMesh = [40, 40, 1] which is expected.

Yes, overall it is certainly faster in phoebe.

Regards,
Prasad

[matukumilli]

A second note to speed things up, based on your last input file:

windowType = nothing --> when running a scattering matrix calculation for transport, as you're at a low temperature, I would set this to "population" useSymmetries = false --> true can be a big speedup dimensionality = 3 --> 2, looks like you have a 2d material here?

Yes, I will use these settings. Thanks!

Regards,
Prasad

[jcoulter12]

Ahh, thanks for clarifying. Yes, that can make things a bit slower, that's a good point.
Let me know if it becomes a big problem at any point and I can change things so that U and N are output when scatteringMatrixInMemory = true as well.

Best,
Jenny