Particles Initial Condition

[ktangtar]

Hi,

Can the particle momentum initial conditions be set deterministically? For example, say I want all particles at certain x coordinate to have a certain momentum:
px=0,
py=0,
pz=p0*sin(x/micron).

Regards,
Kavin Tangtartharakul

[Status-Mirror]

Hey Kavin,

You can set a general momentum distribution using the dist_fn key in the species block, but I don't think this is appropriate here. This would be useful if you wanted to initialise from a momentum distribution, but if you want a specific value varying with $x$, I don't think it would help.

Instead, I would recommend manually writing the starting positions and momenta of your particles to file, and loading these using the particles_from_file block.

Hope this helps,
Stuart

[DanRRRR]

The examples in this documentation are desperately needed! More examples, many examples. Without real examples what is written specifically in this paragraph resembles the attempt to describe music with words. Same in some other places. You return to it many times trying to decipher the exact meaning of these words (because there could be multiple possibilities behind the words) and never finish...With hundreds of examples no documentation would even needed. I agree that partically my probems arise because I am not native English speaker plus usually do not like RTFM, any of them, preferring tries and faults :). Still for me the documentation for EPOCH was from the first day looking as a worst disaster i ever seen.

[ktangtar]

Thanks @Status-Mirror. I plan to try this later at some point. But @DanRRRR has a point, it will be much easier if there was a more detailed example of what the particle files should look like (perhaps I missed it when I checked earlier).

[Status-Mirror]

Maybe a bit too late to be useful to you, but there is now a particles_from_file example on our basic examples page here: https://epochpic.github.io/quickstart/basic_examples/particle_load.html#load-particles-from-file

[DanRRRR]

Let me ask again -- am i understanding this correctly that there is no way to make in settings something resembling DO loop? A la this standard Fortran do loop

Do i=1,100
number_density = if( (x gt i *step) and (x lt (i+1) * step), density * i, number_density(Silicon))
EndDo

May be there exist some trickery ?

[Status-Mirror]

The input deck maths parser does not support do-loops.

For repeating structures, your options would be:

• Trickery with the floor() function (you can use this to construct a variable which repeats over space, like (x/10.0e-6) - floor(x/10.0e-6), which repeats every 10 microns).
• Write a code to automate the process of input deck writing, so you can explicitly write each loop iteration.
• Write a code to define macro-particle properties externally, then load from file.

Cheers,
Stuart

[DanRRRR]

Thanks, Stuart.
What kind of difficulties pushed developers not to add the major programming feature like DO loop? Not that i complain, just curious.

Would be great if developers add simplest possible demo examples of loading from file, starting initially from text/ASCII

[Status-Mirror]

The EPOCH maths parser is a complicated piece of code. It reads in a function as a string from a text file (the input deck), and tokenises it into a maths expression that FORTRAN can evaluate. If we were setting the number density of a cell, EPOCH would take the functional form of density, perform any logical tests needed by IF statements, substitute in the $x$ and $y$ position of the cell centre if required, and perform the calculation. This happens on a cell-by-cell basis.

A DO loop would have to override this behaviour, setting things in a certain order, with new variables introduced. It doesn't fit in with the rest of the maths parser syntax, and would require a major re-write.

I would argue that, because the code would gain no new functionality, this isn't worth the extensive developer time it would take to implement. Everything that could be done with a DO loop can be achieved with a workaround, and it wouldn't require a complete rewrite of one of the more complicated parts of the core code.

On basic demos, this is something I'm trying to improve. I've already added a new set of basic laser examples, and I intend to create similar sections for:

• Particle loading (maths parser densities, distribution functions, and loading from files)
• Injectors (plasma injectors, file injectors)
• Ionisation (our field and collisional ionisation benchmarking simulations)

If there's anything else you'd like adding to this list, now would be a good time to suggest something.

[DanRRRR]

EPOCH has few third-party apps like IDL, Matlab, Python to extract the data from SDF files, but not a single one how to get for example coordinates and momentum of particles or E field using the same Fortran EPOCH itself is written on. Nothing is simpler to understand or faster to get massive data. This example would be #1 of all examples if i was developer. :)

[Status-Mirror]

At this stage we're only doing basic examples. I don't think most code-users want to interface directly with the FORTRAN code, and I also don't think this is the most efficient way to output data.

There is a case for outputting particle and field variables in specific places during the runtime of the code, but I see this more as a developer's tool than a user's tool.

[DanRRRR]

I was not clear why i mentioned Fortran. Fortran is not just simplest language and one of the best for science and engineering, the user must know it if he uses EPOCH, but it also fast to extract the data. If anyone can create the SDF data converter with other software as fast then it's great. I saw C and Python converters of HDF format and they all failed by the factor of ... guess?...100! My wish is just to see SDF file viewer/converter EXE file so that after user got EPOCH results in 00042.SDF he can write

SDFconvert.exe 00042.SDF > Output.dat

and see or write these results into text/binarty file like this below. He can visualize it at his wish with 1000 existing codes instead just 3. Why EPOCH developers chose to marginalyze itself with the dead format no one in universe use is beyond me

       x           y           z           px         py          pz         Energy      Charge      Weight       ID1       ID2
   1.164E-02  -2.334E-02  -1.652E-02   7.073E-05   5.299E-05   2.026E-04   6.438E-04   1.003E+08   1.300E+01   1.000E+00   0.000E+00
   5.673E-03   1.764E-02   7.233E-04  -4.399E-04   2.100E-04  -6.531E-05   3.187E-03   1.003E+08   1.300E+01   2.000E+00   0.000E+00
   1.436E-02  -4.964E-03  -2.145E-02   2.004E-05  -4.179E-05   1.329E-04   2.609E-04   1.003E+08   1.300E+01   3.000E+00   0.000E+00
   8.445E-03  -2.310E-02   1.376E-02   3.047E-04  -9.276E-07   8.372E-07   1.224E-03   1.003E+08   1.300E+01   4.000E+00   0.000E+00