Picongpu: Species setup: ionization and creation

[cbontoiu]

I try to understand how the ionization models are used in PIConGPU. My reasoning is that if for a Carbon atom the first ionization energy is 11.2603 eV (corresponding to 110.11 nm) a wavelength of 120 nm should yield no ionization but in fact I see how the electrons appear as soon as the laser reaches the Carbon atoms. This means I need to limit the available ionization mechanisms probably to ADKLinPol or ADKCircPol. I am right here?

If I use the following code in speciesDefinition.param for a Carbon atom

ionizers<
        MakeSeq_t<
            particles::ionization::BSIEffectiveZ< Electrons >,
            particles::ionization::ADKLinPol< Electrons >,
            particles::ionization::ADKCircPol< Electrons >,
            particles::ionization::ThomasFermi< Electrons >
        >
>

is it true that all four mechanisms are activated and likely to occur in a suitable laser field? I understand that the last model enables ionization by collision with electrons. Is it correct to specify both ADKLinPol and ADKCircPol reasoning that the one chosen will depend on the type of polarization written in the laser.param file?

[sbastrakov]

Concerning the technical part: yes, it means all the listed models will be used. For the physics part, I can't answer, perhaps @n01r , @steindev or @PrometheusPi have an idea?

[n01r]

Hi @cbontoiu, thanks for your question!
So far, the ionization models that are implemented, are limited to field ionization in the so-called quasi-static regime and collisional ionization in a statistical Thomas-Fermi approach.
The former means that we assume to be in a regime where the changes of the external electric field, introduced by the laser pulse, are much slower compared to the inner atomic time-scales. At the same time, coming from the fact that particle-in-cell codes are working best (as in physically correct) in a collisionless plasma which is created by the ultra-high intensity infrared lasers used in laser-particle acceleration, the single-photon energy can usually be neglected for ionization processes. Instead, ionization for the physics we usually look at is caused by skewing the atomic potential to a point that an electron can either leave classically (barrier suppression models: BSI, ...) or tunnel through the barrier (tunneling models: ADK, ...).

To consider just the photon wavelength is not sufficient since the intensity of the laser light also determines which process of ionization is dominant. What type of laser would you like to model?

For moderate laser intensities of around 10^12-10^14 W/cm² and photon energies close to the ionization energy, single- and multi-photon ionization processes are much more dominant than the quasi-static ionization processes we have implemented. If you would like to operate with a 120nm laser and maximum intensities in this regime, you should take the results the code gives you with a large grain of salt.
The tested range of intensities for PIConGPU starts at roughly 10^17 W/cm² and the wavelengths we have been using are typically at 800nm or 1000nm.
At much lower peak intensity and shorter wavelengths, more atomic physics that are not part of the original PIC cycle (and would, therefore, need to be implemented on top) have to be considered for accurate results. A multi-photon ionization model would have to be implemented as well.
Nevertheless, depending on the question that you are asking of the simulation, approximates of the electronic states and free electrons in the problem could maybe be implemented as an initial condition and you may still observe collective electron motion if that is what you are interested in.

For the technical part:
A combination of the ADKLinPol and ADKCircPol is not necessary. Unfortunately, the choice is still made manually, depending on what polarization type your laser has or on which time scales your interaction is taking place.
I implemented the naming of the models as they are introduced in the paper of Delone and Krainov from 1998 (see links leading to the documentation of our code and references above in my answer).
That being said, it would be more accurate to call them ADKAveraged and ADKInstantaneous, since the authors of the paper arrive at the former just by a process of averaging the latter over a laser wavelength under linear polarization conditions. If you are interested in sub-wavelength ionization physics in the quasi-static regime, almost always the ADKCircPol implementation is your candidate of choice. Checking for BSI before and, for solid density targets, adding the ThomasFermi model is usually the way to go.

Be careful with the ThomasFermi model, though. If I remember right, you would like to look at Carbon nanotubes. The Thomas-Fermi model depends on electron temperature and ion density. It is unclear how the model performs with metamaterials like CNTs. The simple approach of the implemented model is to calculate an overlap of ionic potential wells and an electron gas that statistically collides with bound electrons. That works fine in a 3D volume completely filled with a solid density material. A 2D material might exhibit completely different pressure ionization properties and since electromagnetic fields from a laser should be able to reach every atom, more or less, field ionization could be so dominant that the ThomasFermi model should better be left out. Perhaps it does not apply to the situation very well. :)

