ColwynGulliford / distgen

Particle distribution generator
https://colwyngulliford.github.io/distgen/
Apache License 2.0
13 stars 8 forks source link

Structure set for xy_dist is not used when building beam #8

Closed jacquelinegarrahan closed 2 years ago

jacquelinegarrahan commented 2 years ago

I've run into a follow up issue from https://github.com/ColwynGulliford/distgen/issues/7 with the set params being used in generating the beam.

After assigning the structure:

image_rep = {
    'type' : 'image2d',
    'min_x': {'value':x_min, 'units':'mm'},
    'max_x': {'value':x_max, 'units':'mm'},
    'min_y': {'value':y_min, 'units':'mm'},
    'max_y': {'value':y_max, 'units':'mm'},
    'P': image
}

print(G["xy_dist:min_x"])
{'value': -630.0, 'units': 'mm'}

All items appear to be set correctly. However, running beam generation in verbose mode suggests that the configuration for the xy_dist is empty:

Creating beam distribution....
   Beam starting from: cathode
   Total charge: 242.912 pC.
   Number of macroparticles: 10000.
   xy distribution:    t distribution: Tukey
      length = 6.6 ps, ratio = 0.8
   px distribution: Gaussian
      avg_px = 0 eV/c, sigma_px = 459.950 eV/c
   py distribution: Gaussian
      avg_py = 0 eV/c, sigma_py = 459.950 eV/c
   pz distribution: Gaussian
      avg_pz = 0 eV/c, sigma_pz = 459.950 eV/c
   Shifting avg_px = -0.565681 eV/c -> 0 eV/c
   Scaling sigma_px = 459.629 eV/c -> 459.95 eV/c
   Shifting avg_py = -0.425358 eV/c -> 0 eV/c
   Scaling sigma_py = 459.827 eV/c -> 459.95 eV/c
   Shifting avg_pz = -0.663741 eV/c -> 0 eV/c
   Scaling sigma_pz = 459.86 eV/c -> 459.95 eV/c
   Shifting avg_t = -0.000784974 ps -> -5.55112E-17 ps
   Scaling sigma_t = 1.27922 ps -> 1.2794 ps
   Cathode start: fixing pz momenta to forward hemisphere
      avg_pz -> 367.079 eV/c, sigma_pz -> 277.139 eV/c
   Applying user supplied transform: "tx" = set_avg x...
      Setting avg_x -> 0 mm.
   Applying user supplied transform: "ty" = set_avg y...
      Setting avg_y -> 0 mm.
...done. Time Ellapsed: 352.669 ms.

I'm using this as a replacement for a File2d dist type and, while this successfully generates particles, the dimensions are incorrect. I'm guessing the xy distribution type is defaulting to something other than image2d here?

Impact returns the below error:

{'error': True, 'run_script': '/Users/jgarra/miniconda3/envs/lume-epics-impact/bin/ImpactTexe', 'start_time': 1647378413.744645, 'why_run_error': 'too many indices for array: array is 1-dimensional, but 2 were indexed', 'run_time': 0.1676008701324463}

Any thoughts?

jacquelinegarrahan commented 2 years ago

Playing around a bit further, I found calling

G.configure()

after the assignment will get the xy_dist into the object params (G.params). I still land with the same downstream error for the dimensions, though, and have no xy_distribution logging in the verbose output.

ColwynGulliford commented 2 years ago

Interesting. Can you send full yaml file or string that you send to Generator so I can test?

ColwynGulliford commented 2 years ago

I believe the blank xy_dist when using verbose is a minor bug, but does not effect particle generation: Screen Shot 2022-03-15 at 7 38 22 PM

I'm trying to understand how your example differs from the one in the examples_dist notebook:

Screen Shot 2022-03-15 at 7 46 10 PM

generates: Screen Shot 2022-03-15 at 7 48 53 PM

I can manipulate the distribution (here I cut a rectangle out of the center and stretch the x scale):

Screen Shot 2022-03-15 at 7 47 32 PM

Screen Shot 2022-03-15 at 7 46 40 PM

ColwynGulliford commented 2 years ago

Btw, did you install the package through conda or through Git?

jacquelinegarrahan commented 2 years ago

Here is the yaml, with xy_dist set as file for placeholder then overwritten with the structure. I've found that if xy_dist is not included in this file, I get a key error when setting the structure.

n_particle: 1000000
random_type: hammersley

start:
  type: cathode
  MTE:
    value: 414
    units: meV    

total_charge:
  value: 250
  units: pC

t_dist:
  type: tukey
  length:
    value: 7.5
    units: ps    
  ratio:  
    value: 0.8
    units: '' 

xy_dist:
  type: file2d
  file: laser.txt

transforms:
    order:
        - tx
        - ty
    tx:
        avg_x:
            units: mm
            value: 0
        type: set_avg x
    ty:
        avg_y:
            units: mm
            value: 0
        type: set_avg y    

Also, I installed via conda. Let me create a small toy example and report back.

ColwynGulliford commented 2 years ago

Ok - I think I may understand the issue now. So the first time you run your code you use file2d for creating particles from an image file. And then you want to update that image. I think the issue that you are running into is this: in distgen the file2d object which reads in your file isn't created until you use gen.run() or gen.beam(). And even then, because it's expecting to always read the xy dist from the file, I don't think it ever creates gen['xy_dist:P'].

The fastest solution is as follows:

  1. Remove the file2d definition from your yaml input
  2. Load the remaining yaml into a dictionary in python
  3. Load your xy PDF data into a 2d NumPy array (*more on how below), say Pxy
  4. Add the xy_dist parameters to the input dict from (2)
  5. Create initial particles
  6. Update Pxy as you want, and put that into gen['xy_dist:P'], update other params as needed
  7. Create new particles

*Loading the Pxy data: I saw in your example you are loading the 2d data from a txt file. That's totally fine, and I think you could load that into python with something like Pxy = np.loadtxt(....). However, if that data comes from an original image file, typically png, tif, or jpeg, it can be loaded directly into python using distgen.tools.read_image_file. This will convert 3 or 4 channel image files into a grey scale 2d NumPy array ready to use.

Below is a python file implementing this solution, as well as an example image file. Note I couldn't attach the python code as .py (which is funny for Git?) so I made it .txt.

jaqueline_example_issue_no8.txt

seaturtle

jacquelinegarrahan commented 2 years ago

Sorry for the delay! This is working well with our packaged model workflow! Thank you for your patience and for helping me work through this :)