WarpX
WarpX copied to clipboard
ECP-WarpX
Add External Fields from Data File
@RemiLehe @ax3l Now, the loaded external field (1st plot) looks different from the provided external field (2nd plot). I'm stuck at debugging. Maybe you guys can help when reviewing this PR.
What is the reason that this requires creating new multifabs, Efield_fp_external and Bfield_fp_external instead of using E/Bfield_fp, E/Bfield_aux and E/Bfield_cp as is currently done with input like Ex_external_grid_function(x,y,z)? Basically I'm asking if there is a reason that the 'read external field from a data file' cannot be treated exactly like the parsed input parameter Ex_external_grid_function(x,y,z) (obviously with adding the read and interpolate functionality to WarpXInitData)?
What is the reason that this requires creating new multifabs,
Efield_fp_externalandBfield_fp_externalinstead of usingE/Bfield_fp,E/Bfield_auxandE/Bfield_cpas is currently done with input likeEx_external_grid_function(x,y,z)? Basically I'm asking if there is a reason that the 'read external field from a data file' cannot be treated exactly like the parsed input parameterEx_external_grid_function(x,y,z)(obviously with adding the read and interpolate functionality toWarpXInitData)?
Hi @roelof-groenewald, thanks for looking at this PR and asking this question. The reason we cannot easily use the existing (E/Bfield_fp, E/Bfield_aux and E/Bfield_cp) field arrays is that we have to make sure the external field data satisfy the Maxwell equation very well as well as the boundary conditions. If we want the external field data to be a bit more flexible, we would like to add them during the gather phase rather than adding to the existing field arrays in the code.
@RemiLehe Please add more comments if needed here.
Now, the loaded external field (1st plot) looks different from the provided external field (2nd plot). I'm stuck at debugging. Maybe you guys can help when reviewing this PR.
I would try these things:
- plot also the other slices of the simulation
- try to invert the read (or write) indices
Record a working test!
constant_B.txt This (Jupyter Notebook) python script generates a constant Bz field and other zero fields into txt files. Then, this version of the PR will read those txt files as external fields.
The WarpX input file is:
input_constant_B.txt
Compile using:
cmake -S . -B build -DWarpX_EXTERNAL_FIELD=TRUE -DWarpX_openpmd_branch=0.14.5 -DWarpX_DIMS=3
cmake --build build -j 4
Then, the above constant_B.txt script can be used again to read the outputted diags data and plot the particle trajectory, as shown below.
Record a working test in RZ!
constant_B_rz.txt This (Jupyter Notebook) python script generates a constant Bz field and other zero fields into txt files. Then, this version of the PR (Make rz workiong: 03c3d00) will read those txt files as external fields.
The WarpX input file is:
input_constant_B_rz.txt
Compile using:
cmake -S . -B build -DWarpX_EXTERNAL_FIELD=TRUE -DWarpX_openpmd_branch=0.14.5 -DWarpX_DIMS=RZ
cmake --build build -j 4
Then, the above constant_B_rz.txt script can be used again to read the outputted diags data and plot the particle trajectory, as shown below.
Record a working test in XZ!
constant_B_xz.txt This (Jupyter Notebook) python script generates a constant By field and other zero fields into txt files. Then, this version of the PR (Make xz workiong: 5db4e86) will read those txt files as external fields.
The WarpX input file is:
input_constant_B_xz.txt
Compile using:
cmake -S . -B build -DWarpX_EXTERNAL_FIELD=TRUE -DWarpX_openpmd_branch=0.14.5 -DWarpX_DIMS=2
cmake --build build -j 4
Then, the above constant_B_xz.txt script can be used again to read the outputted diags data and plot the particle trajectory, as shown below.
Record a working test in 1D!
constant_E_z.txt This (Jupyter Notebook) python script generates a constant Ez field and other zero fields into txt files. Then, this version of the PR (Make 1d work: 774e591) will read those txt files as external fields.
The WarpX input file is:
input_constant_E_z.txt
Compile using:
cmake -S . -B build -DWarpX_EXTERNAL_FIELD=TRUE -DWarpX_openpmd_branch=0.14.5 -DWarpX_DIMS=1
cmake --build build -j 4
Then, the above constant_E_z.txt script can be used again to read the outputted diags data and plot the particle trajectory (z vs time step), as shown below.
Tested a more complicated 3D scenario: magnetic mirror effect.
-
A 2D RZ magnetic mirror field is generated by the FEMM software. The field is shown as this figure.
Then, the 3D Bx, By, Bz fields are saved using a Lua script into txt files named B0.txt,B1.txt,B2.txt. CorrespondingE0.txt,E1.txt,E2.txt(same size and format asBfiles) are generated manually with all zeros. An information file is also generated by the Lua script namedinfo.txt, indicating the number of grid points, the cell sizes, and the minimal x,y,z values of the external field domain. The FEMM file and the Lua script are posted here in thisFEMM.zip. FEMM.zip -
Then, a corresponding WarpX input file is generated and given here, which contains only one test particle. input.txt
-
WarpX (the current version of this PR) can be compiled using:
cmake -S . -B build -DWarpX_EXTERNAL_FIELD=TRUE -DWarpX_openpmd_branch=0.14.5 -DWarpX_DIMS=3cmake --build build -j 4 -
The output can be read by a python script: read.txt
-
The result makes sense, as a particle can be reflected by the magnetic mirror.
Now, the mirror 3D test is applied using OpenPMD.
openpmd_create.txt reads the previous B*.txt and E*.txt txt data files and converts them into OpenPMD format file openpmd_data.h5.
B0.txt B1.txt B2.txt E0.txt E1.txt E2.txt
WarpX can be compiled using:
cmake -S . -B build -DWarpX_EXTERNAL_FIELD=TRUE -DWarpX_openpmd_branch=0.14.5 -DWarpX_DIMS=3
cmake --build build -j 4
The input file is input.txt.
The results can be read and plotted using read.txt.
This pull request introduces 3 alerts when merging b32e6efdd766f5986d66b213479d7c84587fca7e into 4f88c5b85e6de10ea51c3bd146f5ba5aaa6d5cec - view on LGTM.com
new alerts:
- 3 for Unsigned comparison to zero
![lgtm-com[bot] avatar](https://avatars.githubusercontent.com/in/17324?v=4 "Published by a pub.dev verified publisher"){kind=small}
This pull request introduces 4 alerts when merging c21244d103e3eb245ebb1d3b9d2c4b016afd8671 into ee837089bf2264feb412e6351c22658dfe7599d2 - view on LGTM.com
new alerts:
- 4 for Unused import
This pull request introduces 5 alerts when merging caf213cdff02213cf0ff7389b399898bc76951b5 into 642f6c0f4ea5a524e6f73f2123aebbdef70c94fd - view on LGTM.com
new alerts:
- 5 for Unused import
This pull request introduces 4 alerts when merging a96a3eb3a181d6e1a649a43bc9eb2e00e4e0ef57 into 642f6c0f4ea5a524e6f73f2123aebbdef70c94fd - view on LGTM.com
new alerts:
- 4 for Unused import
This pull request introduces 4 alerts when merging 3394416cc0f7dc1e4742249b469957bedbfd5e84 into 4876446dff60411cbdd4892a044643f5fcc9dd00 - view on LGTM.com
new alerts:
- 4 for Unused import
This pull request introduces 4 alerts when merging 5452b0a818e952fc8ac989a306b0ea83738243f1 into 90b72e804c96eea345896125b7eb7d3c3272711b - view on LGTM.com
new alerts:
- 4 for Unused import
This pull request introduces 4 alerts when merging 2ff7eafd1ccf0aef287401fa2675cc51285dd518 into 5d635b996feff9fac6065930df7b87b83cceb311 - view on LGTM.com
new alerts:
- 4 for Unused import
Heads-up: LGTM.com's PR analysis will be disabled on the 5th of December, and LGTM.com will be shut down ⏻ completely on the 16th of December 2022. Please enable GitHub code scanning, which uses the same CodeQL engine :gear: that powers LGTM.com. For more information, please check out our post on the GitHub blog.
After discussion with @Yin-YinjianZhao, the current status is that the code is almost ready. We just need to:
- fix CI
- implement/test for GPU
It seems a little bit odd to me to push a distinction between internal and external fields all the way down to the particle containers, and make them consider those. I'll look further, but naively, it seems like the fields should be summed outside any particle container, and the particles should only see the summed effective field. Is there a use case for some particles to be influenced by an external field, and others not?
Given my current contract tasking, I may be able to pick up work on this from @Yin-YinjianZhao entirely, if that would be preferable.
Just to update - I will be getting this refactored and cleaned up ASAP as part of a contracted project