Alright, sorry about the book I just wrote ^^. If you give us more details on the exact scenario we might be able to figure out a suitable solution together.

[cbontoiu]

Hi Marco,

Great answer! Thank you very much! I will study these ionization models in details. At this stage, the laser we want to use is not really defined. I think it must be in the UV region to couple to the 10 nm tubes diameter. As for the intensity level what we want is only to generate ripples in the electron shells made by the 6th Carbon electron which virtually roams freely. We then investigate how generate a standing pattern of this ripples with a train of laser pulses and what is the amplitude of their wakefields. Carbon nano tubes have densities of ~1e29 atoms/m^3 which shows a potential greater than that of gases for wakefield acceleration and finding how to exploit them is the main goal of my research.

We want to avoid the ionization and the damage of the tubes and it is important to know the power-wavelength threshold which should not be exceeded. From what you say I understand that ADKCircPol might not be reliable for low intensities.

The 120 nm was chosen on the fact the the first ionization energy (single photon know-out) corresponds to 110 nm, but my A0 factor was 0.5 adjusted directly in the ThinFoil PIConGPU example, so plane wave laser. What I would try now is to drop this A0 factor until there is virtually no ionization, because the model contains only Carbon atoms and ionization is visible as soon as electrons appear in the simulation.

Anyway, my model would need actually C+ ions and free electrons such that I can test if a laser can drive ripples of electron density along the tube. So a new ionization model for carbon nano tubes would not be required since one can consider them ionized already at the first level.

Kind Regards,
I will follow your work.

Cristian

[n01r]

Right, perhaps it is best to look directly at the effect you want to observe and make the initial conditions simple enough to get to a result quickly. Making the ions immobile and ionizing the first electron off each Carbon atom makes sense. One can then disable ionization altogether and try to see the ripples you expect/hope to see. From there you could make the setup more complex and try to see how realistic you can possibly get.
That seems much better than trying to get there by plugging in and prototyping a lot of physics that is usually outside of the normal PIC capabilities and would require lots of testing themselves.

[sbastrakov]

Btw @cbontoiu in case you feel some other questions are resolved for the moment, please feel free to close them as well. We sometimes are not sure whether the question is resolved, or maybe the plans changed and it is no longer relevant, or the question requires further assistance and there was just no time to work on that further (yet).

[cbontoiu]

Thanks. I will review my questions and close those which have clear answers. Meanwhile looking at the code below, please confirm that I am creating a free electron for each C+ ion. I am not sure:
1) if the last functor ManipulateDerive is necessary
2) if the first ManipulateDerive is necessary (now commented)

namespace particles
{
using InitPipeline = bmpl::vector<
    CreateDensity<
        densityProfiles::XYTubes,
        startPosition::Random6ppc,
        Carbon
    >,
    /* derive the other two ion species and adjust their weighting to have always all
    * three of macro ions present in a cell, even in cut-off regions of the density profile */
    //ManipulateDerive<
    //    manipulators::binary::DensityWeighting,
    //    Carbon,
    //    Electrons
    //>,
    // randomize C in-cell
    Manipulate<
        manipulators::unary::RandomPosition,
        Carbon
    >,
    // partial pre-ionization: set bound electrons for C+
    Manipulate<
       manipulators::OnceIonized,
       Carbon
    >,
    // partial pre-ionization: create free electrons
    Derive<
        Carbon,
        Electrons
    >,
    ManipulateDerive<
        manipulators::binary::UnboundElectronsTimesWeighting,
        Carbon,
        Electrons
    >
>;
} // namespace particles 

[n01r]

Looks good as it is!
The commented part is indeed not necessary and everything that is necessary is there. :+1:

Edit: Sorry, looked too quickly. Actually, you're right, either the Derive before the last ManipulateDerive is too much, or the last ManipulateDerive can go away. But in case you ever want to change the ionization state of the Carbon ions with your manipulator before, I would just say that you should remove the Derive because it copies the weighting of the Carbon atoms to the Electrons and does not adjust the weighting for ionization state.

