Skip to content

Conversation

@lucafedeli88
Copy link
Member

@lucafedeli88 lucafedeli88 commented Nov 27, 2025

Summary

This PR is the second step of a long-overdue process: the integration of picsar_qed into ablastr. Specifically, this PR moves the Schwinger pair production process into ablastr/sfqed and makes the necessary changes in the rest of the code . In addition, some details on the Schwinger process are added to the documentation.

The code is adapted from PICSAR QED, with minor changes.

Main changes:

  • Calculations for the Schwinger process are performed using amrex::Real and amrex::RealVectND<3> types.

  • Source/ablastr/sfqed/SchwingerProcess.H : this new source file contains the methods that compute the pair production rate

  • Source/ablastr/sfqed/UnitConversion.H : QED-related calculations are performed internally using the Heaviside-Lorentz units. This new file contains helper functions to convert quantities between these units and SI units.

  • Source/Particles/ElementaryProcess/QEDInternals/SchwingerProcessWrapper.H : this file is no-longer needed. The only one method that was implemented there is now in ablastr/sfqed/SchwingerProcess.H .

  • Source/Particles/ElementaryProcess/QEDSchwingerProcess.H : in this file a simple name change to call the new method in ablastr instead of the one in the wrapper is performed.

  • Source/Particles/MultiParticleContainer.H/cpp : the Schwinger process no longer requires the PICSAR QED library. Therefore, the relevant code is moved out of the #ifdef WARPX_QED ... #endif sections.

  • Source/Evolve\WarpXEvolve.cpp : same as above

  • Docs/source/usage/parameters.rst : the documentation is updated to reflect that the Schwinger process no longer requires the PICSAR QED library.

  • Docs/source/theory/multiphysics/qed.rst : some details on the physics of the Schwinger process are added to the documentation.

  • Docs/source/refs.bib a reference to a paper cited in Docs/source/theory/multiphysics/qed.rst is added.

  • Regression/Checksum/benchmarks_json/test_3d_qed_schwinger_4.json : I had to reset the checksum, but the change is really tiny (and the python script passes) .

@lucafedeli88 lucafedeli88 added cleaning Clean code, improve readability component: QED QED module component: PICSAR PICSAR specific changes labels Nov 27, 2025
@lucafedeli88 lucafedeli88 changed the title [WIP] Integrate picsar_qed in ablastr : move in the Schwinger process Integrate picsar_qed in ablastr : move in the Schwinger process Nov 27, 2025
@lucafedeli88 lucafedeli88 changed the title Integrate picsar_qed in ablastr : move in the Schwinger process [WIP] Integrate picsar_qed in ablastr : move in the Schwinger process Nov 27, 2025
@lucafedeli88 lucafedeli88 changed the title [WIP] Integrate picsar_qed in ablastr : move in the Schwinger process Integrate picsar_qed in ablastr : move in the Schwinger process Nov 28, 2025
@ax3l ax3l self-requested a review December 2, 2025 23:37
@ax3l ax3l added the component: ABLASTR components shared with other PIC codes label Dec 2, 2025
Copy link
Member

@aeriforme aeriforme left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Merging PR6385 first could be helpful

doQEDEvents();
mypc->doQEDSchwinger();
#endif
mypc->doQEDSchwinger();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this?
I think it makes sense that the Schwinger effect can only be used when compiling with QED ON, no?
Even if it's not technically essential...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have to discuss this.
In principle, if we integrate picsar QED into ablastr, we could enable QED effects at no cost (no additional libraries). We could have a compilation flag only for lookup tables generation (this feature requires the boost library).
Since I see this PR as a step towards the full integration of picsar QED in ablastr it seemed reasonable to me to start putting stuff that can be used without picsar out of the #ifdef regions. However, this change can be certainly delayed till the end of the integration.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh I see! We shall discuss at the developers meeting then.
I'll add it to the agenda.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above, I don't see why we would prefer this.



void
MultiParticleContainer::doQEDSchwinger ()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why doesn't this code belong to ablastr?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, shall we add doxygen?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that it is a bit too WarpX - specific to be in ablastr. Would you suggest moving the whole function to ablastr? Adding a doxygen comment is certainly a good idea.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I've noticed that the doxygen statement is in the MultiParticleContainer.H header file:

    /** If Schwinger process is activated, this function is called at every
     * timestep in Evolve and is used to create Schwinger electron-positron pairs.
     * Within this function we loop over all cells to calculate the number of
     * created physical pairs. If this number is higher than 0, we create a single
     * particle per species in this cell, with a weight corresponding to the number of physical
     * particles.
     */
    void doQEDSchwinger ();

Looking again at the code, I still think that it is a bit too warpx-specific to be in ablastr...

add_subdirectory(parallelization)
#add_subdirectory(particles)
#add_subdirectory(profiler)
add_subdirectory(qed)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we maybe call it sfqed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, that's a good idea. I'll do that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

convert_from_to<unit_system::heaviside_lorentz, UnitSystem, quantity::rate>(1.0_rt);

constexpr auto pi = ablastr::constant::math::pi;
if(epsi != 0.0_rt && eta != 0.0_rt){

Check notice

Code scanning / CodeQL

Equality test on floating-point values Note

Equality checks on floating point values can yield unexpected results.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's OK here. It protects against a corner case replacing an expression that would give a NaN with a valid expression obtained by computing the limits eta -> 0 or epsi -> 0.

convert_from_to<unit_system::heaviside_lorentz, UnitSystem, quantity::rate>(1.0_rt);

constexpr auto pi = ablastr::constant::math::pi;
if(epsi != 0.0_rt && eta != 0.0_rt){

Check notice

Code scanning / CodeQL

Equality test on floating-point values Note

Equality checks on floating point values can yield unexpected results.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as above

if(epsi != 0.0_rt && eta != 0.0_rt){
return coeff*rate_conv*epsi*eta*std::exp(-pi/epsi)/std::tanh(pi*eta/epsi);
}
else if(epsi == 0.0_rt){

Check notice

Code scanning / CodeQL

Equality test on floating-point values Note

Equality checks on floating point values can yield unexpected results.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as above

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cleaning Clean code, improve readability component: ABLASTR components shared with other PIC codes component: PICSAR PICSAR specific changes component: QED QED module

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants