MCC Collision Information

[budjensen]

How feasible would it be to add functionality which allows users to diagnose collision phenomena between plasma species and the MCC background gas? As an example, could we add a buffer of information pertaining to energy lost during collisions, location of the last collision of a specific type, etc.?

In particular, I am interested in looking at heating profiles of the background gas due to collisions with plasma particles and fast ion creation due to charge exchange collisions in the plasma sheath.

Thank you!

[roelof-groenewald]

Hi @budjensen. A collision diagnostic would definitely be nice to have but there are no ongoing efforts I am aware of to code up such diagnostics. What I've done in the past to track energy transfer due to collisions is to use the beforecollisions and aftercollisions callbacks to get the energy in a given species before and after the collisions. You could do this to also see spatially resolved changes in the particle distribution moments and even track the regions where energy transfer mainly occurs. That would give you a general picture of where collisions are occurring but it won't distinguish between different types of collisions. To get similar information for individual collisional processes, we could add functionality that would "deposit" the energy lost or gained during each collision to new multifabs, with a separate multifab for each process. Let us know if you'd be interested in implementing that and we can help you get started.

[roelof-groenewald]

I think any quantity that can be stored as grid values (using the simulation grid) would fit easily into the WarpX structure - basically one would need to create a multifab with the appropriate number of components to store all the desired quantities (I'd imagine a component for each diagnostic). During each collision event, the appropriate value would then be added to that multifab at the appropriate location (cell index).

As a concrete starting point, it would help if you identify two or three diagnostics that would be most useful to you and we can work from there to implement them. It would be helpful to identify the specific value that should be recorded in the buffer for each diagnostic. For example, if tracking number of ionization events is useful, that diagnostic would add 1 to the buffer at the appropriate cell index every time an ionization event occurs.

Creating a new multifab is generally done through the alloc_init function - https://github.com/ECP-WarpX/WarpX/blob/development/Source/ablastr/fields/MultiFabRegister.cpp.
That function takes as input, among other things, the number of components the multifab should have.

At a high level, the steps to implement this diagnostic functionality would be:

1. Create a new multifab with ncomps = # of diagnostics to start with
2. Inside the MCC routine (

   WarpX/Source/Particles/Collision/BackgroundMCC/BackgroundMCCCollision.cpp

   Line 317 in acd1434

   void BackgroundMCCCollision::doBackgroundCollisionsWithinTile

   ) add the appropriate values to the new multifab for each collision.
3. Decide how to process the buffer - this could be just from Python at a specific interval at which the buffer values are reset to 0.

[budjensen]

Great, that sounds perfect. For starters, I'd be happy to implement two diagnostics--one counting ionization events, and one tracking energy transfer due to collisions. Both of these can be processed directly from Python, similar to the particle boundary scraping diagnostics.

For the ionization diagnostic, I would think it best to add the newly created particle's weight, w, to the multifab at the appropriate cell index. For the energy transfer diagnostic, the story would be the same, except that the added quantity would be, w*v2, particle weight multiplied by the difference between final and initial kinetic energy of the particle.

I'll get started on writing this up, and appreciate any other pointers you have. To my knowledge, I'll initialize each multifab in the AllocLevelMFs function (https://github.com/ECP-WarpX/WarpX/blob/acd1434320107b8b18ec377fab4a4313f3da989d/Source/WarpX.cpp#L2079C1-L2082C2) provided that an input option for collision diagnostics is specified.

[budjensen]

Hi @roelof-groenewald, as I've worked on implementing I've ran into a few things:

1. What macroparticle weight is assigned to newly created particles in MCC ionization events? I've traced ionization through BackgroundMCCCollision::doCollisions -> doBackgroundIonization -> filterCopyTransformParticles to ParticleCreation::DefaultInitializeRuntimeAttributes where particle attributes are assigned, but can't find any mention of particle weight.

2. How should I specify a number of guard cells and the nodal_flag parameter in alloc_init()? Is inserting this snippet into the AllocLevelMFs function an appropriate approach?

// Allocate extra multifabs needed for MCC collision tracking
if (do_MCC_collision_tracking) {
    // 2 components:
    // physical particles created, energy transferred in collisions
    int MCC_ncomps = 2;

    // Prepare to initialize a cell-centered MultiFab
    amrex::IntVect MCC_nodal_flag = amrex::IntVect::TheCellVector();

    m_fields.alloc_init(FieldType::MCC_collision_tracker, lev, amrex::convert(ba, MCC_nodal_flag), dm, MCC_ncomps, ngRho, 0.0_rt);
}

[roelof-groenewald]

Hey,

1. The filterCopyTransformParticles functor includes functionality that duplicates the original particle, so the weight of the new particle matches the weight of the original particle. In that functor the velocity of the new particle is modified but the weight does not need modification so it is not mentioned. Thus, the assigned weight will match the weight of the colliding particle.
2. You would not need any ghost cells for this diagnostic since you (correctly) use a cell-centered multifab, and therefore all indices for the new multifab will be valid on a given tile. So as you have it is correct but you can replace ngRho with 0. You might now find it helpful to look at amrex::getParticleCell, which is a function that can return the appropriate index for the multifab given a particle location.

[budjensen]

Thanks for the response. As an amrex/warpx beginner, I greatly appreciate the help.

Below is where I'm at in writing a snippet to insert at line 262 of

WarpX/Source/Particles/Collision/BackgroundMCC/BackgroundMCCCollision.cpp

Lines 459 to 462 in a4d5631

	ux[ip] = vx + ua_x;
	uy[ip] = vy + ua_y;
	uz[ip] = vz + ua_z;
	break;

Here's the snippet:

if (WarpX::do_MCC_collision_tracking) {
    // Calculate difference in energy for tracking
    v_lost2 -= ux[ip]*ux[ip] + uy[ip]*uy[ip] + uz[ip]*uz[ip];
    ParticleUtils::getEnergy(v_lost2, m, E_lost);

    // store the energy (add E_lost * w[ip] to the buffer of energy sent to the background)
    auto & warpx = WarpX::GetInstance();
    amrex::MultiFab &MCC_collision_tracker = *warpx.m_fields.get(FieldType::MCC_collision_tracker, lev);

    // get the cell index
    const auto plo = pti[ip].Geom(lev).ProbLoArray();
    const auto dxi = pti[ip].Geom(lev).InvCellSizeArray();
    const auto [ii, jj, kk] = amrex::getParticleCell(pti[ip], plo, dxi).dim3();

    // store energy lost in the buffer
    MCC_collision_tracker[ii, jj, kk][1] += E_lost * w[ip];
}

I've made some modifications to define w and get lev into the doBackgroundCollisionsWithinTile function, but am pretty confident that I'm handling the WarpXParIter &pti and MultiFab objects incorrectly.

1. To understand necessary inputs for amrex::getParticleCell I looked at where it was used in

   WarpX/Source/Diagnostics/ComputeDiagFunctors/TemperatureFunctor.cpp

   Line 27 in a4d5631

   TemperatureFunctor::operator() (amrex::MultiFab& mf_dst, const int dcomp, const int /*i_buffer*/) const

   and am wondering if pti[ip] acts like a particle container with one particle... Is this the correct approach, or should I modify the inputs of doBackgroundCollisionsWithinTile and pass in the particle container of the colliding species?

2. I haven't found an example of how to modify one element of aMultiFab. Is the last line in my snippet appropriate?

Thank you!