Just a question on the side: are you intentionally randomizing the in-cell position to have some natural disorder in there or did you want a very specific position, even inside the cells to reflect your structure?

P.S.: @cbontoiu Don't worry that it says that I edited your comment. I just fixed the Markdown syntax highlighting for you.

[cbontoiu]

Looks good as it is!
The commented part is indeed not necessary and everything that is necessary is there. +1

Just a question on the side: are you intentionally randomizing the in-cell position to have some natural disorder in there or did you want a very specific position, even inside the cells to reflect your structure?

P.S.: @cbontoiu Don't worry that it says that I edited your comment. I just fixed the Markdown syntax highlighting for you.

Thanks so much for the reply. Actually I tried formatting the text myself but I couldn't make it look so nice as you did. The randomizing part is inherited from the thin foil example and I thought is necessary, but actually since the structure is very ordered anyway, I can remove it. For the moment I only know how to create density shells but the next approach would be to use discrete atom-electron pairs distributed in 3D arrays. Regards.

[n01r]

Hey @cbontoiu, I edited my comment above - you were right, there is one manipulator too much.

[n01r]

Actually I tried formatting the text myself but I couldn't make it look so nice as you did.

You used single backticks for the code - you can do that if the code is inline. If you have line breaks in there, you need to put triple backticks before and after the code block.

You can then write a language name after the first triple backticks to activate specific syntax highlighting. :v:
```C++

... \< code > ...

```

[sbastrakov]

About formatting: it is as @n01r pointed out. Btw in case one wants to "copy" the formatting of another message but unsure how to reproduce it, could click "edit" on the message to see how it looks raw in markdown - this is often quicker than figuring it out or googling.

[n01r]

could click "edit" on the message

That only works if you're at least a maintainer of the repository ^^

[cbontoiu]

OK, I went the other way around. That is generating electrons first and then a carbon C+ ion for each electron. It is more convenient like this because there is C++ value_identifier( float_X, DensityRatioCarbon, 1. / 1. ); and C++ densityRatio< DensityRatioCarbon >, in speciesDefinition. param so now the code looks like this:

```C++ using InitPipeline = bmpl::vector<
CreateDensity< densityProfiles::XYTubes, startPosition::Random6ppc, Electrons >,
ManipulateDerive< manipulators::binary::DensityWeighting, Electrons, Carbon >,
Manipulate< manipulators::OnceIonized, Carbon >,
//ManipulateDerive< manipulators::binary::UnboundElectronsTimesWeighting, Carbon, Electrons >,
CreateDensity< densityProfiles::ProbeEveryFourthCell, startPosition::OnePosition, Probes >

;
```
Is this still correct, please?

[n01r]

Looks correct to me, however, I disagree with the statement that it is more convenient.
The densityRatio is only ever used in CreateDensity and ManipulateDerive< manipulators::binary::DensityWeighting, ...>.
By creating the electrons first, you would not be able to adjust their weighting by simply changing the charge state manipulator of the Carbon ions (if you were interested in playing with that).
Cloning the electrons once from the ions by using Derive copies their weighting. Doing that after using the OnceIonized manipulator on the Carbon ions would make this a valid setup.
Please note, here the densityRatio of the electrons plays no role at all. Of course you need to make sure that the densityRatio of the Carbon ions multiplied with the BASE_DENSITY you configured in density.param needs to yield the density value that you wanted to configure.
If you replaced the Derive with ManipulateDerive< ... UnboundElectrons...> you can manipulate the ion charge state at will and still get the correct weighting for the electrons.
Important here: despite multiple preionization the PIC code still requires quasi-neutrality at the beginning of the simulation, meaning you need to co-locate the electrons on the ions. Multiple electrons of the same weighting and at the same position can simply be expressed by one electron of higher weighting, since they would never change have a different trajectory, as long as there are no modules active that change electron number or do Monte-Carlo operations on the electrons that affect their momenta and for which different results could appear.
Now, with the setup you chose you would have to make sure that the electrons always have a densityRatio that matches the ionization state of the carbons. That makes bookkeeping harder since you need to remember setting this up in a different file rather than doing all of it in speciesInitialization.param.