External field and moving window about smilei

[MickaelGrechX]

Hello Ujjwal! So, from what you say I think the moving window may not account for the external fields. I will discuss with the guys of the dev-team of this problem. I think if external fields are not accounted for it may be possible to upgrade the moving window to ensure they are. As I have not worked on this particular feature, I'll try to get you some answers from guys who have worked on it. Best, Mickael

…

On Tue, Jul 24, 2018 at 5:15 PM usinhampik ***@***.***> wrote: Hello everyone, I am trying to simulate a relativistic electron beam interacting with a plasma. In this regard, I am using the moving window feature of SMILEI. When I apply an external magnetic field, it is present only in the first window of the system (i.e. the initial simulation domain). As the beam propagates and the simulation domain moves with the beam, the external field vanishes. As a result, I cannot study the effect of an external magnetic field for such systems. It would be very helpful if you can suggest a solution to this. Thank you and regards, Ujjwal Sinha — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#59>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARsfTM3z3J2ONLgyiq5k0D3Q5E6N59Olks5uJzMPgaJpZM4Vc4ot> .

-- ------------------------------------------------------------- Mickael Grech Chargé de recherche CNRS --- Laboratoire d'Utilisation des Lasers Intenses Ecole Polytechnique Route de Saclay 91128 Palaiseau Cedex, France --- tel.: [phone] gsm: [phone] [email protected] -------------------------------------------------------------

[usinhampik]

Thanks a lot Michael for the response. This will be of great help.
When we apply the external field, then initially the field is present. As the window moves towards positive x, the new region entering the simulation domain do not have the field.

[beck-llr]

Hi
This is actually normal. In Smilei, the external field you define is an additional field in your initial simulation box. It can also be coupled with the corresponding boundary conditions, if necessary, so that the field is maintained in the simulation box. It was originally designed for magnetic reconnection simulations. It can also be used to initalize a laser pulse inside the simulation box at t=0 for instance.

But in the case of a moving window, you would have to define a field for all possible time and space where your window could potentially be during the whole course of the simulation. This is the source of many difficulties, confusion and physical misinterpretation so we decided not to implement it for the moment.

Our apologies. I have to admit the documentation is not very clear on this particular point.

[MickaelGrech]

Hi!
Just a quick comment following @beck-llr.
One actually consider that the 'new' plasma injected on the right side of the moving window is in a stationary state. Hence, one could also consider that the fields in there are as should have been defined at t=0.
As an exemple, imagine you want to simulation LWFA in the presence of a constant magnetic field (let say Bx). One should be able to add very easily this external field Bx = cst.
I've discussed this with @jderouillat and we agreed this could be done (with obviously the possible pitfalls you mentioned earlier). @beck-llr, don't you it's worth allowing this feature?

[beck-llr]

It would definitely be worth it yes. And it looks very easy to do in the way you put it @MickaelGrech . But it actually requires quite a lot of thinking and engineering because it modifies patch creation which is a fundamental function. It also raises some questions about boundary conditions.

[usinhampik]

I think this feature will be very helpful to study several phenomenas. In particular, in LWFA as well as beam driven Wakefield. I am not aware of the patch creation function but would like to know if it would be possible by just adding the external field in the equation of motion at every time step.

[jderouillat]

Hi Ujjwal,
Can you try to add in the moving window (src/MovWindow/SimWindow.cpp, line 269) the 3 lines indicated below to test this feature ?

$ git diff
diff --git a/src/MovWindow/SimWindow.cpp b/src/MovWindow/SimWindow.cpp
index 359a99b..1d2e031 100644
--- a/src/MovWindow/SimWindow.cpp
+++ b/src/MovWindow/SimWindow.cpp
@@ -266,6 +266,11 @@ void SimWindow::operate(VectorPatch& vecPatches, SmileiMPI* smpi, Params& params
                     for( unsigned int idiag=0; idiag<vecPatches.localDiags.size(); idiag++ )
                         if( DiagnosticTrack* track = dynamic_cast<DiagnosticTrack*>(vecPatches.localDiags[idiag]) )
                             track->setIDs( mypatch );
+                    
+                    mypatch->EMfields->applyExternalFields( mypatch );
+                    if (params.save_magnectic_fields_for_SM) 
+                        mypatch->EMfields->saveExternalFields( mypatch );
+                    
                 }
             }
         }

[jderouillat]

To be more explicit on what happen here :

• The pragma omp clauses and the ithread loop are used to serialize over threads the usage of python profile which could be used to create particles (not compatible with OpenMP, Python is not thread safe).
• The j loop browses patches newly created.
• The test on patch_to_be_created[ithread][j] identifies patches created at Xmax and not those which are created between 2 MPI process.
• mypatch is the current instance of a newly created patch

    #pragma omp master
    {
        for (int ithread=0; ithread < max_threads ; ithread++){
            for (unsigned int j=0; j< (patch_to_be_created[ithread]).size(); j++){
                //If new particles are required
                if (patch_to_be_created[ithread][j] != nPatches){
                    mypatch = ....
                }
            }
        }
    }
    #pragma omp barrier

[usinhampik]

Thanks @jderouillat . I will try this and comeback to you.

[usinhampik]

Hi @jderouillat ,

I tried what you suggested above. However, I got the following error message while compiling

src/MovWindow/SimWindow.cpp: In member function ‘void SimWindow::operate(VectorPatch&, SmileiMPI*, Params&, unsigned int, double)’:
src/MovWindow/SimWindow.cpp:270:18: error: ‘class Params’ has no member named ‘save_magnectic_fields_for_SM’
if (params.save_magnectic_fields_for_SM)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/MovWindow/SimWindow.cpp:271:27: error: ‘class ElectroMagn’ has no member named ‘saveExternalFields’; did you mean ‘applyExternalFields’?
mypatch->EMfields->saveExternalFields( mypatch );
^~~~~~~~~~~~~~~~~~
applyExternalFields
make: *** [build/src/MovWindow/SimWindow.o] Error 1

I tried looking into Params.h and Params.cpp, but was not sure what should be the datatype of the new variables introduced.

[mccoys]

@usinhampik You likely have an old version of the code (before last april). I suggest you clone the repository on this GitHub to obtain a newer version.

[usinhampik]

Hello all,

I did some preliminary small scale tests and this seems to work. I am running a few large simulations now. I will update with the outcomes in a couple of days.
Thank you all a lot for the help.

[usinhampik]

Hello all,
I ran sufficient number of simulations after adding the lines suggested by @jderouillat and it works fine.
Once again, I thank you all for the prompt response and help.