Relativistic field initialization (solve poisson) in transverse direction #318
Comments
|
Before the explanation for the modifications, some recommendations:
As can you see from the documentation https://smileipic.github.io/Smilei/relativistic_fields_initialization.html, the difference between a relativistic Poisson solver for a species moving along x or y is the presence of an average gamma squared in the operations associated to the desired direction. For a motion along x, this gamma squared is below the x derivatives in Eq. 62: Thus, to modify the solver to take into account instead a motion along y, that gamma squared must be moved from the x derivatives to the y derivatives in those equations, and change the unit vector x in the final vector product, from x to y. Eq. 62, or relativistic Poisson's equation, is solved with a conjugate gradient method (look at the section "The resulting algorithm" in https://en.wikipedia.org/wiki/Conjugate_gradient_method). The term Ap of that scheme is computed In the same file, you can find the mentioned calculation of E from Phi in Finally, in the same file you can find the calculation of B from E in To start, try to make these modifications, do not hesitate to contact us here if you have questions, I hope the explanation was clear. You may have to change the boundary conditions in the Poisson solver in |
|
I changed the first two parts to this (haven't changed the boundary condition though): void ElectroMagn2D::compute_Ap_relativistic_Poisson( Patch *patch, double gamma_mean ) void ElectroMagn2D::initE_relativistic_Poisson( Patch *patch, double gamma_mean ) However, I don't know what to do with B field initialization. In the original script there doesn't seem to be a By field (which should exist by beta0*(x cross E), which I'm not sure why. Also I realized whether it's possible to let the laser propagate in the y direction and the electron will then flow in the X direction (then it would be a 90 degree rotation of my problem). This way I don't really need the modification anymore. Thanks |
|
Your modifications seem ok. With a solver for a motion along x, the vector product B = beta0 x E gives Bx=0, By = -betaEz, Bz = betaEy, that's why Bx does not exist. However, Ez = - \partial_z Phi, which in 2D is not defined (there are no variations along z), so also By=0. For a solver for a motion along y, you would have Bx = betaEz, By=0, Bx = -betaEx. In this case, since Ez = - \partial_z Phi = 0 as before, so also Bx = 0. Anyway, as you say if your laser propagates along y you can make the electrons flow along X and you don't need a modified solver. I'll close the issue then, feel free to reopen it if in the future you will need again a modified solver. |
|
This is what I have for B field. However, I'm not really sure about the initial field 2D, and I'm not sure whether the Bz loop i<nx_p, j<ny_d indices needs change for beta0*Ex. void ElectroMagn2D::initB_relativistic_Poisson( Patch *patch, double gamma_mean ) } // initB_relativistic_Poisson |
|
I see your Bx = 0, By = 0, Bz = -betaEx as it should be. Now, remember the entering of these fields in the Yee scheme to solve the electromagnetic fields: Ex is dual, primal (d,p), while Bz is dual, dual (d,d). This means that the indices in the loop must go from 0 to nx_d for i, and from 0 to ny_p, to follow the entering of the Ex field that you are putting inside Bz. Afterwards, in Sure, for the first tests you can try to use a very large simulation box to avoid border effects and see if it is ok for your simulations. |
|
Do you mean by changing this section (other sections remain the same) in "center_fields_from_relativistic_Poisson"? That's all that is required for poisson solver right? Thanks // Bz (d,d) - remember that Bzrel is centered as Eyrel (p,d) |
|
Yes, for a solver with an x motion you had Bz = betaEy, but for a y motion Bz = -betaEx, so that comment in the code you reported does not apply, it should be instead Your modifications should be correct. |
|
The compile fails when linking smilei due to multiple definition. (I think I could also try to modify the boundary condition first and then compile, since the compilation process could be long and problematic) Linking smilei |
|
Each time you modified a method used by the Poisson solver, you created a new method with the same name of the old one? This could cause the multiple definition error. PS as it was written in the link I sent you on Element, for compiling issues normally please provide us details of your environment, i.e. the result of the commands below. In this case, maybe it's just a problem of creating a homonym method. |
|
Do you mean changing the name of the modified function could avoid this problem? (I'm not very sure about what creating a homonym method means) The compilation is fine until linking smilei. Thanks |
|
Creating a homonym method means that you created two functions with the same name and input arguments, so the compiler cannot know which one is the "true" one. First, try to download smilei in another folder, without modifying it and see if it compiles and runs correctly. If it doesn't, please provide us details on your system configuration, as stated in my previous answer, and these compilation problems should be addressed before modifying the solver. If without modifications the code compiles and runs correctly, I see two recommended steps:
|
|
The compilation was fine without modification. I did replace the old function with the new one (like method 1) but the compilation for the new one shows the multiple definition error. I wonder if I need to change other files too to make the modification. |
|
So if without modification it compiles, there's something to fix in your implementation. I suggest to take the original code without modifications, the version that compiles. Starting from there, gradually put your modifications in the place of the corresponding original parts of the solver, by small steps (like few lines of code, or just one block each time, like a for loop). Alternatively, comment everything in the old solver methods and then put your modifications gradually, by small steps. Each time you put a small modification, try to compile. Add the next modification only if it compiles. If at a certain point errors arise, you found a part that is giving errors to the compiler. Then fix the errors of that part, and so on until you have put in place all your modified solver. |
|
I was a little confused. I modified the code and compiled, the code shows the multiple definition error. I tried modifying one function and leaving others unchanged, it shows the same thing. However, when I changed the that single file back to where it begins (when the compilation was okay), the multiple definition error shows again when linking Smilei (I did "make clean" everytime). I don't know what's wrong here. |
|
Yes, I had understood the problem from your previous message, in my previous answer there was a strategy to find the error. The code can perfectly compile multiple times in the same folder if the C++ synthax rules are respected. If you obtain an error probably something should be fixed in your modifications. Again, please try to take the code version that compiles without modifications, then try to do your modifications through small incremental steps and at each little step try to compile. If it does not compile, there is an error in the little step you have made and should be corrected to make the code compile. |
|
Okay I finally got the problem (and it's kind of stupid). The modification is okay. But when I modified the code, the system automatically creates a hidden backup folder that contains the original file, and therefore creating a homonym when compiling. I fixed it right now and it compiles okay with modification. Sorry for the trouble. Thanks |
|
Very good, now it's time to test your new solver. |
|
When you posted the error log I noticed the weird path containing Could you please tell us which editor/IDE does this? |
|
It's jupyterlab or jupyter notebook that could create these errors (the editor automatically creates backup files). |
|
The simulation result with y direction relativistic solver doesn't seem so good compared to situation without solve-relativistic-poisson. I'm now thinking about two possible problems. 1. Does "solve relativistic poisson" only applies to the plasma species inside the first simulation window? Since my window is moving, it might be the case that the species initialized after some time do not received the correction? (The density profile seems to get a discontinuity in density) The total number of iterations is about 4000, which should work under the 50000 default "relativistic_poisson_max_iteration" value. 2. Does the "gamma_mean" variable in the functions you mentioned only applies to the x longitudinal direction? Since in the explanation text it says "A relativistic mean velocity in the x direction and a negligible energy spread are assumed in the hypotheses of this procedure". |
I cannot see your movie, the link did not work. Can I see the input namelist? |
|
After I added the relativistic_field_initialization, the error message shows this (I'm not so good at C++ programming and not sure if that's something wrong with the modification): Stack trace (most recent call last): (I'm attaching the modified cpp script and the job script here) |
|
This happens with the non-modified solver? If not, the problem lies in the modification. |
Z10Frank
added
the
needs-user-input
|
Closing the issue, feel free to reopen it if you have news. |
The problem and the context
My problem involves a longitudinal Bx field and an electron species moving in the y direction. However, the current solve_poisson only works in x (longitudinal direction). To initialize a relativistic species moving in transverse direction, I hope to modify the (relativistic) poisson solver to work in y/transverse direction. Thanks
The text was updated successfully, but these errors were encountered: